Hay un límite en el que no puedes recortar más el tiempo de un proyecto añadiendo más gente
A la hora de planificar un proyecto, muchos responsables de proyecto ven razonable pensar que si añaden más gente al proyecto, el proyecto se terminará antes, y podrán encajarlo en esas complicadas fechas.
Lo primero que hay que tener en cuenta es que hay una temporalidad llamada imposible, por mucha gente que añadas al proyecto no podrás reducir su tiempo más allá de un tope.
Muchos investigadores han estudiado los efectos de comprimir el calendario de proyecto, todos concluyen en que acortar el tiempo de proyecto por debajo del tiempo ideal incrementa el esfuerzo de manera no lineal. Es decir, que si el tiempo ideal es 12 meses y 7 desarrolladores, no vas a poder recortar el proyecto a 7 meses con 12 desarrolladores… vas a necesitar muchos más.
La siguiente tabla es popular en el mundo de la gestión de proyectos software, elaborada por Putnam, que muestra, después de estudiar un gran número de proyectos, cómo según la reducción el tiempo se incrementa el esfuerzo.
Una de las razones de este efecto viene del desperdicio de esfuerzo que aparece por aumentar el número de miembros del equipo, que como veíamos en el anterior apartado, es un desperdicio mucho mayor, se dispara, si el equipo se incrementa en más de 7 personas.
Después de tanta investigación sobre el tema, existe el consenso de que reducir más de un 25% el tiempo ideal…es imposible.
Añadir gente a un proyecto retrasado… hace que se retrase aún más
Brooks fue director del desarrollo del famoso OS/360 de IBM, y a raíz de sus experiencias, éxitos y fracasos escribió “The Mythical Man-Month: Essays in Software Engineering”, libro al que deben su mayor fama, aunque no suficiente, frases como:
“Añadir recursos humanos a un proyecto con retraso provocará un retraso mayor”.
“En un proyecto la figura del arquitecto software es esencial”.
“Medir el progreso de un proyecto en función del tiempo que lleva desarrollándose es un error”
“¿Cómo puede un proyecto acumular un retraso de un año?… acumulando retrasos día a día”.
La principal causa de los problemas en el desarrollo software está en la planificación y distribución de recursos, la idea de que horas y recursos humanos son intercambiables lleva a que si un proyecto está retrasado la solución sea agregar más mano de obra. Pero el factor humano y las horas no se pueden conmutar como en una multiplicación: el tiempo extra que se añade por cada persona va a parar a reuniones, planes, e-mails, negociaciones, discusiones, revisiones, coordinación de reuniones, actas, explicaciones, formación, etc. Y por otro lado existen tareas que simplemente no se pueden dividir y deben ser realizadas por la misma persona.
Brooks compara el desarrollo software con las arenas movedizas que durante la prehistoria engullía animales gigantes que cuanto más luchaba por escapar más rápido se hundían. La única salida de este pozo de arenas movedizas es aplicar un proceso de ingeniería consciente y métodos probados en la gestión de proyectos.
No hay comentarios:
Publicar un comentario