Planificación (I): Gantt, PERT y CPM
Detalles- Detalles
- Categoría: Artículos
- Publicado el Martes, 12 Abril 2011 13:00
En el desarrollo de casi cualquier proyecto de cierto tamaño pueden identificarse algunas tareas que podrían realizarse simultáneamente por distintas personas o equipos de personas.
El hecho de trabajar en paralelo con distintas tareas suele hacer que el proyecto total se termine antes. Al fin y al cabo, el tiempo es nuestro recurso más valioso: no se puede comprar.
En este artículo, hablaremos de las técnicas mas elementales para planificar el tiempo, el trabajo de las personas y los recursos materiales, como las máquinas.
Se trata de técnicas que ayudan a la fase de planificación dentro del ciclo de vida del software, e intentan organizar el tiempo, los recursos y el esfuerzo de las personas implicados en otras tareas del ciclo de vida.
Aunque en general nuestro interés se centra en la ingeniería del software, éstas son técnicas aplicables a casi cualquier proyecto de construcción o producción de casi cualquier bien o servicio. Como de costumbre, sólo trataremos de exponer una simple introducción al tema, sin intención de ser exhaustivos.
Pensemos, por ejemplo, en la construcción de un edificio: mientas que un equipo está colocando el tejado de una parte de la casa, otro equipo puede estar realizando la instalación eléctrica y otro poniendo la puerta del garaje.
Es decir, para abordar un proyecto grande (sea de desarrollo de software o de cualquier otro tipo), es un enfoque razonable el hecho de identificar que todo el trabajo puede dividirse en varios trozos más pequeños (que llamaremos tareas, a partir de ahora, aunque también se utiliza el término actividades con el mismo sentido). Pues bien... esas tareas pueden tener cierta dependencia unas de otras (por ejemplo, no se puede poner el tejado a una casa a la vez que los pilares que lo van a sujetar), pero muchas de ellas sí van a poder realizarse simultáneamente.
Esto de que varias tareas se puedan solapar en el tiempo, seguramente, se ha sabido a lo largo de la historia... Con toda certeza, los constructores calzadas romanas o los arquitectos del antiguo egipto ya lo sabían.
El caso es que en nuestra civilización también lo sabemos desde hace mucho tiempo, pero sólo desde hace algunas décadas utilizamos herramientas formales (matemáticas) para estudiar y predecir cómo será el desarrollo de un proyecto en el que varias tareas se realizan a la vez. La ventaja que tiene ésto de contar con una herramienta formal es que se puede decidir con cierto criterio manera buena de planificar las tareas en el tiempo, es decir, decidir cuándo debe empezar y terminar cada tarea para que todo vaya lo mejor (o más rápido) posible.
Las herramientas que hoy en día utilizamos son de tipo matemático. La rama de las matemáticas que se encarga de estudiar este tipo de problemas es la investigación operativa.Nosotros vamos a hablar de algunas de técnicas (no muy punteras, pero vigentes no obstante) para tratar de organizar un proyecto basándose en sus tareas y sacar algunas conclusiones. Son las técnicas más básicas que suelen estudiarse en cualquier curso relacionado con la organización de proyectos de desarrollo de software.
El resultado del estudio de estas tareas y la aplicación de éstas técnicas matimáticas es lo que llamaremos el plan. (o la planificación, si quieres).
Dentro del plan, hay que controlar tiempos, recursos y esfuerzo productivo de las personas principalmente. En este artículo introductorio nos centraremos en las técnicas básicas que tratan el tiempo. El motivo es sencillo: el tiempo no se puede comprar. Podemos comprar más recursos materiales o contratar a más profesionales que aporten mayor esfuerzo productivo... ello conlleva otros problemas... pero es posible, sin embargo, comprar más tiempo no lo es.
Un plan debería decirnos:
- Qué tareas identificamos, cuándo deberían empezar y acabar, y las posibles consecuencias de un retraso.
- Qué recursos requiere cada tarea
- Qué perfiles profesionales de personas requiere la tarea y en qué cantidad.
Hay que tener en cuenta que las matemáticas nos ayudan a predecir qué pasará globalmente con el tiempo, los recursos y las personas a lo largo del desarrollo de un proyecto, pero los resultados de esas predicciones están basados en datos que parten de suposiciones y estimaciones, a menudo subjetivas o basadas en otros proyectos similares, pero no iguales, de tal modo que aunque la herramienta matemática que utilizamos sea exacta y precisa en sí misma, los datos de entrada tienen un grado considerable de "adivinación". Es decir, siempre que se intenta trabajar con tiempos se tiene un cierto grado de incertidumbre, dado que los datos iniciales son estimaciones. De todas maneras, siempre es mejor partir de un plan siendo conscientes de que debe tener un cierto grado de inexactitud que no tener ningún plan.
A pesar de todo esto, surgen problemas e inconvenientes durante el desarrollo del proyecto que afectan al tiempo, a las tareas, a las personas y a los recursos... Bueno... volvemos a lo mismo... nada es perfecto (¡ menos mal !), pero tener un modelo ayuda a no resolver cada problema partiendo de cero.
En cualquier proyecto, tanto grande como pequeño es imprescindible que alguien adopte el papel de gestor. Es decir, la persona encargada de llevar la planificación y supervisión del desarrollo de un proyecto. Existe un delicado equilibro entre el tiempo de desarrollo, el esfuerzo productivo de las personas y los recursos materiales. Un gestor debe llevar un seguimiento día a día del desarrollo de cada tarea del plan, para poder prever sus consecuencias y tomar las decisiones necesarias (ej: dotar de mayores recursos a una tarea para evitar retrasos, o calcular directamente el retraso y asumirlo, viendo como afecta al resto del plan). Si es necesario... se replanifica.
Sin embargo, un buen gestor sabe que la planificación de tiempos, tareas y recursos obtenida con éstas técnicas no es más que una guía, una orientación, una base de trabajo...y que el éxito de un proyecto no se basa ni en la planificación, ni en la replanificación, ni en el dinero, ni en los recursos ni en la inteligencia de nadie: el éxito de un proyecto se basa en las personas que participan en él.
Un buen gestor utiliza la planificación para que las personas que realmente realizan cada una de las tareas le orienten para coordinar a todos los equipos de trabajo, y que todos logren una cierta eficiencia y satisfacción con su tarea.
Muchos gestores olvidan o nunca llegan a ser conscientes de todo ésto: es decir, que la planificación es para ayudar en la coordinación de los equipos de trabajo, para estimar el tiempo y el esfuerzo que cada tarea del desarrollo de un proyecto implica y facilitar la fluidez del trabajo en cada tarea y en la continuidad de unas con otras. Muchos gestores olvidan que el trabajo se realiza por personas y para personas. Muchos gestores creen que el resultado de su planificación es infalible y que indica cómo deben suceder las cosas, en lugar de pensar que es simplemente una serie de líneas maestras para empezar a trabajar, facilitar el desarrollo y la coordinación de las personas, detectar flaquezas y debilidades en las suposiciones iniciales, y en fin último, ayudar a poner los medios para que cada tarea salga adelante, en lugar de obligar a que las cosas salgan como previeron. Si ésto es así... se contribuye mucho al malestar de las personas, a la frustración de todos (incluido el propio gestor) y al fracaso del proyecto.
El papel del gestor no es especialmente envidiable. Por un lado, siempre encuentra presiones por parte del cliente para que los tiempos y los costes sean minimizados, y por el otro, los inconvenientes que surgen en las tareas y que normalmente conllevan aumento de costes y tiempos.
Como el tiempo es el recurso más costoso, vamos a presentar estas técnicas considerando únicamente el tiempo, y después haremos otras consideraciones. En la realidad, esto no es tan sencillo... otros recursos, como las personas o las máquinas también condicionan la planificación, sin embargo, conviene tenerlos en cuenta en segundo lugar, después del tiempo a la hora de hacer la planificación. El motivo es que las personas, por ejemplo, se enmarcan dentro de un determinado perfil... quiero decir, en un proyecto de software puedo tener quizá cinco o seis personas con el perfil de programador (las tareas se planifican pensando en los perfiles, y no en cada persona en particular). Estas personas contribuirán a realizar varias tareas en un tiempo determinado... si necesito más esfuerzo productivo, siempre se puede contratar algún programador más... sin embargo, en general, el tiempo está acotado, y cuanto antes se acaben las cosas, mejor. Se pueden contratar más personas, o comprar más máquinas, pero en general, no se puede conseguir más tiempo. Así pues, el tiempo se tiene en cuenta primero, y las personas y los otros recursos después. Si el número de personas o de otros recursos está acotado, eso influirá a la planificación del tiempo... pero la planificación del tiempo se obtiene primero.
Vamos al tajo:
La base de la planificación: la identificación de tareas, sus tiempos y sus precedencias
En el artículo anterior en el que hablábamos de Las actividades del ciclo de vida del software, comentábamos que la planificación era una actividad de diseño, es decir, se realiza cuando está más o menos decidido cómo se desarrollará el proyecto. Bueno... esto no es algo inamovible... La fase de codificación de un proyecto, es decir, su construcción en sí, suele ser la que más se beneficia de una buena planificación, por eso, suele hacerse la planificación junto con otras tareas de diseño. Sin embargo, la planificación podría hacerse algo antes de manera parcial... Por ejemplo, podría hacerse una planificación para la fase de análisis y otra para la fase de diseño... al fin y al cabo, el propio análisis y el propio diseño también son trabajo y también puede planificarse... es, como todo, cuestión de balance. No obstante, el análisis y el diseño suelen hacerse por grupos mucho más reducidos de personas que la propia construcción, y con unas actividades, plazos y consumo de recursos bastante menos definidos: la planificación no tiene por qué ser tan útil en estas condiciones como el la construcción.
Supongamos que los diseñadores ya han decidido cómo debe ser la construcción del proyecto: es decir, al menos, han escogido lenguajes de programación, plataformas, medios de comunicación y almacenamiento, han planificado los distintos componentes de software que hay que programar, han establecido sus interfaces y han desarrollado un plan de pruebas y de integración. Quizá alguna de estas cosas todavía esté por perfilar un poco más, pero si se han definido las líneas básicas de trabajo, ya se puede empezar a planificar.
A partir de aquí, lo primero que hay que hacer es identificar las tareas y estimar sus tiempos. Una tarea es simplemente un trabajo, realizado por una o varias personas y que debería realizarse más o menos sin interrupciones.
El límite de lo que es una tarea y lo que no lo es lo pone el sentido común de las personas que realicen la planificación.
Te pongo un ejemplo: Imagina que estamos involucrados en la construcción de un edificio, y una de las cosas que hay que hacer es poner la puerta del garaje. Podríamos considerar que eso es una única tarea... pero también podríamos descomponerla en varias tareas... por ejemplo: Poner el marco, poner las bisagras, enganchar la puerta, montar el motor... etc. Bueno... así indefinidamente... pero no es util llegar a tanto refinamiento: si todo eso se hace más o menos de tirón, sin interrupciones, lo consideramos una sola tarea: poner la puerta del garaje. Al utilizar la expresión sin interrupciones no me refiero a tomar un café entre medias ni a que la tarea se haga en varios dias, sino a que ninguna de las personas involucradas se dedica a otras tareas mientras está realizando ésta.
Aclarado éste punto y puestos manos a la obra, el planificador se encontrará con que el desarrollo consta de una serie de actividades... es conveniente poner un título bien descriptivo a cada una, y también una breve referencia que nos permita nombrar a una tarea de manera inequívoca: para ésto, suelen asignarse letras o bien numerar las tareas. En esta ocasión, voy a utilizar letras.
Vamos a inventarnos un ejemplo:
| Tarea: | Descripción |
| A | Instalar el servidor ZZZ |
| B | Programar el módulo YYY |
| C | Programar el módulo XXX |
| D | Integrar el módulo YYY con el XXX |
| E | Probar YYY y XXX ya integrados en el servidor ZZZ |
Cada una de estas tareas llevará un tiempo, e involucrará a una serie de personas y otros recursos que condicionarán el hecho de que puedan simultanearse. Pero en este momento, no vamos a tenerlo en cuenta: lo que vamos a tener en cuenta es que la propia naturaleza de cada tarea también condiciona su precedencia.
En el caso del ejemplo,
- La tarea D consiste en integrar el módulo YYY con el módulo XXX. Para ello, es necesario que ambos módulos esten terminados. Así pues, diremos que la tarea B (programar YYY) y la tarea C (programar XXX) deben concluirse antes de empezar la tarea D... dicho de otro modo, B y C preceden a D.
- La tarea E consiste en probar conjuntamente YYY y XXX en el servidor ZZZ. Para ello, es necesario que ambos módulos estén integrados (la tarea D). Así pues, diremos que la tarea D debe concluirse antes de empezar la tarea E... dicho de otro modo, D precede a E. Por supuesto que también B y C preceden a E... pero no es necesario tomar nota de ello, ya que es una consecuencia lógica (la precedencia entre tareas es una relación transitiva: si B y C deben concluirse antes de que empiece D, y por otro lado D debe concluirse antes de que empiece E, entonces está claro que B y C deben concluirse antes que E.
De cada tarea, anotaremos como sus precedentes sólo a los inmediatos... aunque en éstos textos utilizaremos la palabra "precedente" o "predecesor" a secas (igual que otros muchos textos sobre el mismo tema), en realidad nos estamos refiriendo a las tareas inmediantamente anteriores, y no a todas las tareas anteriores.
Bueno... pues ampliaremos la tabla con éstos datos.
| Tarea: | Descripción | Precedentes |
| A | Instalar el servidor ZZZ | - no tiene |
| B | Programar el módulo YYY | - no tiene |
| C | Programar el módulo XXX | - no tiene |
| D | Integrar el módulo YYY con el XXX | B y C |
| E | Probar YYY y XXX ya integrados en el servidor ZZZ | D |
Las tareas A, B y C no tienen precedentes. Eso significa que (sin considerar recursos y personas), pueden empezar lo antes posible. La tarea D sólo puede empezar cuando B y C hayan concluido, y la tarea E sólo puede empezar cuando haya concluido D.
Muy bien... Si empezamos este proyecto el día 1 de Enero del año que viene, ¿Cuándo lo terminaremos?... Ahhhh... Todavía nos faltan datos: debemos estimar el tiempo que se tardará en realizar cada tarea.
Resulta evidente que estimar el tiempo que tardará algo que todavía no se ha realizado entra en el terreno de lo subjetivo... en cierto modo, es como "adivinar"... pero con criterio.
Por ejemplo, si yo tengo que viajar en mi vehículo mañana desde Madrid hasta París... ¿Cuánto voy a tardar? Bueno... No lo sé (hoy es hoy y nadie sabe lo que pasará mañana)... pero podemos estimarlo. Conocemos las carreteras por las que tenemos previsto pasar, la velocidad media de los vehículos por esas carreteras, las distancias... Puedo ir a cualquiera de las magníficas herramientas en línea, como Google Maps, y me dará una estimación de lo que tardaré, basándose en esos y otros muchos datos. Puede ser que me desvíe de él... que tenga sueño y pare a descansar, o que encuentre un atasco por obras no previsto que me retrase... o que mañana haya poco tráfico y buen tiempo y finalmente llegue antes... pero a efectos prácticos, y para planificar algunas tareas alrededor de mi viaje, lo mejor es que tome la estimación en cuenta: no debo empeñarme en tadar exactamente lo que me han estimado... simplemente me sirve como ayuda para planificar mi tiempo.
Si luego las cosas no son como se estimaron, pues a adaptarse con sentido común y buen criterio: las cosas siempre son como son... nunca como uno prevé.
Bueno... pues es necesario estimar a priori la duración de cada tarea. La estimación siempre será imprecisa (por muchas herramientas matemáticas asombrosas que se utilicen para estimar), pero debemos intentar hacer un pronóstico lo más realista posible. Normalmente, nos debemos basar en la experiencia de los trabajadores en proyectos anteriores: ellos son los que saben lo que tardaron saben lo que van a hacer, y pueden extrapolar su experiencia a las nuevas tareas. Conviene igualmente no hacer una estimación demasiado optimista, o el más mínimo contratiempo planteará muchas dificultades.
Hay ríos de tinta escritos sobre cómo hacer estimaciones del tiempo en proyectos informáticos... cada ilustrado investigador tiene su propio método: algunos tienen una cierta sensatez, otros parecen sacados del pasado con una máquina del tiempo y otros... son casi peores que tirar un par de dados y quedarse con el número que salga. El motivo de éstas disparidades radica en algunas erróneas creencia instauradas en algunos de éstos investigadores:
- Por un lado, a menudo se piensa que todas las partes del software tienen una dificultad uniforme, directamente relacionada con algún criterio más o menos esotérico (Ej: el número de líneas de código)
- Por otro lado, a menudo se piensa que todos los proyectos de software tienen una gran cantidad de características comunes, y que las técnicas y la forma de hacer las cosas es conservadora... cuando en realidad, la naturaleza del buen software es exáctamente la contraria: LA INNOVACIÓN.
- Por último, algunos eruditos confian ciegamente en la infalibilidad de no-sé-qué herramienta estadística... y por lo tanto, defienden que los resultados que obtienen son el fiel reflejo de lo que ocurrirá. Bueno... una buena parte de las matemáticas del siglo XXI son realmente maravillosas y ciertamente exactas en sí mismas como herramientas, pero se basan en tomar datos extraidos del pasado y proyectarlos sobre el futuro, para obtener una predicción de lo que pasará. Ese resultado NUNCA será exacto, a menos que en el futuro se den EXACTAMENTE las mismas condiciones que se dieron en el pasado, y en el software no suele ocurrir eso, precisamente porque se busca que un software siempre sea distinto e innovador con respecto a cualquier software similar. Es decir, se intenta deliberadamente que no se repitan las condiciones de desarroyo de proyectos del pasado, así que sólo podemos tener una cierta esperanza en que la extrapolación del pasado al futuro que hemos realizado sobre algunas suposiciones no se desvíe demasiado de lo que realmente ocurrirá. Por supuesto que podemos encontrar proyectos de software con un enfoque conservador... pero no es (ni debe ser) la tónica general.
Es decir, las estimaciones son siempre estimaciones y normalmente aciertan más cuanto más se fijan en las similitudes con otros proyectos no demasiado distintos, en la experiencia de los involucrados y en el grado de cercanía tanto en el tiempo como en la técnica y los objetivos de los proyectos en los que se basa, pero el factor inherente al software de LA INNOVACIÓN deliberada hace que las estimaciones nunca sean exactas.
Así pues... está bien poner un cierto empeño en realizar las estimaciones con cuidado... está bien utilizar herramientas matemáticas que nos ayuden a estimar... pero no debe confiarse en que los resultados sean exactos, y tampoco debe permitirse que el propio acto de obtener una estimación conlleve una cantidad de tiempo tan considerable que supere a la posible desviación de una estimación menos costosa en tiempo... En definitiva: una estimación es una estimación... y en el software hay demasiados factores que diferencian un proyecto de otro, así que no hay que obsesionarse.
Uno de los métodos que comentaremos más adelante (el método PERT), propone que para la estimación de los tiempos, se estudie cada tarea desde tres puntos de vista: pesimista, optimista, y esperado (más probable). Es decir, si se supone para cada tarea un escenario pesimista, uno optimista y el más probable (el que se espera) y se obtiene una estimación del tiempo en cada caso, el tiempo con el que nos quedarémos responderá a la fórmula
t=(tp+4te+to)/6 Siendo tp el tiempo estimado en un escenario pesimista, te el esperado en el escenario más probable y to el esperado en un escenario optimista.
Es una forma interesante de abordarlo
Volvamos al ejemplo... Imaginemos que para nuestro ejemplo, cogemos un grupo de trabajadores cualificados del proyecto, analizamos las tareas con ellos y les pedimos opinión acerca de cuánto tiempo tardará cada una de ellas en completarse... quizá incluso pidamos que piensen en los tres escenarios... hacemos los cáculos y obtenemos éstos resultados (que añadimos a la tabla).
| Tarea: | Descripción | Precedentes | Tiempo (días) |
| A | Instalar el servidor ZZZ | - no tiene | 5 |
| B | Programar el módulo YYY | - no tiene | 4 |
| C | Programar el módulo XXX | - no tiene | 6 |
| D | Integrar el módulo YYY con el XXX | B y C | 3 |
| E | Probar YYY y XXX ya integrados en el servidor ZZZ | D | 2 |
Diagramas de Gantt, el método PERT y el método CPM
Gantt Propuso crear una cuadrícula, en la cual se representaran los distintos días en los que se desarrolla un proyecto en el eje horizontal, y cada una de las tareas en las que se descompone el proyecto en el eje vertical. Si una tarea debe realizarse en una serie de días concretos, se marcan las casillas correspondientes, formando barras. En la idea inicial de Gantt no se realizaban estudios sobre la precedencia de las tareas ni otras implicaciones.
Un diagrama de Gantt de nuestro ejemplo tendría éste aspecto:
En principio, no tiene mucha utilidad práctica. Los ajustes de cuándo debe empezar cada tarea se hacen manualmente. Por ejemplo, la tarea D, no puede empezar hasta que se terminan B y C, así que hay que colocarla el día después de que temine C (que es la que más dura). Esto es sencillo con pocas tareas, pero tremendamente tedioso cuando hay muchas.
En el eje horizontal hemos colocado los días, numerándolos del 1 en adelante. También se podrían poner fechas concretas.
Cuenta la leyenda que el método PERT fue desarrollado en los años 50 por la marina de los Estados Unidos, principalmente por un equipo capitaneado por Booz Allen Hamilton debido al desarrollo de un proyecto militar: el desarrollo de los misiles Polaris, y su posterior implantación en naves. En ese contexto, varias empresas proveedoras debían estar trabajando en paralelo sobre tareas distintas del proyecto, sin que ninguna de ellas conociera globalmente el proyecto. PERT permitía obtener estimaciones acerca del impacto de posibles retrasos en cada tarea sobre otras o sobre el proyecto entero, estimar la duración total del proyecto y alguna cosilla más.
Casi al mismo tiempo, Morgan R. Walker de la compañia DuPont y James E. Kelley, Jr. de la compañía Remington Rand desarrollaron otra herramienta matemática en el mismo sentido que PERT, pero que permitía saber qué tareas de un proyecto debían terminarse en el tiempo estimado, o de lo contrario, afectarían a la duración total del proyecto. Es decir... algunas tareas pueden admitir un cierto retraso (que empiecen más tarde, o que tomen más tiempo del estimado) sin afectar por ello a la duración total del proyecto, sin embargo, en algunas otras tareas un pequeño retraso repercute directamente en la duración total del proyecto. Pues bien, éste método, denominado CPM trataba de identificar esas tareas (llamadas tareas críticas). Al conjunto de tareas críticas se le denomina camino crítico, y de ahí el nombre del método: CPM - Critical Path Method.
Los métodos PERT y CPM, al ser numéricos, proporcionan una herramienta matemática que a partir de los datos de entrada (tareas, duraciones, precendentes, fecha de inicio del proyecto), nos devuelven para cada tarea cuándo deben empezar y terminar y qué retraso admite cada una sin afectar a la duración total del proyecto. Esos datos pueden ser luego utilizados para dibujar un diagrama de Gantt, que es mucho más atractivo que la representación numérica.
Hoy en día: el software de planificación y gestión.
Hoy en día, utilizamos software para estas tareas. Software que, lógicamente, tiene su fundamento en los tres métodos. Ninguno de los métodos se utiliza ya por separado, ni en la forma original en que fue definido.
- Las aplicaciones de planificación de hoy en día utilizan el aspecto de los diagramas de Gantt. Nosotros podemos definir nuestras tareas, introducir sus nombres, tiempos y precedencias en un software de planificación, y éste dibujará un diagrama de Gantt, que por supuesto, puede editarse y modificarse gráficamente.
- La información acerca de tiempos y precedencias permite que éstas aplicaciones, internamente apliquen las técnicas de PERT, y nos puedan dar algunas previsiones acerca del proyecto... Por ejemplo, calcular en qué día debe empezar y terminar cada tarea.
- Por último, también internamente, estas aplicaciones pueden aplicar las técnicas de CPM para identificar las tareas que, de retrasarse, afectarían a la duración total del proyecto, es decir: las tareas críticas o camino crítico.
- Como añadido, el software de planificación también permite hacer un la gestión del seguimiento del plan, en el que el gestor puede anotar el progreso de cada tarea, los recursos asignados, etc.
- Además, es posible que incorporen otras técnicas de la investigación operativa, especialmente las referidas a gestión de recursos, esfuerzo de las personas u optimizaciones.
Existen varias aplicaciones de planificación y gestión en el mercado, pero vamos a hacer un breve comentario sólo de dos. Una mirada crítica es ya cosa tuya.
En el lado Open Source.
Bajo licencia GPL se distibuye GanttProject, una aplicacion interesante escrita en Java, y que como característica curiosa, permite su ejecución directamente desde su web (con Java Web Start), aunque también puede instalarse. Cuenta con todo lo básico para una planificación temporal de tareas. Él solo las colocará en un diagrama de Gantt basándose en su duración y su precedencia, puede identificar el camino crítico, llevar una gestión de recursos (mínima) y anotar algunos seguimientos por parte del gestor.
Es una herramienta muy atractiva para iniciarse y hacer algunas pruebas.
Nosotros hemos utilizado GanttProject para introducir los datos del ejemplo que nos traemos entre manos, y lo hemos grabado en un screencast. Haz clic sobre la imagen para verlo.
Screencast de ejemplo de utilización de GanttProject.
En el lado comercial
Desde hace muchos años, Microsoft ofrece una aplicación llamada Microsoft Project Professional. Ofrece todas las características básicas que hemos comentado, además de herramientas de optimización, una gestión de recursos y personal bastante avanzada, cálculo de costes y herramientas de seguimiento para los gestores bastante sofisticadas.
También existe una versión llamada Microsft Project Server, en la que varias personas pueden realizar seguimientos colaborativamente, aportar documentación, etc... A lo grande.
Se puede conseguir una versión de prueba de ambas versiones en la página web del producto.
Conclusión
Hasta aquí llegamos hoy. En la próxima entrega dedicada a éste tema hablaremos acerca de las matemáticas involucradas en PERT y CMP, que, al menos superficialmente, suelen ser objeto de estudio en cualquier titulación relacionada con la informática.
[Continuará...]
[Imágenes de Gantt y Polaris tomadas de la wikipedia]
[Logo de GanttProject y Microsoft Project tomado de su página web. Son propiedad de sus respectivos autores]
