Diagrama Gantt: planificar como un estratega romano

Hay un diagrama que sobrevivió dos guerras mundiales, la llegada de la computadora personal, la era de la información, la revolución ágil, el desembarco del software y dos pandemias. Lo dibujaron en hojas cuadriculadas durante décadas, después en transparencias, después en hojas de cálculo, y hoy en aplicaciones que cuestan más al año que una computadora. Sigue ahí. No porque sea perfecto — no lo es —, sino porque resuelve, de forma visual y en pocos minutos, una pregunta que cualquier persona que haya intentado coordinar a más de tres seres humanos se hace tarde o temprano: ¿quién hace qué, cuándo, y qué pasa si algo se atrasa?

Ese diagrama lleva el nombre de un ingeniero industrial estadounidense, pero la historia — como casi siempre que se trata de "inventos" en el management — es más interesante que la versión oficial. Vale la pena contarla con calma, porque entender de dónde viene una herramienta es la única manera honesta de decidir cuándo usarla y cuándo guardarla en el cajón.

Una historia con dos padres y una injusticia

Henry Laurence Gantt nació en Maryland en 1861 y murió en Nueva Jersey en 1919. Estudió en el Stevens Institute of Technology, dio clases unos años, y a finales del siglo XIX entró a trabajar en la Midvale Steel Company. Ahí coincidió con Frederick Winslow Taylor, el hombre que estaba reescribiendo la idea misma de "trabajo" desde la metalurgia. Taylor fue su mentor, su socio en varios proyectos de consultoría y su contraparte intelectual. Gantt absorbió la ortodoxia tayloriana — la fe en la medición, en el estudio del tiempo, en la posibilidad de "racionalizar" cada movimiento del operario — pero, a diferencia de Taylor, le interesaba algo más blando: el operario en cuanto persona, los incentivos, la fatiga, el desempeño grupal. Esa diferencia importa para entender el diagrama.

Su primera publicación de peso fue Work, Wages, and Profits, en 1910. Ahí ya aparecen, en forma embrionaria, las gráficas que después llevarían su apellido. La idea era sencilla y radical para la época: en lugar de reportar la producción mediante tablas de números — la convención industrial — Gantt proponía dibujar barras horizontales sobre un eje temporal. Un golpe de vista bastaba para saber si una máquina había producido lo planeado, qué máquina iba retrasada, qué turno cumplía, dónde se atascaba la línea. La hoja de cálculo se volvía, de pronto, un mapa.

El gran ensayo histórico del diagrama vino con la guerra. Durante la Primera Guerra Mundial, Estados Unidos creó la Emergency Fleet Corporation para acelerar la construcción de barcos mercantes que reemplazaran a los hundidos por los submarinos alemanes. Gantt, ya consultor reconocido, fue contratado para coordinar la planeación. El problema era brutal: decenas de astilleros, miles de proveedores, materiales que llegaban en orden incorrecto, plazos políticamente imposibles. Para coordinar esa red de dependencias, Gantt extendió sus barras a la planificación de proyectos: cada actividad — colocar la quilla, soldar el casco, instalar las calderas — recibía una barra, una fecha de inicio y una fecha de término. La planeación dejó de ser una colección de memorandos y se volvió un objeto visual que cualquier capataz podía leer en treinta segundos. La herramienta funcionó. Los astilleros redujeron tiempos. Y Gantt entró en el panteón del management.

La parte incómoda de la historia es que, mientras Gantt afinaba sus barras en Pennsylvania, en la Polonia ocupada por el Imperio Ruso un ingeniero llamado Karol Adamiecki ya había publicado, en 1896, un diagrama prácticamente idéntico al que después popularizaría el estadounidense. Lo llamó harmonogram — armonograma —, y lo presentó por primera vez en la Sociedad Rusa de Ingenieros y Tecnólogos en Ekaterinoslav. Lo publicó en revistas técnicas en ruso y polaco entre 1898 y 1903, y de manera ampliada en 1931. Adamiecki trabajaba en la industria del acero y tenía exactamente el mismo problema que Gantt: coordinar fases de producción con dependencias estrictas. Su solución, en términos visuales, era prácticamente la misma.

