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

40

En un trabajo actual tengo dos proyectos en los que trabajar. El primero es un sistema muy grande y el segundo es más pequeño pero también grande (el primer proyecto se está desarrollando durante 12 años, el segundo durante 4 años).

Al principio estaba trabajando solo en el primer proyecto y estaba tratando de acostumbrarme. Luego me trasladaron al segundo proyecto e intenté allí, por lo que mi conocimiento sobre el primer proyecto se volvió sombrío. Ahora tengo que trabajar en ambos proyectos al mismo tiempo.

Es muy difícil para mí porque a pesar de que ambos usan Java, usan diferentes marcos y la cantidad de código y lógica de negocios para comprender es muy grande, por lo que realmente no puedo tener ambos proyectos en mi cabeza.

¿Es normal y debería acostumbrarme a ello, aunque mi experiencia se volvió muy escabrosa, qué no sucedería si trabajara solo en un solo proyecto? ¿O debería plantear una inquietud o tal vez cambiar de empleador?

mosquito
fuente
para mí trabajar en múltiples proyectos es más adecuado para el término 'taller de carrocería', lo cual es algo malo, ¿no?
La peor parte es que no soporto la falta de confianza que surge cuando no tienes mucha experiencia en tu proyecto. Y una situación de tener múltiples proyectos en los que trabajar, me impide obtener una gran comprensión y eso me enfurece, porque me sacan de mi zona de comodidad / trabajo.
No quiero cerrar esta pregunta. Solo porque, en mi opinión, si trabajas como programador, debes garantizar que tu código tus cambios no afectarán al sistema. Pero si no tiene experiencia en el sistema, ¿qué garantía puede brindarle? ¿Poner verificación nula en cada llamada de método 'igual' u otros objetos? - ¡Demonios si!
¿Se le permite utilizar tecnologías de colaboración y gestión del conocimiento en el trabajo? (Ejemplos: Wiki, herramientas de revisión de código, acceso a documentos de diseño, herramientas de gestión de proyectos, listas de tareas personales, seguimiento de errores, mensajería instantánea, etc.) Sin esas tecnologías, no es factible trabajar en múltiples proyectos.
rwong
¿Es esta pregunta "más del 50% de las empresas permiten la multitarea" o "¿La multitarea es buena o mala"?
Martin Wickman

Respuestas:

54

Estoy completamente en desacuerdo cuando la gente dice "sí, la multitarea es normal"

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

En primer lugar, no debería simplemente aceptar su destino porque "usted es un empleado tan excelente" y eso significa que debe asumir más tareas de las que puede manejar. Para nada, no lo haces. A veces las personas reciben 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 no pueden manejar su cronograma de proyectos correctamente. Por lo tanto, definitivamente debe tratar de 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 ir a buscar trabajo. [Usted, el desarrollador, es la mercancía. Los empleadores lo saben y rezan para que nunca se den cuenta.]

Ahora, acerca de la multitarea, no estoy de acuerdo al 100% cuando la gente dice "sí, solo cambia de un lado a otro y asegúrate de que estás haciendo la misma cantidad en cada proyecto". Lo siento, pero ese es un muy mal consejo.

Primero debe darse cuenta de cómo funciona su cerebro cuando está desarrollando un software (sé que hay otras tareas involucradas, pero centrémonos en esa). Primero debes "conectarte", lo que significa que debes concentrarte mucho y poner tu mente en una posición en la que tengas todo mapeado en tu 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 uno al lado del otro, todo. Por lo general, me lleva 15 quizás 20 minutos para llegar "a la zona".

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

Entonces, la multitarea es terrible porque te obliga a abandonar "la zona" y pasar a otra cosa. Si cambia constantemente, eso 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 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 del subproceso cada dos ciclos es demasiado alto, por lo que la CPU termina pasando más tiempo cambiando el contexto que ejecutando las tareas reales.

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

http://www.joelonsoftware.com/articles/fog0000000022.html

Entonces, mi consejo es: intente aprender cómo (no) realizar varias 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 múltiples tareas; y eso también está bien. No es porque sea común que deba considerarse normal.

Joel lo dijo bien cuando dijo:

De hecho, la verdadera lección de todo esto es que nunca debes dejar que la gente trabaje en más de una cosa a la vez. Asegúrate de que sepan de qué se trata. Los buenos gerentes ven su responsabilidad como la eliminación de obstáculos para que las personas puedan enfocarse en una cosa y realmente lograrlo.

Alex
fuente
55
Tener varios proyectos en marcha al mismo tiempo no significa que codifique simultáneamente. Eso sería multitarea. Esperar tener un proyecto a la vez puede ser preferible, pero solo está soñando con La La Land.
JeffO
1
+1 excelente. Si las empresas se dieran cuenta de esto, estarían mucho mejor. Sin embargo, algunos lo hacen, ¡y ahí es donde están los ganadores de mañana!
Martin Wickman
Gracias @ Martin. Me parece curioso que algunas personas no entiendan que "multitarea" es lo mismo que trabajar en múltiples proyectos. Nunca dije que la codificación simultánea es lo mismo que la multitarea, ¿de dónde sacaste eso de @Jeff? ¿Beber café y codificar? ¿Me estás tomando el pelo? Entonces, si estás respirando y parpadeando al mismo tiempo, ¿también estás haciendo múltiples tareas? Al menos lee el post completo ¡caramba! El enlace a los artículos de Joel tiene ideas muy similares, léalo antes de poner su comentario aquí.
Alex
2
@Alex - @bjarkef y @Jeff tienen toda la razón; teniendo dos proyectos! = multitarea. La publicación de Joel y su opinión sobre que la multitarea es costosa y derrochadora son correctas, pero no son necesariamente relevantes para trabajar en múltiples proyectos.
Nick Knowlson
55
Por ejemplo, supongamos que decide trabajar en los dos proyectos en días alternos. ¿Dónde entra el costo del cambio de contexto aquí? ¿Y cómo eso interrumpe estar en la zona? Podría ser el caso de que gasan sea constantemente interrumpido por errores de emergencia con el otro proyecto, o incluso errores de emergencia en el mismo proyecto. Ahí es donde la multitarea se convierte en un problema, pero no es inherente a tener dos proyectos en los que trabajar y, a menudo, es un problema incluso con un solo proyecto.
Nick Knowlson
33

Sí, es de esperarse. Y bienvenido.

Hay un par de formas de ver esto:

  1. Se espera que realice varias tareas y es casi imposible concentrarse. Esto da como resultado procesos de ingeniería subóptimos, confusión ocasional al cambiar 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ía con múltiples proyectos, lo que se refleja bien en 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 debe 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 malabarismos 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 sus crecientes habilidades de malabarismo solo son explotadas por su compañía actual, estas son buenas habilidades para tener y le servirán bien en su carrera.

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

bill weaver
fuente
77
En lugar de ser un servidor obediente y esperar las riquezas, ¿quizás ser asertivo y agregar valor señalando la ineficiencia?
Joppe
66
@Tungano: de ninguna manera estoy sugiriendo ser "un servidor obediente", sino que recibir múltiples responsabilidades concurrentes es un efecto secundario natural de ser bueno en lo que haces. Las personas tienden a confiar en aquellos que pueden hacer que las cosas sucedan. Manejar varias responsabilidades no es necesariamente ineficiente, servil u obediente. Si usted (o @gasan) no puede manejar varias cosas de manera eficiente, entonces hágale saber a su empleador para que no cometan el error de pensar que usted puede hacerlo. (FWIW, no dije nada sobre riquezas.)
bw
También evita que te aburras del proyecto cuando eso es todo lo que haces. Actualmente tengo alrededor de 100 tareas diferentes a la espera de realizarse, distribuidas en 17 proyectos. Claro, esto a veces causa cierta presión, pero me siento infeliz cuando no hay nada que hacer además de poner toda mi energía en un solo gran proyecto.
Htbaa
77
Estoy totalmente en desacuerdo con esta respuesta. La multitarea no es una medida de éxito, es una medida de incompetencia de su gerente. Saber cómo realizar tareas múltiples no es tan fácil. PD: publiqué una respuesta yo mismo, pero va al final de la línea.
Alex
66
Esta respuesta no tiene sentido. Es "normal" en un sentido que muchas compañías obligan a los programadores a hacerlo, pero sigue siendo un desperdicio de los recursos de la compañía. Si se enfocaran en una cosa a la vez , se terminaría mucho más rápido.
Martin Wickman el
15

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

Además, si colaboras con proyectos de código abierto, esa es la regla

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

