16 abril 2008

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.

6 comentarios:

  1. Ante todo, buenas tardes Sr Navarro. Mi nombre es David Atencio, y actualmente estoy haciendo mi tesis en el área de Planificación de Proyectos. Mi investigación pretende estandarizar los procesos de planificación de una industria petrolera en mi país, mediante la aplicación de una metodología de proyectos disponible en el mercado, y lo que se encuentra en el mercado es un software llamado MPMM. Ud tiene conocimientos acerca de ese software? Estaría muy agradecido si Ud me diera alguna respuesta. Tambien he dejado algunas preguntas abiertas en yahoo respuestas: http://mx.answers.yahoo.com/question/index?qid=20080415220243AAQEsrK

    ResponderEliminar
  2. Hola David, conozco el paquete a nivel de evaluación. En realidad, no es más que una especie de libro interactivo con un cóctel de los estádares del PMI reflejados en el PMBOK con algo de Prince2, algunas plantillas, etc. En sí mismo no resuelve nada, aunque si traza una especie de guía con los pasos a dar, que hay que rellenar, etc. Lo que puede ser peligroso cuando el proyecto concreto que nos ocupa presenta algunos casos que no se deberían dar, etc. Si quieres el paquete completo, tendrás que adquirirlo en http://www.mpmm.com/.

    ResponderEliminar
  3. ¿Quiere esto decir que la redistribución de recursos nunca puede ser automática y que una vez realizada requiere el "toque" manual siempre?.
    Saludos.

    ResponderEliminar
  4. Si te refieres a lo que digo en el punto 9, lo que quiero significar es que no se puede implementar un algoritmo que resuelva un problema de optimización de asignación de recursos limitados a una red de tareas porque es de complejidad NP. Eso no quiere decir que los paquetes de software tengan automatizado el problema de la nivelación de recursos, aunque sea con otro tipo de algoritmos que llevan ya incorporadas reglas del tipo del dedo pulgar -las heurísticas a las que me refería-.

    Otra cosa es que la automatización nos sea de ayuda, tanto la que hay ahora como la que incorporara ese esquivo algoritmo NP-hard, única y óptima de verdad -una solución que sí podría estar, por cierto, dentro del alcance de un futuro ordenador cuántico-, debido a que la realidad es bastante mucho más gris y difusa que el funcionamiento mecánico de las técnicas de programación. En mi opinión, no hay nada como el toque manual humano, porque la Inteligencia Artificial brilla por su ausencia.

    ResponderEliminar
  5. yo a veces ciertamente me siento como un orangután y hasta como un chimpancé... a veces como un tití y a veces como un pardillo... saludos

    ResponderEliminar
  6. Bienvenido a la fauna, hoteles. Por cierto, he tenido que buscar tití en el diccionario :-)

    ResponderEliminar

Nota: solo los miembros de este blog pueden publicar comentarios.