¿Cuánto tarda un equipo de desarrollo nuevo en ser productivo? El ramp-up que casi nadie presupuesta

Un equipo de desarrollo recién armado tarda, en promedio, entre varias semanas y unos cinco meses en llegar a su ritmo real de entrega —no el día en que empieza a escribir código, sino el día en que deja de perder tiempo entendiendo el sistema, el negocio y a las mismas personas con las que tiene que coordinarse. La investigación disponible sobre roles profesionales en general ubica ese tramo en hasta 20 semanas (Rollag, Parise & Cross, MIT Sloan Management Review, 2005). Para un equipo completo —no una sola persona— el mismo problema se repite multiplicado por cada persona nueva que hay que integrar al mismo tiempo.

Ese tiempo de ramp-up casi nunca aparece en una propuesta comercial ni en el cronograma de un proyecto. Se paga en semanas de menor output, código que hay que revisar dos veces y decisiones que tardan más de lo esperado —no porque el equipo sea malo, sino porque todavía no conoce el terreno. La mayoría de lo que existe escrito sobre esto está pensado para Recursos Humanos —checklists de onboarding, planes de 30-60-90 días—, no para la empresa que tiene que decidir, antes de firmar, qué modelo de contratación minimiza ese costo.

¿Qué es exactamente el ramp-up de un equipo de desarrollo?

El ramp-up es la curva de tiempo entre que un equipo se suma a un proyecto y el momento en que su output —código entregado, decisiones tomadas, problemas resueltos— deja de estar limitado por lo que todavía no sabe. Tiene tres capas que se aprenden en paralelo, no una sola: el código (arquitectura, convenciones, deuda técnica heredada), el negocio (qué problema resuelve el sistema, quién lo usa, qué restricciones no están escritas en ningún documento) y el equipo mismo (cómo se coordina cada persona, quién sabe qué, qué acuerdos tácitos ya existen). Un equipo que arranca de cero tiene que resolver las tres capas al mismo tiempo que ya se espera que entregue.

¿Cuánto tarda, en la práctica, un equipo nuevo en llegar a su ritmo real?

El estudio más citado sobre esto es el de Kevin Rollag, Salvatore Parise y Rob Cross, publicado en MIT Sloan Management Review en 2005: encontraron que el tiempo para alcanzar productividad plena en un rol profesional puede llegar a las 20 semanas —casi cinco meses—, y todavía más en roles de mayor responsabilidad. Ese número describe a una persona incorporándose sola a un equipo que ya funciona. Cuando lo que se arma es el equipo completo —varias personas coordinándose entre sí por primera vez, sin nadie del otro lado que ya conozca el terreno—, no hay una sola curva de aprendizaje: hay tantas como personas, superpuestas.

Google llegó a una conclusión parecida por otro camino. En un estudio interno de su propio equipo de People Analytics, un cambio simple en el proceso de onboarding —un checklist enviado al manager en el momento justo, antes de que la nueva persona arrancara— redujo el tiempo hasta productividad plena en un mes completo, un 25% más rápido que el proceso anterior (Google re:Work, “A data-driven approach to optimizing employee onboarding”). El dato importa por lo que implica al revés: si estructurar mejor el proceso ahorra un mes entero, es porque sin esa estructura el ramp-up ya se estaba comiendo ese mes solo.

¿Por qué sumar gente no acorta un proyecto atrasado?

La respuesta clásica es la Ley de Brooks: agregar programadores a un proyecto de software que ya está atrasado lo atrasa todavía más (Fred Brooks, The Mythical Man-Month, 1975). La razón no es que la gente nueva no sirva —es que, durante el tramo de ramp-up, consume tiempo del equipo que ya está entregando: alguien tiene que explicar el sistema, revisar el código de quien recién llega, responder las mismas preguntas más de una vez. La capacidad del equipo baja antes de subir.

¿Por qué el costo crece más rápido de lo intuitivo?

Brooks también describe la razón matemática: la cantidad de canales de comunicación posibles entre n personas es n×(n-1)/2. Con 5 personas hay 10 canales; con 10 personas, 45. Cada persona que se suma no solo tiene que aprender el proyecto —también multiplica la cantidad de conversaciones necesarias para que todos sigan alineados. Es la misma razón, en otra forma, por la que un equipo que ya se conoce entre sí llega con ese problema resuelto de antemano: los canales ya existen, no hay que abrirlos todos de nuevo.

¿Por qué este costo casi nunca aparece en el presupuesto de un proyecto?

Porque no se ve como una línea aparte: se disuelve dentro de los primeros sprints, y ahí se confunde con “está lento para arrancar” en vez de nombrarse como lo que es. La mayoría del contenido que existe sobre onboarding está escrito para Recursos Humanos —pensado para un puesto individual que se suma a una estructura que ya funciona—, no para la pregunta que en realidad tiene que responder una empresa antes de contratar: de los modelos disponibles para sumar capacidad de desarrollo, ¿cuál minimiza este costo específico, no el costo por hora?

¿Un squad que ya trabajó junto también tiene ramp-up?

Sí —ninguna cantidad de historial compartido elimina la parte del ramp-up que depende del proyecto puntual: el código específico de esa empresa, su negocio particular, sus restricciones no escritas. Eso no lo evita nadie, ni siquiera un equipo con años juntos. Lo que un squad que ya trabajó junto sí elimina es la otra mitad del problema: la coordinación interna. No tiene que descubrir en el camino quién es bueno en qué, cómo prefiere trabajar cada persona, o qué pasa cuando alguien no está de acuerdo —esa parte ya está resuelta antes de que el proyecto empiece, y es exactamente la parte que un equipo armado ad hoc tiene que reconstruir desde cero, aunque cada persona individual sea sénior.

En Zenit, Kaizen achica la otra mitad del ramp-up —la del negocio, no la del equipo— documentando el contexto real del proyecto antes del match: qué existe, qué falta, qué restricciones no están en ningún documento. El squad todavía tiene que aprender el código específico de la empresa, pero no arranca a ciegas ni tiene que reconstruir su propia coordinación interna al mismo tiempo.

El tiempo de ramp-up nunca llega a cero —ni con el mejor squad ni con el mejor proceso de onboarding. Pero hay una diferencia real entre pagarlo una sola vez, del lado del negocio que el equipo todavía no conoce, y pagarlo dos veces: una por el negocio y otra por un equipo que tampoco se conoce a sí mismo.