¿Cuál es la tasa normal de rotación entre los desarrolladores y afecta la productividad?

¿Cuál es la tasa normal de rotación entre los desarrolladores?

Tu tasa de rotación me parece una locura. Es más lo que esperaría de los agentes de callcenter. Si realmente quiere decir que necesita 35 empleados para mantener su nivel constante de 25 desarrolladores activos, tendría una tasa de fluctuación del 140%. Debe estar en algún lugar entre 10 y 20%. (En 2017, en el sector de TI, encontré una tasa de rotación general del 16 % para Alemania y (2) 18 % en EE. UU. en 2016)

y ¿afecta la productividad?

Sí, afecta profundamente la productividad. Solo una estimación aproximada rápida y sucia:

1. Sus nuevos desarrolladores tienen que aprender la pila tecnológica, el proceso de desarrollo, los requisitos comerciales, etc. Digamos que les lleva la mitad de su tiempo durante los primeros 6 meses (100%-0% en una reducción lineal). Eso es ~ 3 meses perdidos allí mismo.

2. Obtener una atmósfera de trabajo, una dinámica de equipo y una configuración de la oficina correctas puede tener un gran impacto en la productividad de los desarrolladores; ¡algunas investigaciones (1) sugieren un factor de 10!

Entonces, si su desarrollador promedio se queda solo alrededor de 8.5 meses, primero aprendiendo y luego desmotivándose rápidamente, ¡su equipo de 25 tiene la productividad de un equipo feliz y profesional de 2-3 desarrolladores!

Editar debido a los comentarios: algunos trabajos solo tienen una tasa de rotación natural más alta. Por lo general, se trata de trabajos de baja calificación y salarios bajos. Esos trabajos a menudo son asumidos por personas hasta que tienen algo mejor, por ejemplo, por estudiantes, etc. Eso no quiere decir que esto sea algo bueno en cualquier lugar. ¡Reemplazar a un empleado siempre le cuesta dinero y normalmente perjudica la calidad y la productividad!

¡Cualquier negocio que considere a las personas como prescindibles se perjudicará a sí mismo!

Si habla con la gerencia sobre esto, a veces ayuda expresarlo en términos monetarios. Además de los costos de contratación, también invierte dinero en el desarrollo profesional y el aprendizaje del conocimiento del dominio de cada empleado de manera constante a lo largo del tiempo. Este es el capital humano de la empresa. Una vez que el empleado renuncia, pierde esta inversión. Esto es casi lo mismo que no hacer cambios de aceite en la flota de su empresa y, en cambio, hacer que sus vehículos se descompongan y los reemplacen cada medio año. ¡Puedes perder fácilmente millones de esta manera!

Además, no desea llegar a la fluctuación cero. Una pequeña afluencia de nuevas ideas es algo bueno y no todas las personas encajarán en el equipo para siempre. Lo peligroso es que, con un ambiente de trabajo tan tóxico, probablemente esté perdiendo a las buenas personas y solo mantenga a aquellos que no pueden encontrar un trabajo mejor o han encontrado la manera de seguir cobrando mientras se distancian tanto de la empresa que toman. poco interés en sus objetivos (han dimitido por dentro). (3)

(1) Como se explica en el libro "Peopleware" de Tom de Marco y Timothy Lister

(2) https://www.glassdoor.com/employers/blog/turnover-retention-rates/

(3) Artículo de blog sobre la pérdida de talento, gracias a @Josh Johnson

[...] el grupo está plagado de retrasos en los proyectos y porque un gerente senior le gritó al gerente del grupo de tecnología por no poder entregar los proyectos a tiempo y eso provocó una queja y porque el gerente es una mujer y el gerente senior es un hombre, ese problema de gritos debe solucionarse.

No es absolutamente un problema con la facturación o los desarrolladores. ¡ Es un ambiente tóxico y el consiguiente problema de MP-ing incorrecto! Debe arreglarse lo antes posible para que el proyecto sea recuperable .

Manager quiere más desarrolladores ya que todos son nuevos en el código base.

La ley de Brooks (gracias @Benjamin pero usé un enlace diferente) demuestra que lo mejor que puede hacer para matar el proyecto es contratar más personal, con la falsa creencia de que recuperará los retrasos que acumuló.

