Es normal que el programador trabaje en múltiples proyectos simultáneamente [cerrado]

No estoy de acuerdo cuando la gente dice "sí, la multitarea es normal"

Es no normal! No, en absoluto, es muy poco natural que un desarrollador realice varias tareas en varios proyectos (explicaré más adelante). Por otro lado, la multitarea es muy común entre los desarrolladores. Esto es definitivamente algo a lo que deberías acostumbrarte. Entonces, la respuesta real a su pregunta es: ¿cómo realizar múltiples tareas?

En primer lugar, no debería simplemente aceptar su destino porque "usted es un excelente empleado" y eso significa que necesita realizar más tareas de las que puede manejar. En absoluto, no lo haces. A veces a las personas se les dan múltiples tareas porque no hay nadie más. A veces, los gerentes no pueden manejar su trabajo, por lo que delegan, imponiendo tareas múltiples en su equipo porque ellos no pueden manejar el cronograma de su proyecto de manera adecuada. Por lo tanto, definitivamente debe intentar determinar si se le pide que realice varias tareas porque es parte de su trabajo o porque otras personas son incompetentes . De cualquier manera, puedes juzgar por ti mismo si eso es aceptable o no. Si no se siente cómodo [con su trabajo], hay otros lugares donde puede encontrar trabajo. [Usted, el desarrollador, es la mercancía. Los empleadores saben esto y oran para que nunca te des cuenta.]

Ahora sobre la multitarea, no estoy de acuerdo al 100% cuando la gente dice "sí, simplemente alterne y asegúrese de hacer la misma cantidad en cada proyecto". Lo siento, pero es un consejo muy malo.

Primero debes darte cuenta de cómo funciona tu cerebro cuando estás desarrollando un software (sé que hay otras tareas involucradas, pero concentrémonos en esa). Primero debe conectarse "por cable", lo que significa que necesita concentrarse mucho y poner su mente en una posición en la que tenga todo asignado en su cabeza. Todos los nombres de variables y métodos, el flujo de trabajo de su código, el modelo de objetos, los hilos que van de lado a lado, todo. Por lo general me toma 15 tal vez 20 minutos para llegar "a la zona".

Cuando llegas a ese estado, realmente estás volando y escribiendo código como si estuvieras manejando una bicicleta. En el momento en que te interrumpes puedes perderlo todo. Si la interrupción es lo suficientemente larga (5, 10 tal vez 30 minutos) perderá ese estado mental y tendrá que comenzar de nuevo.

Así que la multitarea es terrible porque te obliga a salir de "la zona" y pasar a otra cosa. Si está cambiando constantemente, significa que no está siendo productivo porque cada vez que cambia a una nueva tarea / proyecto, necesita perder esos 15-20 minutos para volver a ingresar a la zona (sin mencionar que derrite su cerebro lentamente).

Es como un subproceso múltiple: en algún momento, el costo de cambiar el contexto de subproceso cada par de ciclos es demasiado alto, por lo que la CPU pasa más tiempo cambiando de contexto que ejecutando las tareas reales.

Recomiendo encarecidamente leer un artículo de Joel Spolsky sobre este tema:

enlace

Por lo tanto, mi consejo es: intente aprender a (no) realizar múltiples tareas porque es muy común. Pero también asegúrate de que te sientas cómodo haciéndolo. Algunas personas pueden tomar más tiempo para concentrarse y sufrirán más que otras cuando realizan tareas múltiples; y eso está bien también No es porque es común que se lo considere normal.

Joel lo puso bien cuando dijo:

  

De hecho, la verdadera lección de todo esto es que nunca debes dejar que las personas trabajen en más de una cosa a la vez. Asegúrate de que sepan lo que es. Los buenos gerentes consideran que su responsabilidad es eliminar obstáculos para que las personas puedan concentrarse en una cosa y realmente hacerla.

Sí, es de esperar. Y bienvenido.

Hay un par de maneras de ver esto:

1. Se espera que realice varias tareas y es casi imposible concentrarse. Esto se traduce en procesos de ingeniería subóptimos, confusión ocasional a medida que cambias de un lado a otro, una sensación de ser explotado, frustración, estrés, etc. Todo esto es negativo, por supuesto; sin embargo,

2. Se le confían varios proyectos, lo que refleja bien los resultados que produce y la confianza que su empleador tiene en sus capacidades. Es una oportunidad para mostrarles que la confianza está garantizada.

Mi consejo es desarrollar un juicio sobrio sobre qué tareas requieren su atención inmediata y cuáles pueden esperar. A veces la respuesta es que ninguno de los dos puede esperar y es necesario adoptar un enfoque creativo para proporcionar resultados (un poco para el proyecto A, luego un poco para el proyecto B, luego enjuague y repita). Cultive las habilidades para prosperar en este tipo de situación.

Normalmente (aunque no siempre), esto será recompensado con más responsabilidad, más proyectos para hacer malabares y más expectativas. En algún momento podrá, y se espera, delegar parte de este trabajo. Es una medida de éxito.

Por lo tanto, incluso si su empresa actual solo explota sus crecientes habilidades de malabarismo, estas son buenas habilidades y le serán de gran utilidad en su carrera.

Por lo que vale, por lo general estoy trabajando en un proyecto importante, uno más pequeño, mantenimiento y soporte de proyectos antiguos y administrando al menos uno más. Es frustrante, confuso, aburrido y estoy muy agradecido.

¡Sí! Eso es completamente "normal" / habitual cuando trabaja en una empresa de servicios xD

También si colabora con proyectos de código abierto, esa es la regla

Tal vez no sea un estado ideal, pero es el pan de todos los días.

Es común. Pero no es bueno, por las razones que ha expuesto. El cambio de contexto se traduce en productividad, por lo que, si puede, intente trabajar en un proyecto durante una gran cantidad de tiempo, por ejemplo. un día.

Trabajo activamente en 2 a 3 proyectos diferentes todos los días. Y mantén algunas docenas más. Algunas semanas se pone un poco abrumador. Algunos de los proyectos son enormes, otros son tan pequeños que fueron codificados en unos pocos días y rara vez necesitan cambios. Varía, pero me mantiene expuesto a diferentes formas de pensar y resolver problemas, diferentes tecnologías y áreas comerciales. Lo disfruto.

Entonces, para responder a tu pregunta, sí, es muy común.

Consulte el artículo llamado La multitarea lo lleva más adelante . Este gráfico cuenta la historia:

Enotraspalabras,lacompañíaestáperdiendoeltiempohaciendoquesusprogramadorestrabajenenmásdeunproyectoalavez.¡Consolotresproyectos,labasuraesdel40%!Elrestodeltiemposedivideentresproyectos.

Elmotivodelamultitareaamenudosedeclaracomo"hacer más cosas". Pero eso es razonamiento defectuoso. La multitarea solo provoca el retraso de todos los lanzamientos. Esta imagen muestra el efecto de la asignación de tareas dual frente a la finalización de un proyecto a la vez:

(La imagen ignora por completo la sobrecarga. En realidad, el tiempo perdido hará que ambos proyectos se realicen 20% más tarde.)

Depende de la empresa. En mi opinión, es deseable trabajar principalmente en un solo proyecto, pero a menudo eso no es posible, especialmente con pequeñas empresas.

Por supuesto, las correcciones de errores, etc., siempre pueden ocurrir con cualquier proyecto.

Sí, en mi experiencia, eso es normal (incluso si algunos de los 'proyectos' son bastante similares, por ejemplo, un proyecto de mantenimiento y funciones en el mismo producto). Para evitar conflictos y expectativas poco realistas, póngase de acuerdo con los gerentes de proyecto y su gerente para asignar ciertas fracciones de su tiempo a cada proyecto (por ejemplo, tres días en el proyecto X, dos en el proyecto Y por semana). Normalmente, luego puede distribuir esas asignaciones como desee, por ejemplo. De lunes a miércoles en X, de jueves a viernes en Y.

Ocasionalmente, habrá ocasiones en que un proyecto "arroje una excepción" y deba ser trabajado en ahora . Hay dos cosas que hacer aquí:

1. asegúrese de que realmente sea una excepción, no solo un gestor de proyectos agresivo: retroceda en el último caso.
2. intercambia tus asignaciones de tiempo para que aún trabajes la misma fracción en cada proyecto.

Si le resulta difícil volver a la velocidad con el marco de trabajo o la lógica empresarial de un proyecto cuando lo vuelva a utilizar, debe aprovechar la oportunidad para escribir toda la documentación que pueda mientras trabaja en ello. El detalle de cómo funciona un sistema complejo, en sus propias palabras, hará que sea mucho más fácil volver al proyecto más adelante. Además, esta documentación puede ser útil para sus compañeros de trabajo si alguna vez necesitan ayuda.

Si el proyecto ya tiene una buena cobertura de documentación técnica, puede ser beneficioso anotar sus pensamientos mientras trabaja en áreas complicadas. De esa manera, puede continuar con su proceso de pensamiento la próxima vez que vuelva a cambiar.

Bueno, no debería ser normal, pero tengo muchos proyectos sobre mis hombros en mi empleador actual. Me lleva algo de tiempo admitirlo. El consejo más importante que puedo dar es priorizar siempre tu trabajo. Obliga a tu jefe a que te diga cuál es la tarea prioritaria y trabaja solo en eso. No ceda a la presión de quien se esté quejando de sus otros proyectos. No es necesario que actualices tu currículum vitae todavía, pero asegúrate de que la carga no se extienda más allá de algo que puedas manejar razonablemente.