yeradis
fuente
bueno, en realidad lo que me pone triste es el nivel de experiencia que tengo como resultado. Simplemente no tengo esa gran cantidad de memoria para recordar tanto los sistemas empresariales como la lógica técnica, me parece imposible. Todas las veces que obtengo tareas, tengo que buscar y depurar muy duro, porque no conozco bien esos sistemas. ¿Estoy en lo cierto de que el programador "no sabe mucho pero hace todos los trabajos no muy rápido" es lo que debería ser un programador, no el "conocer todo el sistema perfectamente y arreglarlo en un par de horas, chico ninja"?
44
@gasan A todos nos gustaría trabajar en "una cosa a la vez". Sin embargo, trabajar en más de un proyecto, leer el código de otras personas y lidiar con los requisitos variables es el camino hacia el ninja-hood.
bogeymin
12

Es común. Pero no es bueno, por las razones que ha esbozado. Cambiar el contexto se convierte en productividad, por lo que, si puede, intente trabajar en un proyecto durante mucho tiempo, por ejemplo, un día.

Antonio
fuente
9

Trabajo activamente en 2 o 3 proyectos diferentes todos los días. Y mantener unas pocas docenas más. Algunas semanas se vuelve un poco abrumador. Algunos de los proyectos son enormes, algunos son tan pequeños que se codificaron en unos 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 de negocios. Lo disfruto.

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

CaffGeek
fuente
Entonces, ¿eres un tipo de Shiva? Casi no puedo imaginar la cantidad de su aportación a esos proyectos.
@gasan, cantidades ridículas para algunos. Pequeñas, pero a menudo críticas, partes de otros. Y algunos solo tengo que mantenerlos porque el desarrollador original se ha ido ... y esos son los que más tiempo consumen.
CaffGeek
8

Echa un vistazo al artículo llamado Multitarea te lleva más tarde . Este gráfico cuenta la historia:

ingrese la descripción de la imagen aquí

En otras palabras, la compañía está perdiendo el tiempo al hacer que sus programadores trabajen en más de un proyecto a la vez. ¡Con solo tres proyectos, el desperdicio es del 40%! El resto del tiempo se divide en tres proyectos.

La razón de la multitarea a menudo se expresa como "hacer más cosas". Pero ese es un razonamiento defectuoso. La multitarea solo resulta en retrasar todos los lanzamientos. Esta imagen muestra el efecto de la doble tarea frente a terminar un proyecto a la vez:

ingrese la descripción de la imagen aquí

(La imagen ignora los gastos generales por completo. En realidad, el tiempo perdido haría que ambos proyectos fueran un 20% más tarde).

Martin Wickman
fuente
4

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

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

usuario281377
fuente
tienes razón, estoy trabajando en una pequeña empresa ahora, pero anteriormente solo trabajaba para grandes, así que tal vez sea parte de la causa de un problema, quiero decir que no estaba acostumbrado al proceso de trabajo en pequeñas empresas.
4

Sí, en mi experiencia eso es normal (incluso si algunos de los 'proyectos' son bastante similares, por ejemplo, un proyecto de mantenimiento y características del mismo producto). Para evitar conflictos y expectativas poco realistas, acuerde 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, puede distribuir esas asignaciones como desee, por ejemplo, de lunes a miércoles en X, de jueves a viernes en Y.

Ocasionalmente habrá momentos en que un proyecto "arroja una excepción" y necesita ser trabajado ahora . Hay dos cosas que hacer aquí:

  1. asegúrese de que realmente sea una excepción, no solo un gerente de proyecto agresivo: retroceda en el último caso.
  2. intercambia tus asignaciones de tiempo para que sigas trabajando la misma fracción en cada proyecto.
usuario4051
fuente
3

Si le resulta difícil ponerse al día con el marco de trabajo o la lógica de negocios de un proyecto cuando vuelve a hacerlo, debe aprovechar la oportunidad de escribir la mayor cantidad de documentación posible mientras trabaja en ello. Detallar cómo funciona un sistema complejo, en sus propias palabras, hará que sea mucho más fácil volver al proyecto más tarde. 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, aún puede ser beneficioso escribir sus pensamientos mientras trabaja en áreas complicadas. De esa manera, puede retomar su proceso de pensamiento la próxima vez que vuelva a cambiar.

