Por qué los equipos con mucha gente (más de 7) son menos productivos. O por qué tener equipos pequeños es una buena práctica (ágil, además)

Uno de los mayores, y más comunes, errores en gestión de proyectos software viene de tener un tamaño de equipo erróneo. Aún hay quien, erróneamente, piensa que un equipo… cuanto más grande mejor, que aumentar el número de personas de un equipo es la única manera, la manera más racional y eficiente, de generar más trabajo, más software, y recortar tiempo.

Escribiendo estas líneas no dejo de recordar aquel equipo de desarrollo en el que trabajé hará unos 5 años, que cuando yo llegué era ya de 20 personas, y al que, por los constantes fracasos e imposibilidad de cumplir fechas y mínimos de calidad… los responsables de la empresa le añadían cada vez más y más personas. Obteniendo cada vez peores y peores resultados y con un gasto económico mayor. Quizás lo peor fue nunca lograron entender porque esto sucedía.

Cuando el tamaño del equipo crece más allá de un número de personas el tiempo de proyecto no se reduce.

Un señor llamado Lawrence Putnam, tremendamente desconocido para la mayoría de los responsables de proyectos, pero cuyos trabajos han sido tremendamente determinantes para entender la gestión de proyectos en el software, elaboró hace unos años una investigación tan importante como fascinante. Tal fue su influencia, que inspiró el porqué las metodologías ágiles siempre recomiendan trabajar con equipos pequeños (aproximadamente 7 personas).

Putnam revisó 500 proyectos software, los cuales estaban en el rango de entre 35.000 y 95.000 líneas de código. Y clasificó todos esos proyectos en cinco grupos, en función del tamaño de sus equipos, los que tenían equipos de entre 1,5 y 3 personas, de 3 a 5, de 5 a 7 y de 15 a 20.

Los resultados de Putnam evidenciaron algo que mucha gente sospechaba: cuando el tamaño del equipo crecía más allá de un número de personas el esfuerzo, lógicamente, al haber más gente, aumentaba pero el tiempo de proyecto no se reducía. Equipos más allá del rango de entre 5 y 7 personas aumentaban en esfuerzo… pero también el calendario.

Cuando el tamaño del equipo se incrementaba del rango 1,5 – 3 al de 3 – 5 el calendario, el tiempo, se acortaba y el esfuerzo se incrementaba. Cuando el tamaño pasaba de 3-5 a 5-7 ocurría lo mismo. Pero cuando se pasaba de 5-7 a 9-11 tanto el esfuerzo como el calendario se incrementaban. En el rango 15 – 20 la situación era peor.

Los equipos con un número mayor a 7 personas se veían constantemente penalizados por:

• La coordinación mayor que requerían esos equipos grandes, las mayores y más numerosas actividades de gestión.
• El incremento de las rutas de comunicación entre sus miembros, lo cual crea más errores. A más personas, más lineas de comunicación aparecen.

Esta mala práctica, la de los equipos grandes, no deja de ser otra errónea aplicación de las técnicas de gestión de proyectos para productos físicos (la construcción de casas, coches, puentes, etc., te dejo aquel post sobre este tema) al mundo del software, y de no tener claras las grandes diferencias que existen.

Quizás a alguien se le estarán pasando por la cabeza en estos momentos preguntas del tipo a “bueno, ¿y cómo aplica todo esto a empresas con 200 desarrolladores y estructuradas en equipos de 20 o 30 personas?”, pues, según todo lo anterior, si quieren lograr la máxima eficiencia deberían reestructurarse en muchos equipos de 7 personas (en vez de pocos de 30).

Y, sí, soy consiente de que las reestructuraciones y reorganizaciones de este calibre en ciertas organizaciones son casi imposibles. Pero también te digo, por si te vale de motivación, que también son muchas las que están realizando esta transformación, y muchas más son las que ya lo han logrado, y créeme, la mayoría son líderes tecnológicos en su sector.

Después de todo, quédate con una importante conclusión a recordar: los equipos entre 5 y 7 personas son los más óptimos.

• Acerca de
• Últimas entradas

Javier Garzás

Javier Garzás es Doctor (Ph.D) en Informática, con un
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.

Últimas entradas de Javier Garzás (ver todo)

• Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
• Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
• Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024