En 1975, Brooks escribió (en The Mythical Man Month), y popularizó (lo que no quiere decir que el tema hoy sea lo suficientemente conocido, menos aún en los ámbitos TM, Troglodita Management), aquello que añadir gente a un proyecto software con retraso… hace que se retrase más, asunto que posteriormente se ha conocido como la Ley de Brooks.
Aunque Brooks reconoció explícitamente que la «Ley» es una «simplificación bárbara», que hay que matizar según el caso, destacó dos factores por los que la introducción de los recién llegados frena a los presentes:
– El tiempo que se necesita para que aprendan lo suficiente como para ser productivos, que, además, requerirá durante ese periodo de las personas que ya estaban, que han de enseñar a los nuevos.
– El aumento de las vías de comunicación, lo que implica, entre otros, más gasto en coordinación del trabajo, gestión, etc.
Estoy seguro de que muchos de los que estáis leyendo esto habréis sufrido la Ley de Brooks, yo siempre que sale el tema cuento aquel proyecto, aquel en el que me tocó lidiar con que el cliente, por los continuos retrasos, se empeñaba en pagar e incorporar a nuestro equipo grupos de 10 becarios: “-Pero si os pago yo gente… ¿cómo me podéis decir que eso no acelerará la entrega?-“. Pobre hombre (y me refiero a este quien aquí escribe).
No obstante, y aunque nuestro subconsciente, experiencia y batallas, nos dicen que esto de “añadir gente a un proyecto software con retraso hace que se retrase más” es cierto, la cosa no es tan trivial. Y a día de hoy, casi 40 años más tarde, la pregunta de cómo y cuándo introducir nuevas personas a los proyectos de software sigue sin estar clara.
Añadir gente retrasa el proyecto… dependiendo de cuando se añadan
¿Retrasa siempre añadir gente? Depende del momento. Organizaciones como la NASA recomiendan comenzar los proyectos software con un número pequeño de personas de alto nivel e ir aumentando la plantilla después de los requisitos iniciales y el diseño.
Además, todos hemos participado en proyectos en los que no se añade gente, en ocasiones porque el proyecto va «tarde», porque no había tiempo suficiente para que puedan ser productivos, etc., pero resulta que meses más tarde todo el mundo se echa las manos a la cabeza diciendo: “Que bien nos vendrían ahora que ya estarían formados”.
En cualquier caso, como ya comentamos, independientemente del momento temporal, hay un tope de máximo de personas que, superado, hace que el proyecto no gane en productividad, recuerda aquello de 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)
Aparentemente, es beneficioso añadir gente hasta un cierto punto en el calendario del proyecto, después la adición de personas se convierte en perjudicial.
Realmente, la Ley de Brooks aplica y habla de las fases finales de un proyecto, “cuando va retrasado”, la pregunta es cómo saber si estamos en las fases finales de un proyecto.
Decía McConneell que realmente aquí, detrás de todo esto, lo que había era un problema de incapacidad por parte de los responsables de los proyectos de saber en qué estado estaba el proyecto… “¿al 75%? ¿al 25%?…” Como casi la mayoría de los responsable de proyectos piensan que “ya casi está”, “estamos al 90%”, efectivamente, en ese momento, no merece la pena añadir gente. Pero la realidad es que ese 90% realmente es el 50% del tiempo del proyecto.
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Esto es válido en general para un proyecto y no solamente uno que implique a informáticos. La prueba es que es más fácil llevar una camilla entre dos personas que entre 30 aunque a los 30 les toque menos peso no hay manera de que agarren la camilla bien