¿Cuánto cuesta la rotación de desarrolladores en un proyecto de software?

Reemplazar a un desarrollador que se va a mitad de proyecto cuesta más que un mes de búsqueda. La cuenta real suma tres partes: reclutar y contratar a alguien nuevo, el tiempo que esa persona tarda en rendir al nivel de quien se fue —casi nunca son días, son semanas o meses—, y el conocimiento del proyecto que se pierde porque nadie más lo tenía documentado en ningún lado. Según el Work Institute (Retention Report 2024, sobre más de 20.000 entrevistas de salida), cada renuncia voluntaria le cuesta en promedio a la empresa el equivalente al 33% del salario anual de esa persona, y ese número crece cuanto más crítico es el conocimiento que se va con ella.

En un proyecto de software esa cuenta suele quedarse corta. Los equipos suelen ser chicos, cada persona termina siendo dueña de una porción grande del sistema, y perder a alguien no solo abre una vacante: también frena el milestone en el que esa persona estaba trabajando hasta que alguien más entiende esa parte del código.

¿Qué es exactamente la rotación de desarrolladores en un proyecto (y en qué se diferencia de la rotación general de una empresa)?

La rotación de desarrolladores que le importa a un proyecto en curso no es la métrica anual que mide Recursos Humanos —cuántas personas del equipo de ingeniería se fueron en el año—, sino algo más puntual: que alguien con una porción específica del contexto del proyecto se vaya antes de terminar los milestones que tenía asignados. Pasa con un empleado in-house que renuncia, con un freelancer que consigue un contrato mejor pago y corta la relación de un día para el otro, y con un integrante de un equipo de outsourcing al que la consultora reasigna a otro cliente sin aviso. El resultado es el mismo en los tres casos: el proyecto pierde a la persona que entendía por qué se tomó determinada decisión de arquitectura o qué se probó con el cliente y no funcionó, justo cuando esa información importa.

¿Cuánto tarda un reemplazo en rendir al mismo nivel que la persona que se fue?

Más de lo que suele planificarse. DX, la plataforma de métricas de productividad de ingeniería que usan cientos de equipos, mide el tiempo hasta el décimo pull request de una persona nueva como proxy de cuándo empieza a rendir de verdad: ese número bajó de 86 días en el primer trimestre de 2024 a 33 días a fines de 2025, gracias sobre todo a la adopción de herramientas de IA en el onboarding. Incluso con esa mejora, sigue siendo más de un mes de ramp-up real antes de que alguien nuevo aporte al ritmo del resto del equipo —y ese mes no es tiempo muerto: es tiempo en el que el resto del squad tiene que explicar el proyecto en vez de avanzarlo.

¿Qué conocimiento se pierde cuando alguien se va a mitad de proyecto?

El problema no es solo el tiempo de ramp-up: buena parte de lo que esa persona sabía nunca estuvo escrito en ningún lado. Según el Workplace Knowledge and Productivity Report de Panopto (2018), un estudio sobre más de 1.000 trabajadores de EE.UU., el 42% del conocimiento que alguien usa a diario en su rol es exclusivo de esa persona —nadie más en el equipo lo aprendió ni lo tiene documentado. Cuando esa persona se va, ese 42% no se transfiere solo: hay que reconstruirlo, casi siempre reconstruyendo primero un problema que ya se había resuelto una vez.

• Por qué se tomó una decisión de arquitectura y qué alternativas ya se habían descartado
• Qué se probó con el cliente y no funcionó, para no repetirlo
• El estado real de un milestone que “ya casi está” según la última reunión
• El acceso y el conocimiento operativo de los servicios que solo esa persona tocaba

¿Por qué el desarrollo de software tiene más rotación que casi cualquier otra industria?

No es un problema nuevo ni exclusivo de esta década: ya en 2017 el software lideraba la rotación entre todas las industrias relevadas por LinkedIn, con un 13,2% anual (LinkedIn Workforce Report, 2018) —el resultado combinado de una escasez de talento técnico que todavía no se resolvió y de un mercado laboral remoto que hace mucho más fácil cambiar de proyecto sin cambiar de ciudad. Ese patrón estructural es la otra cara de un problema que ya cubrimos en detalle: la mayoría de los equipos tiene un bus factor más bajo de lo que cree, justo en la industria donde más probable es que alguien clave se vaya.

¿Un squad que ya trabajó junto absorbe mejor una salida que un freelancer o una consultora armada para el proyecto?

Cuando un freelancer corta la relación, no hay nadie más que herede su contexto —hay que empezar de cero con otra persona. Una consultora que arma un equipo nuevo para cada cliente tampoco parte de un lugar muy distinto: si alguien de ese equipo se va, el resto todavía está construyendo el terreno común que hace que el conocimiento circule en vez de acumularse en una sola cabeza.

Un squad que ya entregó proyectos juntos antes tiene ese terreno común construido de entrada: las decisiones de arquitectura, el criterio de código y el contexto de cliente ya circularon entre varias personas en proyectos anteriores. Eso no vuelve a nadie irreemplazable —ningún equipo lo es— pero sí baja cuánto se pierde cuando una persona puntual se va, porque el conocimiento nunca dependió de una sola cabeza para empezar.

¿Cómo se protege un proyecto de la rotación sin poder evitarla del todo?

Ninguna plataforma ni ningún proceso elimina la posibilidad de que alguien se vaya. Lo que sí se puede controlar es cuánto de lo que esa persona sabía sobrevive a su salida. Eso pasa por dos cosas: que el avance del proyecto quede documentado como evidencia verificable —quién hizo qué, en qué milestone, contra qué criterio de aceptación— en vez de vivir solo en la cabeza de una persona y en las reuniones a las que fue, y que el equipo que contrataste tenga, desde el vetting inicial, una forma probada de responder si alguien puntual deja de estar disponible.

En Zenit eso se resuelve con dos piezas del mismo sistema: ZenitRank verifica el historial de cumplimiento de cada squad antes de que aparezca como opción en un match, y si un squad no puede seguir con un proyecto en curso, el mecanismo de Squad B backup transfiere el contexto acumulado hasta ese punto a otro equipo en vez de reiniciar el proyecto desde cero.

La rotación en desarrollo de software no va a bajar sola. La pregunta que sí podés controlar antes de firmar un proyecto es si el equipo que vas a contratar ya construyó, en otros proyectos, la forma de que el conocimiento sobreviva a que una persona se vaya.