Cada nuevo empleado es nuevo en la base de código y todos necesitan aumentar.

Permítanme agregar una cita icónica sobre lo que está sucediendo en su empresa.

Si dejas embarazadas a 9 mujeres hoy, tendrás 9 bebés al final de los 9 meses, no 1 bebé después de un mes.

En el ámbito de la gestión de proyectos, agregar nuevos recursos requiere pausar un recurso existente de la actividad (codificación) para capacitar a las nuevas contrataciones. Esto tiene el efecto inmediato de retrasar el proyecto, lo cual es lo opuesto a las expectativas de su gerente.

Un proyecto que sufre no se beneficia de recursos adicionales, especialmente en la industria del software: simplemente sufrirá las nuevas contrataciones. No voy a ser intencionalmente grosero, pero parece que su administración proviene del mundo de la agricultura y la ganadería, donde puede contratar una nueva cosechadora de la noche a la mañana.

Al final, su facturación es una locura porque el proyecto tiene problemas de gestión. No puedo entrar en los detalles de la estrategia de remediación, pero seguramente renegociar los plazos sería mi primera opción. Y al final, en este punto el proyecto es tan crítico que debe ser salvado o asesinado.

Según mi experiencia, algunos proyectos, por razones políticas o de marketing, no pueden permitirse un retraso.

Si los estás perdiendo a los 8 meses, están decidiendo irse a los 6.

Supongo que la mayoría de la gente renuncia a otros trabajos. Por lo general, lleva algún tiempo encontrar otro que busque a tiempo parcial y suponga que son algo selectivos. Digamos un mes asumiendo que son buenos desarrolladores. Agregue otro mes para cobrar un cheque de pago mientras espera que comience el nuevo trabajo. Eso hace que la decisión de irse a los 6 meses.

Sus desarrolladores básicamente le están dando el período de prueba y luego deciden irse a otro lado.

Pero el amigo desarrollador que tengo en el equipo dice que "tenemos suerte de mantenerlos tanto tiempo".

Está comentando sobre su empresa, no sobre el mercado de desarrolladores en general. Apuesto a que él mismo está buscando trabajo.

En cuanto a si la alta rotación de desarrolladores daña el proyecto, he estado trabajando únicamente en un sistema durante los últimos 8 meses. El otro desarrollador del proyecto ha estado aquí un año. El proyecto tiene 4 años. Estimaría que 1/4 del trabajo que he hecho se ha duplicado de una forma u otra, ya que no sabíamos que la funcionalidad ya se había creado. ¿Suficientemente problemático para ti?

Está claro cuando haces la pregunta que sabes que tienes un problema de rotación. Esa no es información nueva. Muchas respuestas se han orientado hacia los impactos y describen el costo en el que incurre este tipo de facturación. Toda esa es información realmente excelente, y nada de eso te ayuda a solucionarlo.

Genial, tu problema tiene un gran impacto y necesitas solucionarlo. ¿Cuál es tu problema, sin embargo? La rotación es un síntoma, no es el problema.

Tienes un problema cultural.

Tienes personas que no confían ni se respetan entre sí, y claramente no se les anima a hacerlo. Si bien las estadísticas muestran el volumen de negocios de la organización, ¿cuántas personas tiene que hayan estado allí más de 5 años? Estas pueden ser algunas de sus áreas problemáticas. ¿Cuáles son sus planes de desarrollo? ¿Cómo están subiendo de nivel tus mandos medios a tus colaboradores individuales? ¿Cuál es su camino hacia la empatía por sus compañeros?

1. Necesitas eliminar inmediatamente el comportamiento hostil o tóxico.
2. Identifique a sus personas más importantes. ¿Son de confianza? ¿Son respetuosos? ¿Cómo levantan a las personas que los rodean? Si no puede responder estas preguntas con afirmaciones, entonces este es su primer punto de solución. Necesitan ser nivelados en habilidades blandas, liderazgo y empatía. Si no lo hacen, necesitan ser reemplazados.
3. Escuche los puntos de dolor. Sus colaboradores individuales tendrán MUCHAS quejas. Átelos en puntos de proceso comunes y utilícelos para identificar las mejoras de proceso que aliviarán ese dolor.
4. Separar a las personas del problema. Describa el problema a alguien que no tenga idea de lo que está hablando. No use nombres; usar solo roles. Si no puedes separar a la persona del problema, la persona es el problema .

