Juan, el administrador del proyecto, pregunta al grupo de desarrollo —¿por qué nos estamos atrasando?, y añade —No estamos cumpliendo con el calendario propuesto. Con una expresión de extrema preocupación marcada en el rostro hace “la pregunta” —¿de cuanto va a ser el retraso? — Seguramente este escenario le resulta familiar.
La administración de proyectos consta de actividades clasificadas en tres áreas fundamentales: planificación, seguimiento y control. Estas tratan con el personal, el proceso y el producto involucrados en un proyecto en particular.
Dentro de la planificación, la actividad crítica es la estimación, para la cual existen muchos métodos, entre los que destaca COCOMO II (ver Estimación de Proyectos, SG No. 1, 2005). Pero aun con una excelente estimación, ¿estamos asegurando el éxito del proyecto?, por supuesto que no. Tener una buena planificación no garantiza que se llevará a cabo al pie de la letra, ¿qué puede pasar?
Tiempos de Protección
Los proyectos de software se caracterizan por el alto nivel de incertidumbre asociada, debido principalmente a la naturaleza intangible e intelectual del producto esperado. Por ello, es obligado tomar en consideración las actitudes del ser humano en el desarrollo de una actividad dentro de un plan de trabajo.
Volvamos con nuestro atribulado administrador de proyecto, Juan. Durante la estimación, es probable que su grupo de desarrollo haya agregado un “colchón” de tiempo de protección para cada una de las actividades del plan de trabajo. Como es probable que Juan no se haya dado cuenta de eso, a su vez él agregó otro “colchón” de protección para todo el proyecto, esto lo podemos ver en la Figura 1. 
Figura 1. Red de actividades de un proyecto con protecciones por actividad.
La pregunta es: ¿por qué si todos agregan tiempo de protección, el proyecto inevitablemente se atrasa? Para responder esto, analizemos algunos aspectos que afectan las actividades del plan de trabajo:
1. El “síndrome del estudiante”. Como los programadores saben que cuentan con un colchón de protección, es probable que no inicien de inmediato la actividad, sino que consuman ese tiempo en otras actividades, de tal manera que empezarán hasta que sólo tengan disponible el tiempo que originalmente habían estimado. Es decir, se gastan el “colchón” antes de iniciar. Por lo tanto, si surge algún problema en el desarrollo de la actividad, al no tener protección se producirá un retraso. Es así que en el mejor de los casos, la actividad terminará en el tiempo establecido originalmente.
2. La Ley de Parkinson. Cualquier trabajo se expande hasta ocupar todo el tiempo destinado para él. ¿Cuál es el incentivo para un programador que termina su actividad con anticipación? ¿más trabajo? Si una actividad se termina antes de lo calendarizado y no existe un incentivo por terminación anticipada, el responsable de la actividad encontrará la forma de seguir trabajando en ella hasta llegar a la fecha límite. El resultado de esto, es que los retrasos se acumulan a lo largo del proyecto, pero los adelantos no impactan significativamente.
3. Multitareas. Lo peor que puede hacer un administrador de proyectos es asignar múltiples tareas simultáneas a un mismo recurso, y todas con la misma prioridad.
En conclusión, agregar tiempo de protección a las actividades, no sirve de mucho si no se puede aprovechar el tiempo de las terminaciones anticipadas.
Cadena Crítica
Entre las metodologías orientadas al seguimiento del progreso de los proyectos, existe una denominada Cadena Crítica (CC), enfocada al manejo de la incertidumbre inherente a todo proyecto. Se define como una cadena crítica a la secuencia de eventos dependientes que evitan que el proyecto se complete en un intervalo más corto de tiempo, donde un evento dependiente es aquel que utiliza como insumo tareas que otro evento produce, o utiliza recursos que otro ocupa. Esta última restricción es lo que establece la diferencia con la tradicional “ruta crítica”, ya que ésta última no toma en cuenta la competencia por los recursos.
La metodología CC inicia con la construcción de una red de actividades compuesta por varias cadenas de actividades dependientes. Una de estas será definida como la cadena crítica y las demás como cadenas alimentadoras, que se unen a la cadena crítica en algún punto del calendario. Una característica de CC es que evita agregar tiempo de protección, o “colchón” a cada actividad. Se inicia con una estimación de la duración de cada actividad (sin “colchón”). Al final de cada cadena, ya sea crítica o alimentadora, se agrega un “amortiguador” que proteja a toda la cadena. En la figura 2 vemos un ejemplo de la ubicación de los “amortiguadores” en la secuencia de actividades y podemos apreciar que no cambia la fecha de terminación del proyecto, simplemente quitamos la protección individual de las actividades y la ubicamos al final.
Figura 2. Red de actividades con amortiguadores.
El control del proyecto se hace monitoreando el consumo de los “amortiguadores”, con este mecanismo se evita que el equipo de desarrollo tenga que reaccionar a falsas alarmas debido a pequeñas variaciones en las estimaciones del calendario inherentes a la incertidumbre de todo desarrollo de software, y se pueda concentrar cuando el peligro de no terminar en tiempo sea real.
Para el seguimiento del progreso, CC se apega a las siguiente reglas:
• No se establecen fechas fijas de inicio y fin de cada actividad, sólo se define la fecha de inicio de cada cadena de actividades y la fecha final de entrega del proyecto.
• Las personas participantes estarán concentradas en una sola actividad a la vez. Es decir, no es posible participar en varias actividades simultáneamente.
• Cada persona tendrá que reportar periódicamente el tiempo estimado para completar su actividad actual.
• Cada persona deberá iniciar la actividad que le corresponda en cuanto la actividad de la cual depende sea completada.
• El administrador se enfocará en la supervisión del consumo de los amortiguadores de tiempo, tomando las acciones pertinentes cuando estos consumos sobrepasen límites establecidos de antemano.
Cadena Crítica en Ambientes Multi-proyectos
Una de las ventajas de CC es que se utiliza tanto para ambientes de un sólo proyecto como para ambientes multi-proyectos. Los pasos para la construcción de la red de actividades para este tipo de ambientes son:
1. Desarrollar la red de actividades para cada proyecto.
2. Priorizar recursos tomando en cuenta la disponibilidad entre proyectos.
3. Identificar la cadena crítica por proyecto.
4. Ubicar amortiguadores en cada proyecto.
La principal diferencia entre manejar uno o varios proyectos al mismo tiempo, es la competencia por los recursos. De esta forma, el reto más importante para CC es calendarizar los recursos compartidos de manera que estén enfocados en una tarea al mismo tiempo.
Conclusiones
Aunque el método de Cadena Crítica implica más aspectos que los aquí presentados, ahora Juan ya tiene una mejor manera de organizar y darle seguimiento a su proyecto, para lo cual aprendió que:
1. No debe incluir tiempos de protección por actividad, debe hacerlo al final de las cadenas de actividades.
2. No debe establecer fechas límite por actividad para evitar el “síndrome del estudiante” y la Ley de Parkinson. Sólo se deben manejar tiempos estimados de duración por actividad.
3. Debe tomar en cuenta la competencia por los recursos y no calendarizar actividades simultáneas para un recurso.
4. Debe pedir reportes periódicos de estimados de conclusión de las actividades en curso.
5. Si una actividad se retrasa, no debe alarmarse. Los retrasos en una actividad le restan tiempo a los “amortiguadores”, pero las terminaciones anticipadas le suman tiempo. De manera que unas se compensan con las otras.
6. Sólo se preocupará cuando el consumo de los “amortiguadores” sobrepase un límite que él mismo establece.
Una de las principales limitantes en la adopción de CC en las organizaciones es el cambio de cultura que implica trabajar con este concepto, particularmente en la eliminación del “colchón” de protección, mecanismo al que las personas están acostumbradas.
Referencias
• Goldratt, Eliyahu. “Cadena Crítica”, Ediciones Castillo, 2000. México. • Miranda, Eduardo. “Planning and Executing Time-Bound Projects”. IEEE Computer. Marzo 2002.
• Reel, John. “Critical Success Factors in Software Projects”, IEEE Software, May-June 1999.
Acerca del Autor
José Martín Olguín tiene una maestría en ciencias de la computación y 15 años de experiencia dirigiendo desarrollos de software. Actualmente es coordinador de la maestría en computación de la UABC campus Mexicali e imparte cursos relacionados con la Ingeniería de Software a nivel licenciatura y maestría.
- Log in to post comments