Los peligros de la programación compulsiva

La programación del proyecto, que no hay que confundir con la planificación –la programación o cronograma no es más que uno de los ítems de un plan de proyecto-, es una componente muy importante en la gestión de un proyecto –de hecho es, en sí misma, una de las nueve áreas en las que el PMI clasifica el cuerpo de conocimiento en Dirección de Proyectos-. Hoy en día, y gracias a los múltiples paquetes de software disponibles, tanto a nivel comercial como de libre acceso, es una disciplina muy avanzada con una gran cantidad de conceptos más o menos específicos, y otras tantas técnicas y algoritmos más o menos sutiles. Hagamos un repaso.

1. Las actividades se pueden clasificar en base a su posición en la jerarquía del desglose que se haya realizado (EDT o WBS) atendiendo a si ocupan el último nivel de desglose –esto es, son los ítems que suponen el trabajo directo del proyecto- o no. Todas estas últimas son lo que comúnmente referimos como tareas sumarias, no siendo objeto de trabajo directo sino más bien agrupaciones de otras tareas de un nivel inferior en la jerarquía de desglose, algunas de las cuáles pueden ser a su vez sumarias.

2. Las actividades presentan interdependencias lógicas debido a su naturaleza técnica. A la clásica y más intuitiva de “debe comenzar cuando haya finalizado esta otra”, los paquetes de software incorporan otras tres que permiten materializar otro tipo de relaciones más sutiles como comienzo a comienzo, fin a fin, y “debe finalizar cunado haya comenzado esta otra”.

3. En principio, podríamos materializar cualquier tipo de interrelación a cualquier nivel de la jerarquía de desglose, como enlazar tareas a diferentes niveles de la jerarquía, tareas de último nivel con tareas sumarias, sumarias con sumarias, etc. El software no nos lo va a impedir siempre que no lleve a bucles cerrados lógicamente inconsistentes.

4. Se pueden intercalar decalajes en las interrelaciones de forma que el efecto de la relación no sea inmediato sino que pueda ser pospuesto, o incluso adelantado (decalajes negativos).

5. Se pueden asignar diversos calendarios a tareas concretas, y diferentes del calendario general asignado al proyecto en su conjunto. Incluso se puede hacer al nivel de recursos concretos asignados a las tareas. Nuevamente, los maravillosos paquetes de software permiten casi cualquier combinación que se le pueda ocurrir al planificador más calenturiento.

6. Se pueden asignar restricciones a las fechas de comienzo y/o finalización de una actividad, como “no comenzar antes o después de una fecha indicada”, “comenzar o finalizar en una fecha indicada”, etc. Estas restricciones pueden tener efectos durante una replanificación del proyecto, desde evitar que una tarea concreta se desplace pese a un retraso hasta que sí se desplace, aunque afecte al cálculo de las holguras mediante un recorte de las mismas haciendo que puedan ser negativas –una forma de indicar el retraso que produce su propia desviación en el plazo del proyecto-.

7. Marcar como hitos tareas que tienen una duración mayor que cero –una de las cosas permitidas y tentadoras que considero más absurdas de los paquetes de software.

8. Permitir condicionar la duración de una actividad al esfuerzo resultante del trabajo efectuado por los recursos asignados, hecho que puede llevar a duraciones que sean fracciones diarias.

9. Resolución de conflictos entre recursos. La optimización con capacidad finita –recursos limitados- es un problema muy complejo no resuelto, por lo que los algoritmos implementados en los paquetes de software están basados en heurísticas con efectos que pueden ser dudosos.

10. A modo de conclusión, todas las situaciones enumeradas anteriormente afectan, y de qué manera, al cálculo de los tiempos de inicio y finalización tempranos y tardíos de todas las tareas de la red, a sus holguras, el camino crítico y la duración del proyecto. Y lo más importante, a la apariencia más o menos amigable e intuitiva que tenga el cronograma resultante.

Pues bien, si todo esto se hace de forma alegre e irreflexiva, el cronograma resultante es algo ininteligible, frágil –se desmorona a la primera de cambio, esto es, a la primera replanificación-, y deviene en algo totalmente inútil. Incluso puede llevar a la conclusión no deseada de que programar no sirve para nada. Todo lo enumerado más arriba da para muchos cursos de formación, hay mucho que conocer. Pero no se trata de eso, sino de saber cómo utilizarlo y si se debe utilizar tan siquiera. Jugar a los ejercicios académicos puede llevar a desafiantes y enrevesados cronogramas que quedan muy monos en un papel, pero que aplicados a la realidad práctica del día a día de un proyecto se transforman en un orangután que patea sin ningún tipo de consideración el proyecto.