Genial, has empezado a arreglar el proceso. ¿Qué pasa con la gente?

La gente en general quiere sentirse necesitada y valorada. Quieren que su trabajo le importe a otra persona. Quieren ser mejores en lo que hacen y quieren poder hacer más. Logran esto a través de sus gerentes y supervisores.

1. ¿Cómo son sus programas de formación?
2. ¿Qué incentivos para el avance están disponibles?
3. ¿Cómo se recompensan las acciones exitosas?
4. ¿Cómo se responsabiliza a las personas por los errores?
5. ¿Cómo se promueve su trabajo a un lugar de valor?

Tienes que ser capaz de responder a estas preguntas de manera muy convincente. Si no puede, entonces su gente se va porque la empresa no los valora de la forma en que ellos quieren ser valorados.

¿Qué pasa con la gente tóxica/enojada?

Mucha gente le dirá que necesitan ser despedidos. Mucha gente está dispuesta a renunciar a ellos. Alguien que se enfada o se frustra es alguien que te muestra cuánto le importas. Es posible que no les importen las cosas correctas en este momento, pero están interesados ​​​​en lo que hacen y en quiénes son en su posición. Os animo a no daros por vencidos con estas personas. He invertido en mis individuos tóxicos en el pasado y ha dado como resultado enormes dividendos. Estas personas se han convertido en algunos de mis mejores empleados.

1. Necesitas escucharlos. Escuche sus problemas. Ayúdalos a superarlos. Esto lleva tiempo. Se necesita aliento.
2. Conéctelos con sus compañeros. Edúcalos sobre cómo su comportamiento está afectando a las personas que los rodean. Espera algo mejor de ellos. Dígales que eso no es aceptable y que necesita su ayuda.
3. Encuentre sus puntos de valor y ayúdelos a alcanzarlos. Si se trata de obtener trabajo frente a un cliente, haga lo que pueda para ayudarlo a hacerlo. Si se trata de interactuar con otras áreas de la organización, busque oportunidades para que esto suceda.
4. Identifique su comportamiento tóxico y abordelo de inmediato cuando suceda. No tienes que martillar a la gente. Solo deja en claro que estás mirando y espera algo mejor.

Guau, hay mucho que hacer aquí. ¿Soy yo el problema?

Podrías serlo. Es posible que no confíen en la empresa o en el liderazgo. Si está en la gestión, es fundamental identificar esto. Muchas veces esto se debe a que los mensajes de liderazgo no coinciden con las acciones de liderazgo. A menudo es solo la percepción de falta de respeto que viene con la separación en la información.

1. Sea lo más honesto y transparente que pueda con sus padres.
2. El liderazgo necesita mantener un mensaje cohesivo y consolidado.
3. La gerencia necesita respetar sus contribuciones individuales y hacer lo que sea necesario para elevarlas.

El liderazgo de servicio siempre ha funcionado para mí. Si sus colaboradores individuales creen que el trabajo de la gerencia se hace en beneficio de ellos, levantarán montañas. Se necesita honestidad. Se necesita creencia. Si se espera que las personas se comporten con un estándar más alto, sus líderes deben ejemplificar ese estándar. Si desea que sus colaboradores individuales sean respetuosos y empáticos, entonces debe ser respetuoso y empático. Si quieres que trabajen duro, debes trabajar duro. Cultivarás la cultura que te mereces, no la cultura que quieres.

Hasta que se arregle la cultura, la gente seguirá saliendo y la rotación seguirá estando en niveles épicos.

Se necesitan 35 personas al año para mantener ocupados 25 puestos.

Incluso con el trabajo más aburrido e insatisfactorio imaginable, eventualmente debería terminar con un grupo de personas a las que no les importa eso y que están felices de llegar por la mañana, irse por la noche y tomar su dinero al final de la jornada. el mes.

no lo hiciste Eso significa que sus trabajos no solo no atraen a las personas, sino que hay algo que las aleja activamente. ¿Dos jefes acosando sexualmente a todos sin excepción? ¿Violencia real en el lugar de trabajo? ¿Un olor desagradable en la oficina que me hace pensar en gente muerta debajo de las tablas del piso? Debe haber algo así. La tasa de deserción del 140% simplemente no es normal.

¿Impacta la productividad? ¿Qué productividad? No esperaría que hubiera ninguna productividad allí en absoluto. Tienes recién llegados que primero tienen que aprender el medio ambiente, y no hay nadie con experiencia que pueda enseñarles. Ninguna productividad de las nuevas personas y reducción de la productividad de las no tan nuevas durante cuatro meses. Luego, cuando están casi listos para hacer algún trabajo, la generación anterior se va y el siguiente grupo debe aprender. Una vez hecho esto, han tenido suficiente y se van. No se realiza ningún trabajo.

Tienes mucho trabajo por delante. Diría que necesita de ocho a diez verdaderos profesionales con buenos salarios que puedan salir adelante, pase lo que pase. Deben tener las manos libres para luchar contra cualquier obstáculo (por ejemplo, si el director ejecutivo les grita, para eliminarlo físicamente sin temor a las repercusiones). Con mano libre para tomar decisiones de desarrollo (en caso de que tenga una gestión idiota que no puede mantener las metas sin cambios durante una semana).

Si bien no hay una respuesta perfecta a la pregunta "¿Qué es una rotación normal con los desarrolladores?" (varía de una compañía a otra y todos son diferentes), diría que la mayoría de las veces los desarrolladores intentarán permanecer al menos 2 o 3 años en la misma compañía si pueden.

Se ve bien en el currículum, tienes tiempo para aprender el tema y construir una buena relación con la gente. Después de 2 o 3 años, puedes cambiar de trabajo para tener un buen aumento de salario e ir a trabajar en nuevos proyectos con nuevas tecnologías.

Si un desarrollador no se queda más de un año, significa que algo no le sentó bien. Irse tan pronto puede perjudicar su carrera:

• tendrá que justificar su permanencia por tan poco tiempo en futuras entrevistas.
• será difícil utilizar estos pocos meses de experiencia en cualquier negociación salarial. En cuanto a la carrera, es tiempo perdido.

Así que yo diría que cualquier empresa que tenga una facturación de menos de un año está haciendo las cosas muy, muy mal. Pero luego las respuestas de Daniel y usr-local-ΕΨΗΕΛΩΝ dan mejores explicaciones sobre ese tema.

Si necesita contratar 35 desarrolladores al año para cubrir 25 puestos, su desarrollador promedio permanece durante 8,6 meses. Eso es, de hecho, increíblemente corto.

Tasas de rotación como esta pueden tener un gran impacto en la productividad. Hay varios factores que contribuyen a esto:

• Según la complejidad del proyecto y su experiencia, un desarrollador necesita algo entre unas pocas semanas y unos meses hasta que alcance su máximo rendimiento, porque tiene que acostumbrarse al código base existente, su estilo de programación de co-desarrolladores, los estándares de la empresa, componentes y cosas como tales. Para tener algunas matemáticas más fáciles, supongamos que la incorporación lleva 2 meses y un desarrollador se queda durante 8 meses. En 2 años, eso es 6 meses de incorporación. Habría ahorrado 4 meses de incorporación si se hubiera quedado 2 años.
• El resto del equipo también necesita acostumbrarse al nuevo desarrollador. Esto incluye todo lo que necesita saber por motivos de gestión de proyectos: ¿Qué tan rápido es él? ¿Qué tan competente es? ¿Se comunica bien? ¿Tiene necesidades especiales? Sin toda esta información, la gestión de su proyecto se basará en suposiciones inestables.
• La alta rotación amplifica algunos problemas típicos de desarrollo de software, como procesos deficientes o documentación deficiente. Si todos saben lo que se espera de él y están familiarizados con el código base, estos puntos siguen siendo importantes, pero puedes comprometerlos. Si hace eso en un entorno de alta rotación, cada uno de los nuevos desarrolladores perderá muchas, muchas horas de su tiempo (¡y el de otros!), tratando de averiguar cómo funciona todo y qué tiene que hacer exactamente.
• El conocimiento se pierde y por lo tanto tiene que ser readquirido. "Oh, ¿necesitas saber cómo integrar X e Y? Bueno, Dave hizo esto hace 2 años, revisó las especificaciones durante un mes. Se fue, y también lo hicieron todas las personas con las que alguna vez habló sobre esto. Supongo que tienes que rehazlo. Aquí puedes encontrar las especificaciones...".
• Es mucho más difícil encontrar procesos que funcionen para su equipo, porque su equipo es algo muy volátil.