El reconocimiento, sin embargo, llegó tarde y lejos. La barrera del idioma, la geografía y el poderío editorial estadounidense hicieron que Adamiecki quedara, durante medio siglo, como una nota a pie de página. Hoy los textos serios de historia del management — los de Daniel Wren, los de Morgen Witzel — citan al polaco como un descubridor independiente y, en términos cronológicos, anterior. La justicia histórica obliga a hablar del "diagrama de Gantt-Adamiecki", aunque el mercado, terco como siempre, mantenga el nombre corto. Que un buen invento tenga dos padres separados por seis mil kilómetros y un océano dice algo sobre el invento mismo: cuando una idea es lo bastante natural, varias cabezas la tienen al mismo tiempo. Y la representación de tiempo y dependencias mediante barras horizontales era, evidentemente, una idea natural.

Por qué el dibujo funciona: un detour por la ciencia cognitiva

Hay una explicación elegante para la persistencia del diagrama, y no tiene que ver con la sociología del management ni con la inercia corporativa. Tiene que ver con cómo está construido nuestro cerebro.

El psicólogo educativo australiano John Sweller propuso, a finales de los años ochenta, lo que hoy llamamos Cognitive Load Theory: la teoría de la carga cognitiva. Su tesis, traducida sin tecnicismos, es que la memoria de trabajo humana tiene una capacidad muy limitada — del orden de unos pocos elementos simultáneos — y que cualquier representación que reduzca esa carga libera capacidad para razonar. Una lista textual de cuarenta tareas con sus fechas, dependencias y responsables sobrecarga la memoria de trabajo de cualquier persona. Una representación visual donde cada tarea es una barra con posición, longitud y color, en cambio, descarga buena parte del trabajo en el sistema visual, que evolucionó para procesar enormes cantidades de información en paralelo.

Esa es, en términos cognitivos, la razón por la que un Gantt "funciona" donde una lista no funciona. No es magia, ni un ritual gerencial: es que estamos usando dos canales — el verbal y el visoespacial — en lugar de saturar uno solo. Edward Tufte, en sus libros sobre representación cuantitativa, llama a esto visualización pequeña-multiple y dimensión simultánea: la barra del Gantt comunica, al mismo tiempo, qué tarea es (etiqueta), cuándo empieza (posición), cuánto dura (longitud), si se cumplió (color o sombreado), y de qué depende (flechas o agrupación vertical). Cinco variables a la vez en un objeto visual mínimo.

Conviene tener esto presente, porque el debate de las últimas dos décadas — Gantt sí, Gantt no, ágil sí, cascada no — suele desatender el hecho de que la utilidad cognitiva del dibujo es independiente de la metodología que lo enmarca. Un equipo Scrum puede dibujar un Gantt para planear un trimestre sin volverse "cascada". Un equipo de obra civil puede usar Kanban para tareas semanales sin abandonar el Gantt del proyecto entero. La herramienta es una representación; la metodología es un proceso. Confundirlas es un error que cobra caro.

El siglo XX, los misiles y el camino crítico

Hacia los años cincuenta, el management militar y el management corporativo se cruzaron en una de esas alianzas raras de la historia. La Marina de Estados Unidos, en plena Guerra Fría, necesitaba coordinar la construcción del submarino Polaris — un proyecto con miles de proveedores, plazos imposibles y una complejidad técnica sin precedentes. La consultora Booz Allen Hamilton, en colaboración con Lockheed y la Special Projects Office, desarrolló para ese encargo el método PERT — Program Evaluation and Review Technique —, que tomaba el espíritu del Gantt y lo formalizaba matemáticamente. Cada actividad recibía no una duración, sino tres: optimista, más probable y pesimista. El método combinaba esas distribuciones para estimar la probabilidad de cumplir un plazo.

En paralelo, ingenieros de DuPont y Remington Rand desarrollaron el Critical Path Method (CPM), pensado originalmente para mantenimiento de plantas químicas. La idea central — que se mantiene hasta hoy en cualquier software serio de gestión de proyectos — es que en una red de tareas con dependencias hay siempre un camino crítico: la cadena de actividades cuya suma de duraciones determina la fecha mínima de finalización del proyecto. Si una tarea fuera de ese camino se atrasa un día, no pasa nada. Si una tarea del camino crítico se atrasa un día, todo el proyecto se atrasa un día.

PERT y CPM no sustituyeron al Gantt. Lo enriquecieron. La práctica común — y razonable — es usar el camino crítico para identificar dónde poner atención, y el Gantt para comunicar el plan al resto del equipo. Una cosa es la matemática del proyecto; otra es su representación. Cuando se hablan de "Gantt modernos" en software como Microsoft Project o Primavera, en realidad se habla de un Gantt enriquecido con cálculo de camino crítico, holgura por tarea y simulación de retrasos.

