Home Columnistas Andrés Meza #Columna – Nueve mamás y un bebé

#Columna – Nueve mamás y un bebé

93
0

En todo proyecto hay tres aspectos que se condicionan mutuamente: tiempo, recursos y alcance de la solución. Si crece el alcance o disminuyen los recursos, hay que aumentar el tiempo. Pero si nos reducen el tiempo, hay que reducir el alcance o aumentar los recursos. Y aunque funcione así en los proyectos de manufactura, es distinto en los proyectos de conocimiento como  investigación o desarrollo de software. La razón es que en vez de recursos, el factor clave es el esfuerzo de los participantes, por lo que más gente no necesariamente logra que el mayor esfuerzo se traduzca en menos tiempo. Por eso hay un dicho recurrente en informática:

¿Qué es un Gerente de proyectos? Alguien que cree que nueve mujeres pueden parir un bebé en un mes.

La noción viene de una frase del legendario ingeniero de software Frederick Brooks: “Cuando una tarea no pueda ser dividida en partes debido a restricciones secuenciales, la aplicación de más esfuerzo no tendrá efecto en el cronograma. La gestación de un bebé toma nueve meses, no importa cuántas mujeres sean asignadas”.

El problema

El problema con aumentar el número de participantes es fundamentalmente de comunicación. En el ejemplo del software, un solo desarrollador no tiene que dar explicaciones: tiene el código fuente en su cabeza y recuerda las razones por las que tomó decisiones de diseño y de implementación. Con dos personas, se necesita un flujo de comunicación entre ellas para ponerse de acuerdo. Si se aumenta el equipo a cuatro integrantes, los flujos aumentan a seis. Un equipo de diez participantes implica 45 vías en las cuales puede fluir comunicación entre ellos, y así sucesivamente.

Entre más flujos de comunicación haya que mantener, más probabilidad de que hayan errores de comunicación. También aumenta el tiempo que deben pasar los integrantes en tareas administrativas como asistir a reuniones o escribir documentación, en vez de estar diseñando o programando. Por eso es que hay un punto a partir del cual traer más gente a un proyecto no solo no acelera el progreso sino que lo hace más lento. Pero esto no significa que no se puedan hacer eficientemente proyectos grandes con muchos participantes, solo que hay que coordinar inteligentemente el trabajo de equipos pequeños.

Equipos pequeños

Un camino es minimizar la necesidad de constante comunicación entre todos los participantes. Podemos hacerlo al invertir un tiempo significativo al inicio del proyecto para detallar cuidadosamente los requerimientos y diseñando una solución cuya ejecución se pueda repartir entre varios equipos sin interacción entre ellos. El gran inconveniente es que debe haber muy poca incertidumbre: tanto el problema como la solución deben estar muy bien definidos. Además no debe haber mucha gente diseñando porque se incurre en el problema de comunicación que se quiere evitar durante la ejecución.

Si se cumplen las condiciones de claridad y estabilidad en los requerimientos, se puede ganar velocidad organizando equipos pequeños aumentando la tasa de salida (throughput) del proyecto, es decir, reducir el tiempo entre entregas parciales.

Flujos escalonados

Lo primero es identificar las etapas por las que debe pasar el proceso para culminar en una entrega. Por simplicidad, digamos que son tres: diseño, construcción e implementación. Supongamos que cada una tarda una semana, por lo que desarrollar una entrega completa de principio a fin requiere tres semanas. Con estas condiciones podemos coordinar tres equipos para que cada uno sea responsable de una etapa así:

Al final de la semana 4, el equipo de implementación deja funcionando el entregable B donde el cliente y todos los equipos están trabajando permanentemente. Así, a unque cada entregable sigue tardando tres semanas en completarse, para el cliente el tiempo entre cada entrega se ha reducido a solo una semana.

¿Y qué pasa cuando no se cumplen las anteriores condiciones? Este es el caso de los productos nuevos, donde los emprendedores se enfrentan a una gran incertidumbre. Primero, el problema suele no ser claro (traducción: el cliente no sabe lo que quiere). Segundo, solo sabrán si la solución va por buen camino cuando hayan probado exitosamente en el mundo real una versión del producto cercana a la final. Por eso en este caso, lo mejor es probar un prototipo de la solución, ajustarlo y volverlo a probar tan frecuentemente como sea posible.

En conclusión, dependiendo de las condiciones del proyecto no siempre aplica el aumento de recursos para reducir el tiempo de entrega. En consecuencia, puede que no cumplamos el sueño de gestar un bebé en un mes, pero si logramos que las mamás se turnen, sí podremos recibir a un nuevo bebé cada mes.