La otra parte de su pregunta, a saber, "¿Cuál es la tasa normal de rotación entre los desarrolladores", es mucho más difícil de responder. Así que haré una especie de desafío marco: no preguntes cuál es una tasa normal, pregunta cuál quieres que sea tu tasa y cómo lograrla. Su empresa es diferente de cualquier otra empresa, por lo que su respuesta puede diferir de la norma. Incluso hay algunas circunstancias excepcionales en las que una alta rotación no es un problema en absoluto.

¡Aviso! Se basa principalmente en la opinión. Puede estar sujeto al sesgo de 'evidencia anecdótica' basado en mis propias experiencias y mis conocidos. Las suposiciones más objetivas se encuentran en la sección 'resumen'.

Me gustaría publicar una respuesta desde un punto de vista totalmente opuesto.

Usted mencionó que es un banco u otra institución financiera. Es bastante normal que puedan tener un ambiente de trabajo tóxico y que tengan una gran rotación. Lo que ofrecen a cambio es un salario un poco más alto. no sé por qué Tal vez algunos banqueros todavía tienen una mentalidad corrupta de que pueden obtener todo a través del dinero, o simplemente el negocio bancario es muy rentable.

Voy a contar un poco de mi propia historia. He estado trabajando en la industria bancaria por poco tiempo (solo 4 meses). Fue poco después de los estudios porque reclutaron estudiantes a través de una especie de mercado de carreras organizado en mi universidad.

Puedo decir que ese salario era bastante impresionante, pero no ofrecía un puesto en el que pudiera desarrollar mis habilidades como quería y el ambiente era un poco tóxico. Me hizo cambiar mis planes. Decidí buscar un trabajo por un salario más bajo pero mayores oportunidades para aprender nuevas herramientas/tecnologías de programación y un ambiente de trabajo amigable.

Pero algunos de mis amigos se quedaron en esa empresa y les gustó. Disfrutaron del salario y simplemente se acostumbraron al lugar de trabajo estresante.

También conocí a algunas personas que cambiaron de trabajo de mi empresa actual a mi empresa anterior y lo disfrutan más. Es increíble, pero todos tienen sus propias preferencias personales, lo cual es difícil de discutir.

Resumen

En resumen, la alta rotación puede no ser mala bajo ciertas condiciones:

• Reclutan una gran cantidad de trabajadores jóvenes, principalmente recién graduados.
• Tienen un proceso de incorporación eficiente y tutoriales actualizados y listos para usar. Por lo general, los trabajadores que han estado trabajando durante un período de tiempo medio a corto y que acaban de incorporarse a compañeros más jóvenes. Los veteranos se mantienen enfocados en sus propias tareas importantes. Se les molesta sólo cuando es necesario.
• La mayoría de los trabajadores que han dejado la empresa son personas que llevan trabajando en ella menos de 1 año.
• Las personas que encajan en un entorno de trabajo específico permanecen allí durante años.
• Las personas que adquirieron conocimientos de dominio/negocios específicos e importantes generalmente permanecen en la empresa. Por lo general, están motivados por un mayor aumento/promoción.

Considere que hay un desajuste entre lo que le pide a la gente que haga y cómo contrata y hace las cosas. La tecnología no es, por regla general, una ciencia blanda. Si pides lo imposible, la gente se dará por vencida. Así que asegurándose de:

1. Que las expectativas puestas en tus desarrolladores sean realistas.
2. Que tus trabajadores tengan suficiente tiempo para ejecutar esas tareas.

Lo que las personas que no están acostumbradas al trabajo tecnológico no entienden es que: nada puede prepararlo exactamente para el trabajo que tiene entre manos. Excepto hacer ese trabajo. Ahora bien, es muy difícil calcular cuánto tiempo necesitaría para volverse productivo. Pero también es difícil hacer una tarea que es infinitamente grande desde tu punto de vista.

