En ingeniería de software, escalar un proyecto no funciona como escalar una línea de producción. Contratar más desarrolladores puede aumentar la capacidad total, pero no acelera proporcionalmente la entrega de una única funcionalidad o proyecto.

Fred Brooks capturó esta idea en The Mythical Man-Month: añadir personas a un proyecto de software retrasado tiende a retrasarlo todavía más. La conocida analogía dice que una mujer puede gestar un bebé en nueve meses, pero nueve mujeres no pueden hacerlo en un mes. La ley no trata de biología, sino de las restricciones inherentes al trabajo complejo.

Por qué añadir personas suele producir el efecto contrario

La ley de Brooks señala tres razones fundamentales:

  1. Tiempo de adaptación. Los nuevos integrantes deben aprender el código, el dominio y el contexto. Las personas con experiencia interrumpen su trabajo para ayudarlos, lo que reduce temporalmente la productividad y eleva el riesgo de defectos y retrabajo.
  2. Sobrecarga de comunicación. Los caminos de coordinación crecen rápidamente con el equipo. Tres personas tienen tres conexiones posibles; seis ya tienen quince. Reuniones, alineamientos y transferencias de contexto consumen el tiempo destinado a entregar.
  3. Divisibilidad limitada. No todo trabajo puede separarse en partes independientes. El diseño, las decisiones arquitectónicas y la integración suelen exigir una secuencia coherente. Fragmentar un problema complejo en pequeños tickets no garantiza una solución consistente.

Llega un punto en que el coste de coordinación e integración supera el beneficio de sumar más manos.

El argumento a favor de equipos pequeños y enfocados

Las prácticas ágiles llevan décadas defendiendo equipos pequeños y multidisciplinares. Jeff Bezos popularizó en Amazon la regla del equipo de dos pizzas: si dos pizzas no alimentan al equipo, probablemente sea demasiado grande.

Los equipos pequeños reducen la comunicación, deciden más rápido y mantienen una responsabilidad clara. Análisis de proyectos de software sitúan con frecuencia entre cuatro y cinco personas una franja eficiente. La cifra exacta depende del dominio, pero la dirección es consistente: aumentar el grupo no produce una ganancia lineal y puede elevar defectos y costes.

Mi número práctico: tres desarrolladores

Después de probar distintas composiciones como CTO en EITS, encontré una variante pragmática: tres desarrolladores pueden entregar resultados notables durante un sprint de dos semanas.

Un trío solo tiene tres caminos de comunicación. Puede organizarse sin coordinación excesiva y cada persona mantiene un sentido claro de responsabilidad. Es más sencillo compartir contexto, revisar el trabajo y colaborar en decisiones de diseño.

No es solo eficiencia, sino también creatividad. Los problemas complejos se benefician del foco profundo. Con demasiadas personas, el trabajo tiende a fragmentarse y se pierde la visión de conjunto. Un trío puede colaborar en arquitectura, implementación y pruebas sin perder coherencia.

Restricciones externas al equipo

Añadir desarrolladores presupone que existe suficiente trabajo paralelo. En la práctica, los requisitos de negocio, el diseño de producto y las decisiones de stakeholders suelen limitar el flujo.

Sin tareas bien definidas, los ingenieros adicionales esperan o trabajan sobre premisas frágiles, aumentando el retrabajo. La creatividad y el diseño de soluciones tampoco escalan linealmente: algunos problemas requieren ciclos de descubrimiento y decisión que no mejoran solo con más participantes.

Cómo resistir el impulso de ampliar el equipo

  • Invierte pronto. Incorporar personas al final resulta especialmente perjudicial. Si el crecimiento será necesario, hazlo cuando todavía pueda absorberse el coste de adaptación.
  • Prioriza capacidad, no cantidad. Un profesional experimentado y adecuado al contexto puede aportar más que varias contrataciones sin el repertorio necesario.
  • Aclara arquitectura y requisitos. Muchos retrasos nacen de requisitos ambiguos o límites arquitectónicos deficientes.
  • Mantén la autonomía. Cuando varios equipos pequeños trabajan en paralelo, define interfaces claras y minimiza sus dependencias.

Conclusión

La metáfora del bebé perdura porque resume la dinámica central: no todo trabajo puede comprimirse añadiendo personas. Existe un límite natural de paralelización; después, la comunicación, la adaptación y la carga cognitiva reducen la velocidad.

Antes de ampliar un equipo para cumplir un plazo, pregunta si las personas adicionales harán avanzar la entrega o solo añadirán complejidad. A veces la mejor estrategia consiste en dar a un equipo pequeño objetivos claros, autonomía y confianza para entregar.