Con alarmante frecuencia en las últimas dos semanas me he encontrado a mí mismo repitiéndole lo mismo a gente que debería saberlo ya. Hablo específicamente de una ley aplicada al desarrollo de programas informáticos conocida como la «Ley de Brooks» y, aunque es realmente simple de entender, por algún motivo no parece ni obvia ni natural si no te la muestran y demuestran usando tus propios errores como ejemplo.

Hay muchas metodologías, en estos días de tanto «emprendedor» y «gente altamente eficaz», que se enseñan para manejar equipos de trabajo y proyectos de todo tipo. La «Ley de Brooks» se centra sobre la incorrecta aplicación de uno de los estilos más comunes de llevar proyectos y, específicamente, a la espiral de desastre que suele desencadenar. Al final del artículo pongo más información sobre el libro de Brooks en cuestión y sus otros postulados sobre manejo de proyectos.

En México se dice «Échale más cemento» cuando algún proyecto está atrasándose y no va como debería. La frase viene de la construcción, donde lo que no puedas arreglar con buena ingeniería y arquitectura siempre lo puedes arreglar poniéndole mas hormigón y hierro. Esta analogía se extiende a muchas cosas en las que podemos vernos envueltos:

-¿No puedes transportar todo lo que debes? Échale más camiones
-¿No estás logrando apagar un fuego? Échale más agua
-¿Tienes más información de la que puedes capturar? Échale más gente capturista
-¿No puedes detener a Godzilla? Échale más tanques ((Ésta última es más común de lo que parece.))

El problema es que la solución de «Echarle más cemento» sólo sirve en los proyectos en los que el problema son los recursos y la solución obvia es buscar más recursos.

El otro tipo de proyecto, que es el que nos concierne, es el ‘Serializado’. Proyectos donde una tarea no puede ir antes de otra y cada tarea tiene que hacerse por la misma persona/grupo. Los desarrollos de software son de este tipo porque, con frecuencia (y especialmente en la segunda mitad), las partes que lo componen son interdependientes y dependen unas de otras. No puedes desarrollar pantallas de usuario si no tienes datos que presentar, no puedes hacer rutinas de importación si no tienes tablas definidas.

Esto obviamente no suele ser un problema en desarrollos hechos por grupos pequeños de manera informal pero cada vez más se ve el uso, por parte de compañías y corporaciones, de equipos de desarrollo de terceros, el famoso «outsourcing» o «subcontratación». El outsourcing significa, simple y llanamente, que alguien más hace el trabajo a partir de una serie de condiciones de resultados, por una cuota. ¿Cual es la pega? Que cuando se hace outsourcing de desarrollo tiene que haber un estimado previo estipulando cuánto se va a pagar por ese desarrollo y la forma más fácil de comprender lo que se está pagando es cotizar los proyectos en «horas-hombre»:

Estas horas-hombre pueden luego, fácilmente, multiplicarse por el coste por hora y se sabe de antemano el costo de desarrollo del proyecto (o sea, 1500 euros en el caso de un desarrollador freelance y 150,000 euros en el caso de un desarrollador certificado de consultoría de Oracle).

Las horas-hombre (o su múltiplo, meses-hombre, equivalente a 160 horas) conducen a la deducción equivocada que si una parte requiere 10 horas-hombre entonces diez personas lo completarían en 1 hora. Es dolorosamente indiscutible que TODO líder de proyecto de desarrollo caerá en esta falacia, usualmente en su primer proyecto y, hasta que alguien no se lo señale, fallará en ver que es lo que está pasando mal.

La Ley de Brooks lo dice que «Añadir mas personal a un proyecto tardío sólo logrará retrasarlo más«. Esto significa que cuando un proyecto va retrasado y se intentan añadir desarrolladores nuevos no se toma en cuenta el tiempo el tiempo añadido que le lleva a los nuevos elementos el familiarizarse con el mismo, y que el tiempo adicional perdido en comunicaciones entre ellos puede aumentar tanto que puede llegar a rebasar el tiempo disponible (hay una fórmula al respecto, donde se muestra que a medida que se añaden elementos a comunicar el tiempo dedicado crece de tal manera que al final el 100% del tiempo se dedica a comunicación y el desarrollo se detiene).

