Si estás leyendo esto es porque seguramente sabes lo que es un diagrama de Gantt y estás esperando a ver qué voy a contar… Hace unas semanas tuve que hacer (en contra de mi voluntad) un diagrama de Gantt para especificar la planificación de un proyecto de software. No era el primero que hago, pero hacía años que los tenía olvidados.
Lo de en contra de mi voluntad es importante porque se me ocurren hasta 5 motivos por los cuales los diagramas de Gantt no sirven para planificar proyectos de software, pero aún así, en mi empresa están institucionalizados y no hay proyecto en el que no se haga un diagrama de Gantt.
5 motivos por los cuales los diagramas de Gantt no sirven para planificar proyectos de software
1. No son visuales
Es curioso porque el motivo principal es que no son visuales, a pesar de que el objetivo (como el de cualquier diagrama) es ser visual.
- ¿Alguna vez has adjuntado un diagrama de Gantt en un documento? No se ve nada.
- ¿Alguna vez has hecho un diagrama de Gantt para un proyecto con muchas etapas, meses de duración? No se ve nada.
- ¿Alguna vez has hecho un diagrama de Gantt en el que llegue otra persona (por ejemplo tu cliente) y entienda algo? No se ve nada.
- ¿Alguna vez has intentado imprimir un diagrama de Gantt? No se ve nada.
- ¿Alguna vez has intentado ver un diagrama de Gantt grande en la pantalla del ordenador? No se ve nada.
2. No hay buenas herramientas
Yo he usado OpenProj (software libre) y Microsoft Project (no comment). Ninguno de los dos sirven. El nivel de precisión que hay que tener para ajustar tiempos, mover cajitas, reordenar tareas, cambiar fechas, asignar recursos, hacen que no funcionen.
Y probablemente esté equivocado y son grandes herramientas que con práctica se consiguen dominar, etc, etc. (No me convence)
3. No reflejan la realidad
Puesto que no son visuales y no hay buenas herramientas para crear y actualizar diagramas de Gantt, lo que suele ocurrir es que no reflejan la realidad del proyecto. La realidad de un proyecto de software es que cambia contínuamente y la realidad de un diagrama de Gantt es que se queda obsoleto
contínuamente.
4. Nadie me los ha recomendado
Nadie que haga software que funciona me ha dicho nunca que sus proyectos salen bien porque planifica con diagramas de Gantt. Sin embargo, con otras herramientas más visuales, que todo el mundo entiende, fáciles de modificar, colaborativas, físicas, etc. sí. Por ejemplo, un tablero Kanban.
5. Te los enseñan en la facultad
Este motivo es tan curioso como cierto. Que en la facultad de informática te enseñen diagramas de Gantt para planificar proyectos de software ya te debería hacer sospechar. Probablemente esté equivocado, pero a mí en la universidad no me enseñaron a hacer software, porque allí (salvo excepciones) no hay nadie que haga software que utilicen miles de personas.
Pues nada, a seguir haciendo diagramas de Gantt y si alguien opina lo contrario o cree que son útiles, por favor, que me lo diga que a lo mejor puedo ser un poco más feliz la próxima vez que tenga que hacer uno de estos. Y a ver si tengo tiempo y un día cuento algunas herramientas que sí sirven para planificar proyectos de software.
Hola compañero del metal!
Me siento identificado totalmente, lamentablemente.
A mis jefes también les mola que tenga todo controlado con un Gantt, aunque sea en un Excel. Si, a pelo, sin herramientras para ello 😛
Ya estas escribiendo sobre que herramientas recomiendas 😉
Para mi el Gantt sólo sirve para definir los tiempos de las tareas y que la gente vea que llegas a tiempo. ¿?
Un saludo.
Hola César,
sí yo creo que nos pasa a muchos y el problema es caer en la dinámica de hacer cosas que no funcionan y no proponer cambiarlas.
Cuando tenga un rato ya me explayo más sobre otras formas de planificar proyectos, pero básicamente contaré cómo funcionan el tablero de Scrum, Kanban (que no son lo mismo) y herramientas hay muchas, desde montar los tableros físicos en un pared, hasta Jira agile, Trello, y un larguísimo etc.
Estimados, creo (sin ofender) que partimos del principio erróneo de pensar que tanto cambió es bueno, cuando hablas que en el desarrollo de software hay cambios continuos es por que desde el inicio no se realizan ciertas prácticas como un levantamiento adecuado de requerimientos, lo cual es muy independiente del Gantt y ojo no estoy defendiendo a estos diagramas, en Microsoft project, por ejemplo, existen líneas basé precisamente para manejar esos cambios y poderlos comparar con una planificación anterior, pero por el contrario, si no partes de un adecuado análisis de requerimientos y/o prácticas el método XP de desarrollo, ninguna herramienta de planificación te ayudara por que en la realidad NO PLANEAS, sólo reaccionas antes información diaria que recibes.
La herramienta que mencionas y dices si funcionar, a pesar de no conocerla yo, me imagino que te es útil por que te permite alto nivel de interacción, lo cual es bueno pero como te darás cuenta no tiene nada que ver con una planificación.
Mi recomendación es primero enfocarse en el principio de planificar y sobre esa línea te puedo asegurar que si el software para diagramas de Gantt no te garantizan un término excelente de proyectos, si te da argumentos para saber donde estuvo la ineficiencia de esa planificación que muchos confundimos.
Saludos.
(Yo desarrollo software web)
Hola Oswaldo,
gracias por comentar. Me gusta leer opiniones diferentes a las mías, ya que sólo expongo mi punto de vista y por supuesto, cualquier aportación me sirve 🙂
En mi caso, nunca me ha pasado el trabajar en un proyecto que no cambie de requisitos casi continuamente. Creo que es algo inherente a desarrollar software, de ahí la necesidad de herramientas que se ajusten a esa realidad.
Respecto a lo que comentas, es cierto, que me enfoco sobretodo en la interacción y la experiencia que me proporciona una herramienta para poder planificar bien. Es por eso, que los diagramas de Gantt no me gustan.
Los diagramas de Gantt los veo como algo estático y poco manejable, que no se adaptan bien a la realidad de un proyecto, que es que está vivo, donde hay tareas que se crean y van pasando por distintas fases hasta ser completadas y que muchas veces no se pueden predecir con antelación. Ese tipo de interacción no la veo en un diagrama de Gantt y sí, por ejemplo, en un tablero Kanban. Posiblemente, como comentas es otro tipo de planificación, más a corto plazo y más reactiva.
Debe haber proyectos de software con una fase de análisis muy completa, con pocos cambios y expectativas que se cumplen… sinceramente, ese tipo de proyectos no lo conozco 😛
Saludos!
Bueno supongo que dirás que ni sirven los que mencionas, para hacer un deal ( negocio) al tomar tu curso, porque no creo que lo hagas porque te preocupes de los ingenieros o informáticos ¿verdad? L.I. Luis M.
Hola,
el motivo de escribir esta entrada (hace ya unos cuantos años), como digo al principio, era que yo antes hacía diagramas de Gantt o dicho de otra forma perdía el tiempo intentando cuadrar tiempos de manera absurda.
Lo dicho, mi objetivo con este post es que reflexionemos un poco sobre las herramientas que utilizamos y cómo planificamos proyectos y que cada uno decida si lo puede hacer mejor o no.
Saludos
Tienes razón en que siempre quedan obsoletos, pero a mi ver son una forma de justificar la magnitud de un proyecto, en un tablero kanban solo vez un motón de postis pero no te dan tiempos ni fechas y es lo que los ejecutivos quieren ver, al mostrarle un diagrama de gant ellos ven muchas muchas tareas por hacer, pero lo que les importa es el tiempo y costo, cuanto tiempo va a llevar y cuanto les va a costar, algo que trato de empatar con las metodologías scrum, ya que scrum si va incrementando en cada alternación va aumentando valor al producto, da la sensación que si se esta agregando trabajo y se están dando resultados rápidamente, pero el horizonte del entregable final queda nublado por las posibles mejoras, errores, agregados que se den entre las iteracciones, tengo 12 años desarrollando y creo que para mi lo mas difícil del desarrollo no es programar es acertar en una estimación de tiempos.
Los gants me han servido para dar una estimación, justificar los tiempos, aunque los ejecutivos solo ven “cuadritos”. se dan cuenta que son muchos, que llevan un tiempo, y con ellos he podido negociar mas tiempo de entrega, pero creo que un proyecto de software será muy difícil que así como se planea de entrada se ejecute, creo que el diagrama se debe ir actualizado e ir adaptándose al avance del proyecto.
No estoy de acuerdo en absoluto… Deberíamos poner más esfuerzo en utilizar herramientas y buenas prácticas que funcionan, más allá de justificar o hacer ver cosas que no son ciertas o son imposibles de justificar.
En fin, este post me queda muy lejos, casi 5 años ya y me alegro de haberme salido de ese mundillo de la consultoría, en la que lo que importa es el trabajo mal hecho a un coste irrisorio para justificar gastos/subvenciones/presupuestos, en vez de entregar proyectos que funcionen.
Saludos.
En mi opinión coincido contigo, constantemente los clientes se enfocan principalmente en cuando inicia y cuando finaliza el proyecto, por lo tanto se termina reduciendo tu Gantt a tareas en general para que pueda comprenderse.
En ese caso lo que importa es las partes en las que dividiremos el proyecto (Etapas, Sprints, Modulos, etc) en el cual mostremos información como:
– Fecha de Inicio
– Fecha Fin
– Que incluye
– Cuanto constará en caso que aplique, hablando de personas, tiempo y dinero.
Por lo tanto llego a la conclusión que si una herramienta te genera un Gantt automáticamente a partir de tu tablero de actividades tipo Kanban, podrías generarlo si lo deseas, sin embargo el estar manejando las actividades directamente en el gantt es más complejo, por ejemplo algo sencillo es Workep que realiza algo similar a pesar que faltan muchas mejoras.
Me causa curiosidad que desde el 2013 es la publicación y aun seguimos con problemáticas de este tipo.
Saludos.