La crítica seria: por qué los planes optimistas son la regla

Hasta aquí el aplauso. Ahora la parte difícil. Porque desde mediados de los años setenta, cada vez que alguien dibuja un Gantt para un proyecto de software, de creación, de investigación o de cualquier actividad con incertidumbre seria, el destino del diagrama es chocar contra la realidad. Y la literatura de management se ha encargado, con paciencia, de explicar por qué.

El primer aviso serio vino de Frederick Brooks, ingeniero de IBM y arquitecto del sistema operativo OS/360, en su libro The Mythical Man-Month (1975). Brooks formuló lo que hoy se conoce como Ley de Brooks — "agregar gente a un proyecto de software atrasado lo atrasa más" — y describió, con una honestidad poco común, cómo planes detallados con cientos de tareas y fechas precisas se desmoronaban frente a problemas que nadie había previsto. Su diagnóstico fue elegante: el software no es una línea de ensamble. Cada tarea es, en cierto sentido, original. La estimación basada en analogías históricas falla porque la analogía rara vez es buena. Y cuando un proyecto se atrasa, la respuesta intuitiva — meter más programadores — produce el efecto contrario, porque el costo de comunicación crece cuadráticamente con el tamaño del equipo.

Tom DeMarco y Tim Lister extendieron el argumento en Peopleware, libro publicado por primera vez en 1987 y revisado en sucesivas ediciones. Su tesis: en proyectos donde el factor humano es dominante, los plazos optimistas son la regla, no la excepción. La presión por dar buenas noticias hace que las estimaciones se ajusten hacia abajo. Los gerentes piden compromisos, los equipos los entregan, y el Gantt se firma sabiendo, en algún rincón silencioso del cuarto, que no se cumplirá. El proyecto entra en una marcha forzada de la que es difícil salir.

El golpe definitivo, sin embargo, vino del lado de la psicología. Daniel Kahneman, en colaboración con Amos Tversky, describió desde los años setenta lo que hoy se llama planning fallacy: la tendencia sistemática de las personas a subestimar el tiempo y los recursos necesarios para completar tareas, incluso cuando han hecho tareas similares antes y conocen sus plazos reales. Kahneman recoge la idea en Thinking, Fast and Slow (2011) con un ejemplo memorable de su propia carrera: un comité que él mismo formó para escribir un libro de texto estimó que terminaría el trabajo en dos años; finalmente tardó ocho. Roger Buehler, Dale Griffin y otros psicólogos sociales han documentado la falacia con docenas de experimentos desde los años noventa: pedir a un estudiante que estime cuánto tardará en terminar su tesis produce, sistemáticamente, un número menor al real, incluso si el mismo estudiante recuerda con precisión cuánto tardó en su tesis anterior.

La razón cognitiva detrás de la falacia es, otra vez, elegante: cuando estimamos el futuro, construimos un escenario plausible — el "mejor caso" mentalmente disponible — y le ponemos un número. Olvidamos sistemáticamente las interrupciones, los problemas no anticipados, los días en que estamos enfermos, las reuniones imprevistas, los proveedores que no responden, los archivos que no compilan. El cerebro elabora un guion limpio y le pone fecha. La realidad, como siempre, es desordenada.

Por si todo lo anterior fuera poco, está la Ley de Hofstadter, formulada por Douglas Hofstadter en Gödel, Escher, Bach (1979): "siempre toma más tiempo del que esperas, incluso cuando tomas en cuenta la Ley de Hofstadter". El chiste es serio: la falacia es recursiva. Si sabes que sueles subestimar y multiplicas tu estimación por dos, sigues subestimando, porque la corrección también está sujeta al mismo sesgo.

¿Qué hace todo este cuerpo de evidencia con el Gantt? Lo coloca en su sitio. El diagrama no es culpable de la falacia: es un papel. Pero el Gantt suele dar al plan un aire de precisión que el plan no tiene. Una barra dibujada del 7 al 21 sugiere que la tarea termina el 21. La realidad probable, en proyectos con incertidumbre, es que la tarea termina entre el 18 y el 35, con una distribución asimétrica hacia la derecha. El diagrama dice "21". Es ahí donde empieza el problema.

La revuelta ágil y el regreso del Gantt por la puerta trasera

