Durante la formación recibida durante la carrera, o fuera de ella, a casi todos los ingenieros en informática, cuando toca formarse en gestión de proyectos, raro es que no les enseñen Gantts, PERTs, rutas críticas y CPM. A mí me pasó. Pero no sólo durante la carrera, de hecho, la mayoría de “marcos”, metodologías, certificaciones, etc., sobre gestión de proyectos en tecnología y/o software, destaco lo de tecnología y/o software, cuentan como técnica principal los Gantts, PERTs, rutas críticas y CPM.
A los Gantt ya les dediqué un post, aquel de diagramas Gantt cómo arma de destrucción masiva de proyectos, y hoy quería reflexionar sobre los PERTs, las rutas críticas y los CPM. Sería difícil, y erróneo, afirmar que una técnica es de nula aplicación, pero como primer pensamiento quiero volver a poner en cuestión sino se la ha dado, y da, excesivo protagonismo y tiempo al uso de Gantts, PERTs, rutas críticas y CPM, en comparación con otras maneras de gestionar el proyectos.
Más curioso aún es, en este sentido, que casi todo informático conoce los Gantts, PERTs, rutas críticas y CPM, se los han explicado… y casi nunca los ha usado (o si los ha usado te dirá que se alejan mucho de la realidad). Lo cual quiere decir que algo no termina de encajar: o no los sabemos usar o su uso no es de aplicación a gran parte de los proyectos software (quizá a la contrucción de, yo qué sé, barcos, si que tenga más aplicación). Y esto me vuelve a recordar que podemos estar de nuevo frente al eterno problema de aplicar técnicas de gestión y planificación tradicional, aquella heredada de la gestión y construcción de productos físicos cómo barcos, casas o coches (te recomiendo aquí el post de fabricar software no es lo mismo que fabricar coches o construir casas) al mundo del software y de la elaboración de “productos” intelectuales.
PERT, CPM y la gestión de proyectos para productos físicos
Y lo de aplicar técnicas de gestión y construcción de productos físicos cómo barcos al software no lo digo con ironía. El PERT nació en 1957 en la Oficina de Proyectos Especiales de la Marina de Guerra del Departamento de Defensa de EE.UU. como parte de un proyecto para crear un misil lanzado desde submarino. Y el CPM viene de técnicas aplicadas al proyecto Manhattan, sí, el proyecto para la creación de la bomba atómica.
PERT, CPM y la gestión ágil
Desde entonces, los PERT y los CPM han ocupado un papel destacado en la gestión de proyectos software. Sin estar muy claro cómo aplicarlos a la realidad de un proyecto software, si bien han sido muy socorridos a la hora de “vender” el proyecto, antes de empezar, y “demostrar sólidos conocimientos” sobre gestión.
Y sobre todo, más en estos últimos años, sin saber muy bien cómo encajarlos con una gestión ágil, con requerimientos cambiantes y ciclos de vida iterativos e incrementales. Aunque, también muy curiosamente, puedes encontrar artículos intentando encajar de alguna manera el uso de los PERT en una gestión ágil (más curioso aún si artículo está en la mismísima página de la Scrum Alliance). E incluso libros como el “Scrum Project Management” que aportan su visión de cómo usar PERT en Agilidad.
PERT, CPM, tareas y sus dependencias
No me voy a meter mucho en contarte qué es un PERT y el CPM, seguro que ya lo sabes, y si no hay miles de páginas contándolo con todo lujo de detalles. Aún así, por refrescarte un poco la memoria, y contextualizar el post, te recuerdo que los PERT y CPM típicamente representan un proyecto con un diagrama, un grafo normalmente, que muestra las tareas que tendrá el proyecto y sus dependencias.
El primer problema con estas técnicas viene de la predictibilidad, ya sabes, necesitan que se dibujen todas las tareas que habrá en el proyecto, para desde ahí hacer una planificación, lo que nos lleva que esa planificación no se lleva bien con el cambio, es decir, que cuando venga la dura realidad del proyecto y todo ese esquema de tareas que se supusieron, su orden y temporalidad, tenga que cambiarse.
Luego está lo de las dependencias, ya sabes, la tarea A va antes que la B, la B depende de que antes se termine la A. Y de ahí buscar el camino crítico, aquel conjunto de tareas dependientes unas de otras, en el que si hay un retraso en una tarea se retrasaría el proyecto entero, ya que de esa tarea dependen otras posteriores.
La gestión software actual va por otros caminos, intenta no sólo evitar las dependencias, sino que, en este sentido, intenta que gran parte de las tareas se hagan casi en paralelo, e incluso que tareas que tradicionalmente eran dependientes de todas las demás, como el caso del testing, se empiecen desde el mismo inicio del proyecto. Y para ello, en vez de con grandes fases dependientes, se trabaja con tareas lo más pequeñas posibles. Con todo ello, las dependencias pueden existir pero su papel tiende a ser, y debe ser, mínimo y por ello su gestión no debe ocupar un papel clave.
Alguien podrá decir que “antes de hacer consultas debe haber un modelo de datos”, pero la realidad es que tanto hacer las consultas como hacer el modelo de datos pueden ser tareas que evolucionen de manera conjunta, casi a la vez, así evitamos, además, hacer todo el modelo de datos de una y todas las consultas después (cascada).
Terminando
PERT y CPM son técnicas que nos han acompañado desde siempre a la hora de hablar de gestión de proyectos. Quizá en proyectos en los que participan múltiples empresas se puedan, y sea útil, tener grandes tareas y sus dependencias. Pero ya desde hace unos años los tiros en gestión de proyectos software van por otro camino: pequeños equipos multi funcionales trabajando con iteraciones.
¿Cómo lo ves?
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Desde mi experiencia, no es buena idea avanzar en el modelo de datos de a partes, como por ejemplo, por Caso de Uso o Historias de Usuarios porque los cambios en el modelo pueden ser muy drásticos y, dicho caso, implica grandes cambios a nivel de código de lo que ya está desarrollado.
Por supuesto, todo depende del dominio en el que se trabaja. Actualmente me desempeño como lider de equipo de desarrollo para una Software Factory que se dedica que exclusivamente a clientes de la industria del seguro. Este dominio es muy complejo y las soluciones de software bastate grandes y el costo de emplear cambios radicales en un modelo de datos es costosísimo.