Creo que es normal. La forma en que funciona mi trabajo ahora mismo (estoy en una empresa con unos 40 desarrolladores, el tamaño total de la empresa es de aproximadamente 700). Y generalmente tengo un proyecto de "largo plazo" con muchos tickets / defectos pequeños que surgen, por lo que generalmente termina siendo un 50% de tickets pequeños y un 50% de trabajo en el proyecto a largo plazo. Lo que puede ser difícil es que la interrupción constante puede ralentizarse y descarrilar el proyecto a largo plazo.

Creo que es normal trabajar en múltiples proyectos. La clave es aceptar que enfrentará cierta ambigüedad en términos de la imagen general del sistema inicialmente.

Si se esfuerza por obtener una imagen más grande, obtendrá claridad y podrá detectar las partes móviles / fijas en el sistema y cómo sus cambios afectan al sistema.

Durante un período de tiempo, aprenderá a encontrar patrones comunes en los diversos sistemas en los que trabaja. Puede aplicarlos a sus otros proyectos, lo que reducirá la cantidad de información granular que necesita tener en su mente al mismo tiempo.

En cualquier proyecto no trivial hay más de una persona asignada. Esto significa que necesita colaborar con otros y esperar a que ellos hagan su trabajo, así como también necesitan esperar por usted.

En lugar de tener personas sentadas inactivas, es común tener varios proyectos activos para que siempre haya una tarea abierta que hacer si es necesario.

Aún debes trabajar en porciones considerables en cada proyecto para que puedas entrar "en la zona" y ser productivo, sin embargo.

Estoy de acuerdo con los que dicen que es normal / común.

Considérelo como algo positivo, se volverá más útil, visto como flexible, ¡una persona que puede hacer las cosas! Quizás sea más valioso a medida que con el tiempo llegues a conocer 2 sistemas de adentro hacia afuera.

En mi humilde opinión, no solo es habitual, sino que también es deseable.

El peor trabajo de desarrollo que he tenido en mi vida fue trabajar en la misma sección pequeña de la misma parte de la misma aplicación durante meses. Tedio. Y cuando estás aburrido, apartas la vista del balón ...

Entiendo cómo se siente, es difícil hacer que los nuevos empleadores comprendan el desarrollo procesado involucrado, especialmente si su empleador no está enfocado en el desarrollo.

El problema es que ven 3 trabajos trabajando juntos más de un fabricante de dinero que 1 a la vez, y las estadísticas muestran una disminución del rendimiento del 40%. Eso es 40% de pérdida en ganancias ..

Anteriormente, trabajé para una organización que me permitió concentrarme en 1 proyecto grande a la vez, con pequeños trabajos intermedios, tickets y soporte, etc. Trabajamos en un acuerdo donde 8: 00-10: 00 AM era Boleto y soporte para los sistemas actuales que llegan a través de correo electrónico / teléfono / servicio de asistencia, de 10:00 a 16:30 o su hora de finalización fue un desarrollo completamente sólido. Esto funcionó extremadamente bien, porque teníamos un servicio de asistencia para atender las llamadas y los correos electrónicos, pude hacer los tickets por la mañana y desarrollar el resto del día. El problema es si tienes una mala gestión. Un gerente hace que todo esto suceda, y sin su apoyo o comprensión de los desafíos que enfrenta a diario, ignoran el hecho.

He estado agradecido especialmente en mi último trabajo por el apoyo y la comprensión de mi gerente, me hizo la vida más fácil, menos estrés y aún tenemos TODO el trabajo hecho ...

Otro problema es, el dinero de amor de Boss, ven proyectos en dinero. Cuando tienen 5 proyectos por £ 20,000 al mismo tiempo (y usted es un desarrollador en solitario), eso es £ 100,000 en los libros. el papel puede dañar la reputación de la empresa cuando no se cumplen, se pierden los plazos y los sistemas tienen problemas debido a la falta de concentración.

Simpatizo contigo completamente, estoy en tu posición ahora mismo.

Depende de cómo se describa el proyecto. Por lo general, los desarrolladores trabajan con algún problema y si en compañía hay más de un producto con el que trabaja con múltiples.

Los proyectos de software, como los socios amorosos, pueden ser muchos y buenos para muchos, pero solo son buenos si se hacen uno a la vez.

Agregando a lo que dijo @Martin Wickman, trate de no cambiar mucho las tareas. Por ejemplo, trabaje AM en el proyecto A, PM en el proyecto B. También diga no a la adición de características; eso es más doloroso cuando no estás trabajando en el proyecto a tiempo completo.