A principios de los años dos mil, un grupo de programadores hartos de los Gantt de mil tareas firmó en Snowbird, Utah, el Manifesto for Agile Software Development. La crítica era directa: la planeación detallada por adelantado, con dependencias rígidas y fechas precisas, no funciona para software. Se necesitaban ciclos cortos, retroalimentación frecuente, capacidad de adaptación. Nacieron — o terminaron de instalarse — Scrum, Extreme Programming, Kanban, y la familia de prácticas que hoy se agrupa bajo "ágil".

Durante una década, el Gantt se volvió palabra incómoda. Quien lo dibujaba en una junta de software era visto como un dinosaurio. Pero, como suele ocurrir con los pendulazos, la realidad terminó imponiéndose. Las grandes organizaciones ágiles descubrieron que coordinar veinte equipos Scrum sin alguna forma de visualización temporal de iniciativas era imposible. Aparecieron los roadmaps, los now/next/later, los SAFe Program Increments y, eventualmente, los Gantt rebautizados con nombres más amigables. Hoy, casi cualquier herramienta moderna de gestión — Jira, Asana, Linear, Monday — incluye una vista temporal con barras horizontales, dependencias y fechas. Es un Gantt, aunque la documentación lo llame "Timeline" o "Cronograma".

La lección honesta del último cuarto de siglo es que el Gantt sirve para comunicar plazos en horizontes de meses y para coordinar dependencias entre equipos, pero no sirve para microgestionar tareas dentro de un equipo en proyectos con alta incertidumbre. Para eso último, los tableros Kanban — derivados del sistema Toyota — son superiores: muestran flujo, no calendario. Para horizontes cortos, las pizarras de Scrum y los gráficos burndown miden ritmo, no fechas absolutas. Cada herramienta su nicho.

Cuándo el diagrama sirve de verdad

Tras un siglo de uso, la pregunta no es si el Gantt es bueno o malo, sino cuándo conviene dibujarlo. La distinción que más se sostiene en la práctica es entre proyectos con dependencias rígidas y baja incertidumbre y proyectos con incertidumbre alta. La frontera es porosa, pero la heurística sirve.

En el primer grupo entran obras civiles, construcciones, mudanzas industriales, eventos masivos, instalaciones de equipo, montajes audiovisuales con fecha cerrada, campañas logísticas, cosechas, producciones cinematográficas, lanzamientos de hardware, ensayos clínicos, despliegues regulatorios, cierres contables. En todos estos casos, las dependencias son materiales — el cemento debe fraguar, el actor debe estar presente, el contenedor debe llegar al puerto, el reactivo debe cumplir cadena de frío — y la duración de cada actividad varía relativamente poco. Aquí el Gantt es la herramienta correcta. La planeación adelantada paga. El camino crítico se identifica con cierta confianza. Y el diagrama funciona como contrato visual entre partes.

En el segundo grupo entran el desarrollo de software original, la investigación científica, la creación artística, la exploración de nuevos mercados, la innovación de producto, la consultoría estratégica, la negociación política, la escritura de un libro. Aquí cada tarea es, en cierto sentido, irrepetible. La estimación es tan ancha que la barra del Gantt deja de ser informativa: si "diseñar el feature X" puede durar entre dos y diez semanas, dibujar una barra de cuatro semanas es decir una verdad falsa. En estos contextos, los Gantt detallados son un teatro: nadie los cumple, todos firman.

Hay un tercer grupo, y es el más interesante: proyectos mixtos. Una startup que lanza un producto físico tiene componentes de hardware (Gantt sirve) y componentes de software (Gantt traiciona). Una agencia que produce un comercial tiene logística (fechas duras) y creatividad (fechas blandas). El error frecuente es aplicar la misma herramienta a las dos mitades. La práctica madura es usar Gantt en la parte rígida y Kanban o ciclos cortos en la parte blanda, manteniendo entre las dos mitades una conversación regular de sincronización.

El antídoto contra la falacia: estimar como si supieras que te equivocas

Si la planning fallacy es real — y la evidencia es sólida —, entonces dibujar un Gantt sin corregir por ella es construir un castillo de naipes con barras de colores. Hay tres antídotos serios, todos compatibles entre sí.

El primero es la reference class forecasting, propuesta por Daniel Kahneman y desarrollada por Bent Flyvbjerg, profesor de Oxford especializado en megaproyectos. La idea: en lugar de estimar tu proyecto desde dentro — pieza por pieza —, busca proyectos comparables ya terminados y mira cuánto tardaron. Tu estimación interna probablemente diga "ocho meses". La distribución histórica de proyectos similares probablemente diga "entre doce y veinte". La diferencia es la corrección por sesgo. Flyvbjerg ha mostrado, en estudios de cientos de megaproyectos, que esta técnica reduce sobrecostos y sobreplazos de manera consistente.

