¿La rotación de desarrolladores en un proyecto es una buena o mala idea?

Estoy trabajando en un equipo pequeño que comenzará a trabajar en un nuevo proyecto grande con otro equipo pequeño. El otro equipo está trabajando actualmente en un sistema heredado en el que han estado trabajando durante años.

El gerente ha decidido que los desarrolladores de mi equipo rotarán cada pocos meses para reemplazar a los desarrolladores que trabajan en el sistema heredado. De esa manera, el otro equipo tendrá la oportunidad de trabajar en el nuevo proyecto y comprender mejor el nuevo sistema.

Quiero conocer los beneficios y los inconvenientes (si los hay) de rotar a los desarrolladores del proyecto cada 2-3 meses.

Sé que esta es una pregunta similar a "¿Es una buena o mala idea rotar al desarrollador principal?" , pero esa pregunta se centra en un desarrollador principal. Esta pregunta trata sobre la rotación de todo el equipo dentro y fuera del proyecto (el líder técnico para el nuevo proyecto puede o no rotarse, aún no lo sé).

Me sorprende que todos piensen que esto es algo tan bueno. Los autores de Peopleware (que, en mi opinión, sigue siendo uno de los pocos libros de gestión de proyectos de software que realmente vale la pena leer) no están de acuerdo. Casi toda la Parte IV del libro está dedicada a este mismo tema.

El equipo de software es una unidad funcional increíblemente importante. Los equipos necesitan gelatina para ser realmente productivos. A los miembros del equipo les lleva tiempo ( mucho tiempo) ganarse el respeto de los demás, aprender los hábitos, peculiaridades, fortalezas y debilidades de los demás.

Ciertamente, por experiencia personal, puedo decir que después de un año de trabajar con ciertas personas, he aprendido a reírme de ciertas cosas que solían irritarme, mis estimaciones como líder del equipo son mucho mejores, y no es demasiado difícil. distribuir el trabajo para hacer felices a todos. No fue así al principio.

Ahora puede decir: "Oh, pero no estamos dividiendo a todo el equipo, solo moviendo a algunas personas". Pero considere (a) cuán ciegamente improductivas serán sus reemplazos al principio, y (b) cuántas veces se encontrará a sí mismo u otros equipos diciendo, sin siquiera pensar: "Realmente me gustó X" o "Esto habría tenido ha sido más fácil con Y todavía cerca " , ofendiendo sutil e inconscientemente a los nuevos miembros y creando cismas dentro del equipo existente, incluso sembrando el descontento entre los miembros" viejos ".

La gente no hace esto a propósito , por supuesto, pero sucede casi siempre. La gente lo hace sin pensar. Y si se obligan a no hacerlo, terminan enfocándose aún más en el tema y se sienten frustrados por el silencio forzado. Los equipos e incluso los sub-equipos desarrollarán sinergias que se perderán cuando juegues con la estructura. Los autores de Peopleware lo llaman una forma de "teamicidio".

Dicho esto, aunque rotar a los miembros del equipo es una práctica horrible, rotar a los propios equipos está perfectamente bien. Aunque las compañías de software bien administradas deberían tener algún concepto de propiedad del producto, no es tan perjudicial para un equipo mover todo el equipo a un proyecto diferente, siempre y cuando el equipo realmente termine el proyecto anterior o al menos lo lleve a un nivel con el que están contentos.

Al tener períodos de equipo en lugar de períodos de desarrollador , obtienes los mismos beneficios que esperarías obtener con desarrolladores rotativos (documentación, "polinización cruzada", etc.) sin ninguno de los efectos secundarios desagradables en cada equipo como una unidad. Para aquellos que realmente no entienden la gestión, puede parecer menos productivo, pero pueden estar seguros de que la productividad perdida al dividir el equipo eclipsa totalmente la productividad perdida al trasladar ese equipo a un proyecto diferente.

PD: En su nota al pie de página, menciona que el líder tecnológico podría ser la única persona que no se rotará. Esto está prácticamente garantizado para arruinar a ambos equipos. El líder tecnológico es un líder, no un gerente, él o ella tiene que ganarse el respeto del equipo, y no solo se le otorga autoridad por los niveles más altos de administración. Poner a todo un equipo bajo la dirección de un nuevo líder con el que nunca han trabajado y que es muy probable que tenga ideas diferentes sobre cosas como arquitectura, usabilidad, organización del código, estimación ... bueno, va a ser estresante como el infierno. para el líder que intenta construir credibilidad y muy improductivo para los miembros del equipo que comienzan a perder cohesión en ausencia de su antiguo líder. A veces las empresas tienenhacer esto, es decir, si el líder renuncia o es promovido, pero hacerlo por elección parece una locura.

