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.
[box type=»info»] Cuando el tamaño del equipo crece más allá de un número de personas el tiempo de proyecto no se reduce[/box]
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).
graficaMarca
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 trasformació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.
 

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “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)”

  1. Saludos, los equipos con mucha gente (más de 7) son menos productivos, ya que el tiempo y el esfuerzo para culminar el proyecto se incrementan.

  2. «Saludos, un equipo pequeño es más productivo, ya que minimiza el desperdicio de tiempo y se evitan elevados costos.»
    Cuando es sólo una persona es cuando más se optimiza la comunicación y menos distracciones hay, es el equipo más productivo, y si no hay nadie ya no te digo, es la optimización completa y en costos ya no te digo, cero en salarios.

  3. «…son los más óptimos.»
    No hay más óptimo, es óptimo o no. No puedes llegar a ser más que lo mejor. Podrías decir más eficiente, más eficaz, etc.
    Por lo demás, interesante artículo. Gracias.

  4. El rendimiento de un sistema de trabajo en modo colaboración como el que se propone no entiende solo de cantidad de personas necesarías, entiende de sistemas de colaboración de alto rendimiento, concreción de objetivos, protocolo a seguir y trabajadores cualificados necesarios para ejecutarlo.
    Y para darse cuenta de eso no es necesario revisar 500 proyectos (como tampoco en necesario revisar 500 inventos de máquinas con rendimiento superior a 1).
    Dicho de otro modo, el esfuerzo no convertido en trabajo se queda en el simple esfuerzo y eso es de un rendimiento 0, tanto si han sido 7 como si han sido 700.000 las personas que consideremos que eran necesarias para su ejecución: el error conceptual es anterior a toma de decisiones.
    Podrían ser más de 7 o de 70 las cantidades que «cuadren»… obviamente sí, pero no en todos los casos.
    Saludos 🙂

  5. Claras y contundentes cifras. En Scrum, ¿esos 7 se refieren a los ingenieros (programadores) o a la totalidad del equipo (Scrum Master, Product Owner? De antemano, gracias.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *