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

38

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é).

Christian P
fuente
2
Hay una pregunta sobre esto en ProjectManagement StackExchange: ¿conoce alguna empresa que rota a los desarrolladores entre diferentes proyectos de manera regular?
Spoike
2
No solía convertir esto en una pregunta subjetiva / argumentativa al dar mi opinión personal en la pregunta. Mi instinto es que esto no es una buena idea, pero tal vez hay algo que no sé :)
Christian P
1
¿Qué razón dio el gerente cuando le preguntaste por qué? Es en el mejor interés de una empresa compartir el conocimiento sobre un producto en caso de que los desarrolladores se vayan.
dcaswell
1
Eso es un problema. Si su gestión aún no es completamente transparente al respecto, entonces es probable que sea una señal de que no lo han pensado en absoluto.
Aaronaught
1
Lo que sugeriría es que el equipo inicial que inicia el proyecto esté compuesto por algunos desarrolladores de proyectos heredados actuales y algunos desarrolladores de proyectos nuevos actuales. Mantenlos a través del proyecto. Al final, los desarrolladores antiguos soportan el nuevo producto y los nuevos desarrolladores se unen a otros desarrolladores heredados para hacer el próximo proyecto. De esa manera, el equipo es el mismo durante el proyecto (o lanzamiento principal), pero las personas heredadas se ponen al día sobre lo que apoyarán más adelante. Los nuevos empleados generalmente deben comenzar con legados a menos que tengan alguna habilidad especial que su equipo no tenga para el proyecto.
HLGEM

Respuestas:

76

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.

Aaronaught
fuente
2
No esté completamente en desacuerdo, sin embargo, no está exento de defectos: los equipos pueden construir imperios, y a veces estos se desmoronan La productividad no siempre es el objetivo más importante de un gerente, que (si es que es bueno), está mirando más hacia el final del juego que otro podría ser.
mattnz
44
@mattnz: ¿Qué "juego final" hay para un gerente que no sea alta productividad, retención de empleados y poder enviar a tiempo / dentro del presupuesto? Estoy hablando de gerentes éticos aquí, por supuesto, que realmente quieren hacer lo mejor para la empresa y no están usando el equipo o el proyecto como vehículo para avanzar en sus propios objetivos profesionales. Una organización de software quiere imperios (los imperios son estables y ganan dinero) y sí, los imperios pueden caer, pero es mucho menos probable que caigan que un castillo de naipes.
Aaronaught
2
la rotación es mejor que la gente que abandona la compañía por completo
Warren
44
@warren: Si esas dos opciones son las únicas, entonces la última es casi inevitable.
Aaronaught
3
En serio, no entiendo esta respuesta en absoluto. Todos los miembros de un equipo deben ser profesionales y trabajar bien con los demás, suponiendo que todos los miembros del equipo sean realmente competentes, lo cual es un problema diferente. La rotación de los miembros del equipo es a menudo la única opción para un gerente con escasez crónica de personal en ambos productos o donde el desgaste representa una seria amenaza. A menudo es muy difícil encontrar un buen talento en primer lugar. La rotación de los miembros del equipo es una manera de cubrir las apuestas contra los desarrolladores que se van. También es más equitativo para los desarrolladores que trabajan en software heredado cuando les gustaría aprender algo nuevo.
maple_shaft
18

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.