No veo muchos inconvenientes aquí yo mismo. La rotación te consigue:

• Polinización cruzada del conocimiento institucional: todos conocerán el proyecto heredado y el nuevo, al menos en teoría.
• Entrenamiento cruzado: diferentes proyectos requieren diferentes cosas a menudo. Usted crece mucho más como desarrollador que trabaja en proyectos feos y heredados que en proyectos agradables y limpios.
• Proyectos fundamentalmente mejores: nada como contar con un nuevo equipo para que termine la documentación y limpie los procesos feos con los que está dispuesto a vivir pero que no admite públicamente.
• Mejor código: más cabezas son mejores en la mayoría de los casos.
• Probables mejoras en la moral: la variedad es la especia de la vida. Y quién quiere estar atascado en el modo heredado de corrección de errores del proyecto / grabación de conductos permanentemente. También tenga en cuenta que su "nuevo" proyecto se convertirá en legado en algún momento, ¿quiere estar atrapado allí para siempre?

Probablemente, el único inconveniente es la caída de productividad que se obtiene al cambiar de lugar, pero eso solo debería doler mucho la primera vez. Luego, ambos lados tendrán algo de tiempo para sentarse en ambos lugares y las partes feas de la transferencia probablemente se entenderán mejor y tal vez se resuelvan.

Curiosamente, en mi experiencia, a menudo hemos comenzado nuestros proyectos con esta misma intención. En el futuro, a menudo no hemos podido actuar en esta intención debido a las limitaciones en el nuevo proyecto y la creencia de que el entrenamiento cruzado es demasiado costoso.

Sin embargo, siempre deseo haberlo logrado, ya que a largo plazo creo que es beneficioso para todas las partes: equipo, empresa, cliente y software. 2/3 meses suena como una temporada lo suficientemente larga como para que exista un riesgo limitado de cualquier impacto negativo grave, no hay cambio de contexto para los desarrolladores involucrados, excepto en el punto de cambio en el que pueden dedicarse al proyecto alternativo.

Un par de posibles beneficios no mencionados:

• Mejor gestión de proyectos. Si los gerentes de proyecto de ambos proyectos están a bordo, lo mejor para ellos es trabajar duro para que los períodos de transición no sean dolorosos para ninguno de los proyectos. Este es el turno (dependiendo de su configuración) podría generar una colaboración más estrecha entre los PM y los equipos de desarrollo.
• Mejor documentación (proactiva). Si sabe que está entrando y saliendo de un proyecto, no solo es en el mejor interés del proyecto, el mejor interés de las empresas, las mejores prácticas en general, sino ahora en el mejor interés de cada desarrollador para facilitar la vida mientras están rebotando alrededor.
• Lo moral es un gran problema, si tus desarrolladores no han tenido suficiente de estar atrapados en un proyecto heredado, ¡entonces podrían no ser los desarrolladores que deseas! Si lo han hecho, cambiarlos y lograr que otros desarrolladores trabajen en ellos los hará sentir amor por su empresa, simplemente podrían ordenar los fragmentos de código que pensaron que nadie vería nunca. Los sistemas heredados a menudo se ven como proyectos de segunda clase, lo que a menudo va en detrimento de ellos, tal vez de esta manera usted ayuda a cambiar esa percepción.

La rotación es algo bueno para la empresa y también puede serlo para los desarrolladores.

Hay muchas buenas razones y Wyatt ha mencionado muchas de ellas en su respuesta.

Dicho esto, en su situación, puede encontrar que al presentar esto, los desarrolladores que se están mudando del proyecto más nuevo al proyecto heredado pueden no estar contentos, por lo que debe haber una comunicación muy clara de por qué sucede esto y cuánto tiempo es para, y el plan en el futuro.

Puede ser bueno pensar en no intercambiar los equipos al por mayor para comenzar y rotar 1 o 2 desarrolladores para comenzar, aunque esto podría parecer que se selecciona a las personas para una degradación (que algunas personas pueden ver).

Estoy de acuerdo con Aaronaught que es muy extraño ver cuántas personas simplemente no ven las desventajas. Pocos piensan mal, que puedes señalar muy rápido: el código no tiene dueño y cuando todos son responsables de todo, no es tan bueno para la calidad . Los desarrolladores no son recursos (incluso los gerentes los llaman así a menudo), son personas y para el equipo es muy importante conocerse, la rotación hace un poco de caos allí. Si trabaja para algún proyecto durante más tiempo, se convertirá en un experto (no solo en el dominio, sino en ese proyecto), sabrá de dónde provienen la mayoría de los problemas, quién obtendrá las mejores respuestas o tal vez algunos conocimientos de dominio más específicos, etc. Si eres nuevo, deberás aprender todo lo que piensa, por lo que se ralentizará el progreso. Pero, por supuesto, también es bueno conocer otras prácticas en su organización, cómo otros equipos construyen y se organizan. Es especialmente bueno si sus proyectos están relacionados de alguna manera, por ejemplo, un proyecto es entrada para otro (no es necesario directamente), por lo que obtendrá una mejor comprensión del panorama general. Y, por supuesto, la difusión de la experiencia es buena (si tiene tiempo para obtener estos conocimientos).