Matt G
fuente
1
Buen consejo. Tomo notas detalladas y han sido muy útiles en más de una ocasión.
Adam Lear
2

Bueno, no debería ser normal, pero tengo muchos proyectos sobre mis hombros en mi empleador actual. Me lleva un tiempo acostumbrarme, lo admito. El consejo más importante que podría dar es priorizar siempre su trabajo. Obliga a tu jefe a decirte cuál es la tarea prioritaria y trabaja solo en eso. No cedas ante quien se queja de tus otros proyectos. No necesariamente necesita actualizar su currículum todavía, pero asegúrese de que la carga no se incremente más allá de algo que pueda manejar razonablemente.

ChaosPandion
fuente
2
De hecho, obliga a tu jefe a decirte lo que es importante. La comunicación es muy importante y, cuando no se mantiene, puede causar mucha frustración y decepción a cualquiera de las partes.
Htbaa
0

Creo que es normal La forma en que funciona mi trabajo en este momento (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 "plazo más largo" con muchos pequeños tickets / defectos que surgen, por lo que generalmente termina siendo 50% de tickets pequeños y 50% de trabajo en el proyecto a largo plazo. Lo que puede ser difícil es que la interrupción constante puede ralentizar y descarrilar el proyecto a largo plazo.

BMW
fuente
0

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 el 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 debe tener en mente a la vez.

Pradeep
fuente
0

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

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

Sin embargo, aún debe trabajar en partes considerables en cada proyecto para poder "entrar en la zona" y ser productivo.

usuario1249
fuente
-1

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

¡Míralo como algo positivo, te volverás más útil, visto como flexible, un hombre que puede hacer las cosas! Quizás sea más valioso ya que eventualmente conoces 2 sistemas al revés.

ozz
fuente
-1

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

El peor trabajo de desarrollo que tuve fue trabajar en la misma pequeña sección de la misma parte de la misma aplicación durante meses. Tedio. Y cuando estás aburrido, quitas el ojo de la pelota ...

cjmUK
fuente
Si su trabajo es aburrido, tal vez debería encontrar uno diferente más interesante, en lugar de tratar de hacer que parte de él sea más interesante.
Acumenus
Lo hice, pero pensar que cada aspecto de cada trabajo será emocionante es ingenuo.
cjmUK
Lo siento, pero no puedo empatizar. Como programador, encuentro interesantes todos mis proyectos asignados, no solo en mi trabajo actual, sino también en el que tenía antes. No tiene que ser emocionante; eso es diferente. Hay un espectro interesante entre emocionante y aburrido.
Acumenus
Entonces creo que eres muy afortunado ... Sin embargo, sospecho que estoy en el grupo demográfico más grande que tiene que tomar lo duro con lo suave.
cjmUK
-1

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 a 3 Trabajos trabajando juntos más de un generador de dinero que 1 a la vez, y las estadísticas muestran una disminución del rendimiento del 40%. Eso es una pérdida del 40% en las ganancias.

Anteriormente trabajé para una organización que me permitió centrarme en 1 proyecto grande a la vez con pequeños trabajos intermedios, tickets y soporte, etc. Trabajamos en un acuerdo donde 8: 00-10: 00AM era Ticket y soporte para los sistemas actuales que se enviaron por correo electrónico / teléfono / servicio de asistencia y luego 10:00 - 16:30 o su tiempo de finalización fue un desarrollo sólido completo. Esto funcionó muy bien, ya que teníamos un servicio de asistencia para atender las llamadas y correos electrónicos, pude hacer los boletos 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 diariamente, ignoran el hecho.

Estuve 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 todavía hicimos TODO el trabajo.

Otro problema es que el dinero de Boss ama, 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. Se ve muy bien en papel pero puede dañar la reputación de la empresa cuando no se cumplen, se pierden los plazos y los sistemas tienen errores debido a la falta de concentración.

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

Steve Church
fuente
¿Cómo responde esto a la pregunta que se hace?
mosquito
-2

Depende de cómo describas el proyecto. Por lo general, el desarrollador trabaja con algún problema y si en la empresa hay más de un producto del que usted trabaja con múltiples.

Dainius
fuente
Ofrecemos 2 productos separados y comparten un pequeño código. Que los productos son para diferentes necesidades de los usuarios, pero aún están en el mismo dominio.
-2

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

Apalala
fuente
-2

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

Brian Carlton
fuente