El segundo es el buffer agregado, propuesto por Eliyahu Goldratt en Critical Chain (1997). En lugar de añadir un colchón a cada tarea — que se consumirá por la Ley de Parkinson, según la cual el trabajo se expande hasta llenar el tiempo asignado —, se quitan los colchones individuales y se concentran en un único buffer al final del proyecto. La pregunta deja de ser "¿se atrasó la tarea?" y pasa a ser "¿cuánto buffer agregado consumimos?". Es una mejora real. Las herramientas que implementan camino crítico con buffer son más realistas que los Gantt clásicos.

El tercero es la tres puntos heredada de PERT: estimar cada actividad con valores optimista, más probable y pesimista, y usar la combinación ponderada para calcular la duración esperada. No es exacto, pero produce números menos engañosos que un punto único. Y, sobre todo, obliga a quien estima a confrontar el escenario malo, lo cual reduce el sesgo.

Ninguno de los tres elimina la falacia. La atenúan. La planeación realista no es la que acierta — eso es imposible —, sino la que sabe que no acertará y prepara mecanismos para ajustarse cuando la realidad se desvíe.

El Gantt como objeto de comunicación, no como contrato

Peter Drucker, en sus textos clásicos sobre management — The Practice of Management (1954), The Effective Executive (1967) —, insistía en una idea sencilla y a menudo olvidada: el plan es un instrumento de comunicación, no una predicción. Un Gantt sirve para que el equipo entienda qué pasa primero, qué pasa después, qué depende de qué. Sirve para que el cliente entienda dónde se invertirá el dinero. Sirve para que el inversor vea la lógica del despliegue. Pero no sirve para garantizar que las cosas ocurran tal como las dibujaste.

Esta distinción cambia el tono del trabajo de planeación. Si el Gantt es comunicación, su valor está en lo claro y honesto que sea. Una barra exageradamente detallada en un proyecto incierto comunica falsa precisión, y la falsa precisión, en management, es peor que la imprecisión. Una barra agrupada — "fase de descubrimiento, mes 1-3" — comunica honestidad. El equipo sabe lo que sabe y lo dibuja como tal. Cuando llegue el detalle, se dibujará. Es lo que la literatura ágil llama rolling-wave planning: planear con detalle el horizonte cercano y con grano grueso el horizonte lejano. La técnica es vieja — los marinos la usaban en el siglo XIX — y reaparece bajo distintos nombres porque resuelve un problema permanente.

Las patologías corporativas del diagrama

Vale la pena nombrar, sin nostalgia, las formas en que el Gantt se corrompe en organizaciones grandes. La primera es la hipertrofia: cronogramas con seiscientas, mil, dos mil tareas. Nadie los actualiza. Nadie los lee. Cumplen una función ritual: existir. La segunda es la actualización fingida: el Gantt se mueve hacia adelante a medida que la realidad se desfasa, sin admitir el desfase. Las fechas oficiales son amables; las reales, otras. La tercera es el Gantt de cara al jefe: un cronograma que existe sólo para mostrar a la dirección que "hay un plan". Lo elabora un consultor, lo aprueba un comité, nadie lo usa.

Estas patologías no son culpa del diagrama; son culpa de la cultura organizacional que lo emplea. Pero el Gantt es especialmente vulnerable a ellas porque su apariencia de control es seductora. Mirar la pantalla con barras de colores ordenadas produce sensación de dominio. La sensación de dominio adormece la atención. Y en management, la atención adormecida es el primer paso hacia el desastre.

El antídoto es viejo y se llama reuniones de revisión honestas. Reuniones donde alguien pregunta "¿en qué nos equivocamos?" antes de preguntar "¿cuándo vamos a recuperar?". Reuniones donde se admite que la fase de descubrimiento tomó tres semanas más, no porque el equipo sea malo, sino porque el problema era más complejo de lo que parecía. Esa información, alimentada de regreso al Gantt, mejora la siguiente versión. El Gantt deja de ser un compromiso con el pasado y se vuelve una hipótesis sobre el futuro.

Una nota sobre el horizonte temporal

Hay un aspecto rara vez discutido y que importa más de lo que parece: el horizonte temporal del diagrama determina su utilidad. Un Gantt para un fin de semana — "instalar el sistema solar en la casa" — es probablemente útil: el horizonte es corto, la incertidumbre se controla, las dependencias son materiales. Un Gantt para tres años — "transformación digital de la empresa" — es probablemente fantasía: a tres años nadie sabe qué tecnología existirá, qué proveedores quebrarán, qué prioridades tendrá la dirección.