Por lo tanto, es muy importante que realmente tenga un desarrollador senior cuyo trabajo sea dividir las tareas en partes manejables. Y realmente parece que ha perdido todo su talento de coordinación, por lo que no hay nadie que ponga al día a la gente nueva.

La solución probablemente no sea aumentar el número de personas, sino disminuirlo. No puede simplemente inyectar nuevos desarrolladores a un ritmo infinito. Simplemente harán que sea imposible que aquellos pocos que podrían trabajar de manera efectiva trabajen de manera efectiva.

Otro puede ser estar constantemente abrumado por el cambio de alcance. Los trabajadores necesitan saber que están haciendo algo. Por lo tanto, deben poder tomar una parte del trabajo y hacer esa parte del trabajo. Haber hecho el trozo debe ser reconocido.

El hecho de que el fragmento ahora se considere obsoleto no es culpa de los trabajadores. Es culpa de los líderes. El trabajador ha logrado el trozo que se había propuesto y eso debería ser correcto. Por ejemplo: No es culpa del pintor si la pared de la oficina es verde cuando le pediste que pintara de verde. Aunque es posible que después de que comenzó a pintar decidió que debería ser rosa. Painter solo puede ejecutar cosas que se han acordado. Aun así, solo puedes tirar de la alfombra debajo de la persona tantas veces.

Las personas pueden irse simplemente porque su proceso no está funcionando.

He trabajado en diversas empresas, en varios países; en mi experiencia, los desarrolladores normalmente esperan permanecer en un puesto durante 2 o 3 años; luego buscan un ascenso o se van. En la mayoría de las empresas en las que he trabajado, esto parecía dar lugar a una tasa de rotación anual de alrededor del 20 %; podríamos reducir eso aumentando las recompensas financieras, mejorando las opciones de desarrollo profesional y encontrando proyectos geniales para que las personas trabajen.

Las excepciones fueron las empresas con un problema cultural: como han insinuado otras respuestas, tiene un problema cultural.

También tienes un problema de círculo vicioso.

Senior management have high, possibly unrealistic expectations.
They put pressure on middle management to deliver against those expectations.
Middle management tries what they can; adding more developers (thus bumping into Brooks' law), and then shouting.
Shouting leads to reduced morale among the team.
Reduced morale reduces productivity - unhappy people don't work as hard.
Reduced morale causes people to leave, which also reduces productivity.
Growing the team leads to a reduction in productivity through recruitment efforts, and Brooks' law.
Reduced productivity further increases the gap between expectations and output.

Enjuague y repita...

Romper este ciclo es increíblemente difícil. Este tipo de entorno crea incentivos para que las personas inviertan en política, en lugar de en la entrega: la estrategia de supervivencia se convierte en "no ser culpado por los malos resultados", en lugar de "trabajar para crear buenos resultados".

No es suficiente dejar de gritar (necesario, pero no suficiente): el equipo seguirá respondiendo a los incentivos y se irá si no les gusta el ambiente. Los desarrolladores en Toronto tienen muchas opciones.

El primer paso es obtener la aceptación de la alta gerencia de que tiene un problema y que continuar haciendo lo que está haciendo no hará que el proyecto se solucione por sí mismo mágicamente. Los problemas culturales y los círculos viciosos por lo general necesitan que la alta gerencia impulse el cambio; la mayoría de las veces, ellos definen la cultura y tienen las palancas para tirar que pueden romper el círculo vicioso.

La mejor manera que conozco de romper el círculo vicioso es encontrar una manera de restablecer las expectativas y hacer que los desarrolladores tengan un objetivo alcanzable. Una vez heredé una situación como esta y acordamos que, en lugar de preocuparnos por el alcance total del proyecto de 18 meses, elegiríamos un horizonte temporal de 3 meses y acordaríamos lo que podríamos hacer en ese período de tiempo. Negociamos un conjunto de entregables "debe/debería/no" entre la administración y los desarrolladores, y acordamos formas de resolver los problemas que los desarrolladores habían planteado ("los requisitos no son lo suficientemente buenos", "nunca recibimos comentarios útiles", "la oficina es demasiado ruidosa"), etc. Utilizamos este mini proyecto de 3 meses para restablecer la cultura y reconstruir un poco la confianza.