Estoy de acuerdo con la respuesta principal de Aaronaught y tengo algunas adiciones.

• A la gente no le gusta que la empujen.
• En un entorno empresarial jerárquico, a las personas se les pueden asignar responsabilidades que luego se les quitarán nuevamente. Esto puede ser solo parte del trabajo. Sin embargo, cuanto más a menudo ocurra, menos probable será que estas personas se sientan responsables de cualquier cosa que se les asigne.
• El primer punto también se aplica al trabajo de mantenimiento en cosas que las personas mismas no crearon. Limpiar el desorden de otras personas (o más neutralmente formulado: trabajo inacabado) no es particularmente motivador para la mayoría de las personas creadoras.
• La filosofía "un programador es un programador es un programador, son complementos anónimos para ser insertados en proyectos según sea necesario" no hace que ningún programador se sienta apreciado o se preocupe más por las tareas que se le asignan.

El momento perfecto para reasignar a alguien es cuando comienzan a aburrirse con lo que están haciendo. No hay nada más que ganar, todo está bajo control, el trabajo está hecho. En estos casos, generalmente se presentarán y pedirán otras oportunidades por sí mismos.

Por supuesto, la realidad es terca y, a menudo, no hay otra opción, alguien puede ser necesitado en otro lugar por cualquier razón. Esto no es necesariamente malo, también puede hacer que una persona se sienta importante y si la persona va a resolver un gran problema, habrá crédito para él.

Es probable que solo arrastrar a la gente para difundir el conocimiento aumente la rotación. De esa forma, el conocimiento se difundirá, pero se extenderá fuera de la empresa, lo que probablemente no sea la intención.

TL; DR Conviértalo en un equipo y luego es un equipo que apoya 2 proyectos.

Para hacer eco en @Aaronaught, creo que mezclar equipos puede ser problemático, ya que puede llevar tiempo acostumbrarse a nuevas prácticas, procesos, etc. Si gira a demasiadas personas para que rápidamente el equipo pierda su identidad. Esto lleva a más preguntas, confusión y tiempo dedicado a tratar de compensar esa identidad.

Por otro lado, si hay un esfuerzo concertado para unir los 2 equipos en un equipo y tener 1 equipo de apoyo 2 proyectos, creo que funciona muy bien siempre que el equipo no sea demasiado grande. He formado parte de numerosos equipos que apoyan múltiples proyectos. Cuanto más cerca de la tecnología estén los 2 proyectos, más fácil será la transición. En mi experiencia, el mayor costo en la transición de un proyecto a otro se produce al cruzar idiomas, cliente / servidor (especialmente GUI), industria (médica, web, juego) u otras líneas similares. El truco es lograr que diferentes personas trabajen en el proyecto con la frecuencia suficiente para obtener los beneficios, pero no tan a menudo que el costo de transición exceda los beneficios.

Entonces, los beneficios de atraer a más personas a un proyecto son bastante conocidos, al igual que los costos.

La rotación de programadores es buena desde el punto de vista de la compañía y del desarrollador.

Desde la perspectiva de una empresa

1. La gerencia conocerá la fortaleza y la debilidad de un desarrollador en particular si puede manejar la multitarea o no y adaptarse a los cambios.
2. Si algún desarrollador deja la compañía por alguna razón, la compañía ya tiene una copia de seguridad lista para el futuro.
3. Mejorará el rendimiento del proyecto, ya que muchas personas trabajarán en él, lo mismo será probado por más y más desarrolladores. (Prueba de desperdicio de recursos minimizado)
4. Todos los miembros del equipo trabajan en equipo y aumentará el rendimiento del proyecto y, en el futuro, la gerencia conocerá qué tipo de equipo debe formarse al implementar un módulo o tarea difícil.

Desde la perspectiva del desarrollador

1. Hará que el desarrollador sea más positivo a medida que aumente su confianza.
2. Los desarrolladores obtienen mejores y mejores ideas del código de otros compañeros de equipo y pueden usar esas técnicas en el desarrollo futuro.
3. A partir de mejores ideas y sugerencias de otros miembros del equipo, aumenta la productividad del desarrollador.

Solo una cosa principal, debe tener en cuenta que,

La rotación de los programadores no debería ser muy frecuente. después del 60% - 70% de desarrollo realizado, solo el cambio será beneficioso.