¿Qué se puede hacer cuando un desarrollo está retrasado?
Las opiniones aquí son varias y variadas, y no hay ninguna que sea 100% adecuada, ya que depende mucho de la situación específica del proyecto y el cliente, pero el resultado final suele ser que la fecha de entrega del proyecto se retrasa (con o sin cargo adicional al cliente, usualmente el segundo) y en casos extremos el proyecto se cancela totalmente.

La única forma de evitar este problema es a través de delineación adecuada de etapas, metas y módulos en el proyecto y de una distribución adecuada de los recursos asegurándonos de tener localizados a aquellos programadores «estrella» que son capaces de moverse de uno a otro trayendo resultados inmediatos con el mínimo de preparación.

The Mythical Man-Month (El mítico mes-hombre), de Fred Brooks.
El libro ‘El mítico mes-hombre’ de Fred Brooks surge de sus experiencias en IBM y su error de intentar acelerar el desarrollo añadiendo mas desarrolladores al mismo, que es el tema central del libro. En el libro se manejan varios conceptos, de los cuales destacan:
El mítico mes-hombre
Arriba ya he comentado algo de este concepto, conocido como la «Ley de Brooks» pero cabe aclarar que la Ley se suele interpretar de forma incorrecta. Dependiendo de como se entienda puede pensarse que lo que sugiere es que un proyecto debe ser desarrollado por grupos pequeños de programadores altamente capaces, pero la realidad es que el concepto lo que cubre es la adecuada planeación del proyecto y la capacidad de dividir el mismo en módulos separados y que se puedan desarrollar de forma independiente. Específicamente la Ley de Brooks no dice que quitando personal de un proyecto se pueda acelerar su terminación (que podría ser una consecuencia lógica de invertir el postulado).

El efecto del ‘Segundo Proyecto‘
De este problema también son víctima casi todos los líderes de proyectos cuando, después de haber completado el primero deciden aplicar al segundo todo lo que han aprendido. El segundo sistema que haga un jefe de proyecto siempre estará horriblemente sobre-diseñado. En un intento de evitar los problemas encontrados en el primer proyecto el jefe de proyecto sobre compensará cayendo en el extremo opuesto.

El ‘equipo quirúrgico’
Todo jefe de desarrollo debe ser capaz de tener en su equipo al menos una persona e idealmente un conjunto de ellas capaz de atacar cualquier problema que surja. La idea es tener a estos grupos dedicandose a varios proyectos en áreas especialmente problemáticas o con labores asignadas pero capaces de entrar de emergencia en alguna etapa problemática. El concepto es bastante similar al concepto de «Electrón Libre» de Rands

Seguimiento del Proyecto
Metas y etapas (milestones) deben ser definidas de antemano para el proyecto, con fechas límite y conjuntos de funcionalidad mínima requerida. La única forma de evitar el acecho de nuevas funcionalidades es mantener el objetivo inicial hasta su conclusión y sólo entonces introducir mejoras al diseño original (la única excepción a esto siendo los «electrones libres», gracias a su capacidad especial de genios y aún en estos casos debe controlarse de cerca. Esto está atado directamente a…

Congelación de código y versionamiento
No existe ningun sistema perfecto y si no se decide un momento en que el código, esté como esté, se detiene y se declara la versión como terminada, jamás se producirían resultados. Escoger las funcionalidades que deben incluirse en cada versión y el momento en que el desarrollo se detiene hasta la próxima versión es vital para poder dar resultados. Obviamente el «síndrome de la versión 1.0» surge de aquí, pero la alternativa sería lo que se conoce como «vaporware». Proyectos que cada vez parecen tener más y mejor funcionalidad y capacidades, pero que nunca ven la luz del día.