La regla razonable, sin pretensión de ley universal, es que el Gantt es útil para horizontes donde la incertidumbre acumulada es manejable. Para construcción, eso pueden ser dos años. Para producto digital, tres meses. Para investigación, quizá ocho semanas. Más allá de ese horizonte, el diagrama sigue dibujándose, pero ya no comunica realidad: comunica deseo. Saberlo no significa abandonar el dibujo; significa leerlo con la suspicacia adecuada.

El diagrama y la dicotomía de lo controlable

Hay un último uso del Gantt que la literatura técnica no destaca y que vale la pena rescatar. Cuando se dibuja honestamente, el diagrama deja ver — sin necesidad de decirlo — qué partes del proyecto dependen de quien planea y qué partes dependen de terceros. La fila de "esperar feedback del cliente", "recibir aprobación regulatoria", "obtener firma del proveedor", "depender del clima" es exactamente la fila donde no hay control. La barra existe pero no se ejecuta; sólo se espera.

Esa visibilidad es valiosa. Permite al responsable distinguir entre dos tipos de retraso: el retraso por mala ejecución propia — que requiere autocrítica — y el retraso por dependencia externa — que requiere otra cosa, generalmente paciencia o presión política. Confundirlos es un error frecuente. El Gantt, bien leído, los separa. Y separa también las palancas: para la primera categoría, mejor método; para la segunda, mejor relación, mejor contrato, mejor plan B.

Si al cabo del ejercicio el diagrama muestra que la mayoría de las barras dependen de terceros, el proyecto es más frágil de lo que su responsable quería admitir. Vale más saberlo en la hoja de planeación que descubrirlo cuando el cliente cuelga el teléfono.

Cierre: la herramienta y su humildad

Ninguna herramienta sobrevive un siglo por casualidad. El diagrama de Gantt — o, si se hace justicia, el harmonograma de Adamiecki — sobrevivió porque resuelve, mejor que casi cualquier alternativa, un problema cognitivo concreto: representar tiempo y dependencias en una superficie bidimensional para que un cerebro humano las procese de un vistazo. Eso es lo que hace bien, y conviene reconocerlo.

Lo que el diagrama no hace — lo que no hace ningún plan — es predecir el futuro. La planning fallacy seguirá operando mientras existan seres humanos. Brooks seguirá teniendo razón sobre el software. DeMarco y Lister seguirán teniendo razón sobre los plazos optimistas. Hofstadter seguirá riéndose desde la nota al pie. El proyecto seguirá tomando más tiempo del previsto, incluso cuando el plan considere que tomará más tiempo del previsto. Esa es la parte de la historia que no cambia.

La conclusión razonable, después de un siglo, no es triunfalista ni nihilista. Es modesta. El Gantt es una herramienta de comunicación útil cuando se reconoce su naturaleza — un dibujo del presente sobre cómo imaginamos el futuro —, cuando se acompaña de los métodos correctos — camino crítico, buffer agregado, reference class forecasting, revisión honesta —, y cuando se aplica a problemas donde tiene sentido. Para construir un edificio, sí. Para escribir un libro, con reservas. Para innovar en un mercado nuevo, con muchísimas reservas y, probablemente, mejor en una pizarra que en un software con licencia anual.

El error no es dibujar Gantts. El error es creerles. Quien planea sabiendo que su plan es una hipótesis y no una promesa hace, al final, mejores proyectos que quien planea creyendo que sus barras son la realidad. La historia del management — desde Taylor hasta hoy — es, en buena medida, la lenta y dolorosa aceptación de esa diferencia. Cien años después de la primera barra de Henry Gantt, el diagrama sigue ahí, no porque haya resuelto el problema de la incertidumbre — nadie lo ha resuelto —, sino porque, dentro de sus límites, sigue siendo el menos malo de los espejos donde un proyecto puede mirarse antes de empezar.

---

Continúa la lectura

• Decisiones bajo incertidumbre: heurística estoica
• La paciencia del emprendedor: lecciones de Crisipo
• Pack Emprendimiento: del caos al pipeline
• Productividad sin culpa: el método estoico

Si quieres trasladar lo leído a una práctica concreta, una herramienta estructurada que usamos nosotros para esto es Planificador Gantt — una hoja de Google Sheets diseñada para sostener la práctica diaria sin abandonar el método al primer cansancio.