Wyatt Barnett
fuente
18
No veo cómo mejoraría mi moral si me "degradan" para trabajar en el sistema heredado.
Telastyn
3
Hay un par de desventajas en el tiempo de desarrollo inicial y las otras tareas específicas del equipo heredado obtienen prioridades más bajas.
Finalizado el
16
@Telastyn Si mi antigua empresa hubiera abandonado el trabajo heredado, todavía estaría trabajando allí. Claro que apesta que te roten, pero apesta aún más saber que nunca te rotarán simplemente porque necesitan un desarrollador heredado.
BeardedO
8
@Telastyn y Christian y otros: es tu problema si lo ves como una degradación. Trabajar en sistemas heredados es un desafío en sí mismo que puede brindarle una experiencia increíblemente invaluable para usar en su beneficio en el desarrollo de campos verdes. El desarrollo greenfield realmente debería tener mucho menos "credibilidad" de lo que tiene, ya que es mucho más fácil que tratar de crear nuevas características en una base existente, incluso una sin mucha deuda técnica. El desarrollo del campo marrón es donde se encuentran los verdaderos artesanos y mujeres. Sí, los encuentras en otro lugar también, pero no en los endurecidos en el campo de batalla.
Marjan Venema
8
@MarjanVenema - Lo siento, hacer algunos trabajos de mantenimiento en Cobol no va a avanzar en mi carrera. Claro, el trabajo puede necesitar realizarse e incluso puede ser una experiencia valiosa, pero si mi gerente me traslada a ese tiempo completo, tendré mi currículum lo antes posible. El quid de la cuestión es que algunos desarrolladores van a percibir esto como una degradación, independientemente de lo que realmente es. Equilibrar esta percepción con el deseo de polinizar cruzado no es mi problema, es el problema del gerente; Ese es su trabajo .
Telastyn
6

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.
JohnMark13
fuente
Creo que así es como termina en la mayoría de las empresas. Objetivos elevados, pero las demandas de un cambio rápido y una evasión mínima de costos inmediatos generalmente impiden el entrenamiento cruzado y el desarrollo cruzado debido a la pérdida de productividad de poner a alguien nuevo al día en un proyecto.
BBlake
2
@BBlake Sí, desafortunadamente ese es el caso. Desafortunadamente, porque es una miopía y un riesgo bastante alto para una empresa "restringir" el conocimiento de sistemas importantes a un número menor de personas.
Marjan Venema
1
Desafortunadamente, la mayoría de las empresas, incluido el principal banco mundial que recientemente dejé para trabajar en otro lugar, están más interesadas en el resultado final de este proyecto o semana o ciclo presupuestario, que en la planificación anticipada de los costos que ocurrirán cuando un desarrollador sénior ( como yo) se va. Sin presupuesto para capacitación cruzada en aplicaciones, solo tenía una familiaridad avanzada. Agregue las docenas de horas de trabajo desperdiciadas rastreando problemas de producción que podría haber resuelto en un par de horas porque conocía los sistemas. Miope, pero esa es la forma corporativa.
BBlake
@Marjan: Estaría dispuesto a apostar que los costos incurridos por tener que hacer entrenamiento cruzado regularmente serán mucho, mucho más altos que los costos de entrenar a un nuevo empleado según sea necesario si alguien se va. Ahora, si todo un equipo se va, entonces ese es un asunto diferente.
Dunk
1
@ Dunk: No sé si lo haría. El entrenamiento cruzado no tiene que ir tan lejos como hacer que el entrenamiento cruzado sea un experto en el campo que no es directamente suyo. Solo tiene que ir tan lejos como para asegurarse de que el negocio no se vea en apuros de inmediato y corra el riesgo de perder clientes cuando los expertos de campo se vayan causando que el desarrollo en ese campo se detenga. Nadie es insustituible, pero los negocios corren riesgos cuando el conocimiento o las habilidades importantes se restringen a muy pocas personas. Y los costos de que ese riesgo se convierta en realidad pueden ser muy, muy altos.
Marjan Venema
4

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).

ozz
fuente
Para empezar, me gusta la idea de intercambiar solo 1-2 desarrolladores. Eso ayudará a reducir el impacto negativo inicial en la productividad.
superM
Estás tratando con desarrolladores de software, no con personas normales. Los desarrolladores de software tienden a ser lógicos. No se pueden manipular tan fácilmente como el público en general incorporando ideas como las anteriores. Otros trucos son más efectivos en ellos (por ejemplo, monitores más grandes, computadoras más rápidas) pero no engaños políticos, como esta idea está tratando de hacer. Será negativo para aquellos en el nuevo equipo de desarrollo, pase lo que pase. Las promesas de recompensas (es decir, ver arriba) es la única forma de encubrir el mal gusto. Por supuesto, será genial (al principio) para los chicos de mantenimiento, hasta que se den cuenta de que no están preparados.
Dunk
2

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).

Dainius
fuente
esta publicación es bastante difícil de leer (muro de texto). ¿Te importaría editarlo en una mejor forma?
mosquito
2

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.

Martin Maat
fuente
0

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.

dietbuddha
fuente
1
"Siempre y cuando el equipo no sea demasiado grande" es clave aquí, creo; Si cada equipo tiene 10 personas, es muy probable que un equipo de 20 personas sea demasiado grande. Además, si hay una separación física entre los equipos (el OP no especifica), entonces no funcionará como un solo equipo y hará que las cosas estén más desorganizadas. Esto definitivamente podría funcionar, pero depende de la situación (¿se pueden fusionar los equipos de manera efectiva?) Y también de los objetivos de la administración (la fusión es más o menos permanente, agregará más recursos pero no logrará los mismos fines que un proyecto rotación).
Aaronaught
0

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.

Pragnesh Karia
fuente
3
Veo muchas afirmaciones calvas que se hacen aquí. Algunos de ellos no tienen casi nada que ver con la rotación ("¿la gerencia conocerá la fuerza y ​​la debilidad de un desarrollador en particular"?), Otros tienen una frase incómoda o simplemente no tienen sentido ("todos los miembros del equipo trabajan en equipo y aumentará el rendimiento del proyecto "?). ¿En qué se basan todos estos puntos? Tienes una fuente? ¿Es una experiencia personal? Si es así, ¿qué experiencia? ¿Su "perspectiva empresarial" proviene de la experiencia como gerente o líder de equipo? ¿Realmente has visto alguna de estas cosas funcionar en la práctica?
Aaronaught
1
La mayoría de estos beneficios propuestos realmente parecen estar relacionados con el simple hecho de estar en un equipo en lugar de ser rotados entre equipos ...
Aaronaught
primero "La gerencia conocerá la fortaleza y debilidad de un desarrollador en particular". en realidad es lo contrario, porque es mucho más fácil ocultar tus debilidades cuando te mudas de un lugar a otro, siempre hay más personas / software a los que culpar, por qué fue tarde, con errores, no hecho.
Dainius
No hay forma en h ... de que el rendimiento del proyecto no se vea muy negativamente afectado. ¿Por qué creería usted que el desempeño de un proyecto sería "mejorado"?
Dunk