Диаграмма Ганта

Назначение: визуализация расписания проекта и его прогресса.

Аудитория: PM, команда, стейкхолдеры.

Статус: устоявшийся (Henry Gantt, 1910–1917).

Не путать с: сетевой диаграммой и PERT (в них важна логика зависимостей — см. «Сетевое планирование»), Kanban-доской (она показывает поток работы, а не расписание), а также сам инструмент не путайте с методом критического пути, который лишь отображается на Гантте подсветкой («Критический путь»).

Общее #

Диаграмма Ганта (Gantt chart) — ленточная диаграмма расписания проекта: каждая задача изображается горизонтальной полосой на шкале времени, а длина полосы соответствует длительности задачи. Вся архитектура диаграммы держится на одном принципе: время идёт слева направо, задачи — сверху вниз. Вертикальная ось — состав работ (что делаем), горизонтальная ось — календарь (когда и как долго).

Диаграмма отвечает сразу на несколько вопросов, которые возникают у любого участника проекта: какие задачи входят в проект, когда они начинаются и заканчиваются, что за чем идёт, что можно делать параллельно, где находятся ключевые вехи (milestones) и насколько фактический ход работ отклоняется от плана. Именно поэтому Гантт стал lingua franca проектного управления: разработчик, PM и топ-менеджер смотрят на одну и ту же картинку и понимают друг друга без перевода.

В жизни проекта диаграмма играет три роли:

• Планирование. Расписание «собирается»: длительности, зависимости и календари дают даты; невозможные сроки и конфликтующие требования видны ещё до старта работ.
• Коммуникация. Гантт — основной язык переговоров о сроках с заказчиком, спонсором и смежными командами: сдвиг одной полосы наглядно показывает последствия для всего проекта.
• Контроль. Фактические даты наносятся на диаграмму рядом с плановыми; отклонения и прогноз завершения становятся видимыми и измеримыми.

И в каждой из ролей важно помнить, чего на Гантте нет: очередей и потока работы, загрузки конкретных людей, вероятностной природы оценок. Границы инструмента разобраны в разделе «Ограничения и критика».

Терминологическая оговорка: в русскоязычной практике равнозначно употребляются «диаграмма Ганта», «график Ганта», «ленточный график» и «ленточная диаграмма» — все названия описывают один инструмент. Стоит также различать расписание (schedule — модель сроков с зависимостями и ресурсами) и его представление: Гантт — это вид расписания, а не само расписание.

Важно понимать место диаграммы среди родственных инструментов. Сетевые методы — CPM и PERT — отвечают на вопрос «как задачи связаны и что определяет срок проекта» (см. «Сетевое планирование» и «Критический путь»). Диаграмма Ганта — это календарное представление той же модели: она берёт рассчитанные длительности и зависимости и раскладывает их по датам. Гантт не заменяет сетевой анализ, а показывает его результат в самом наглядном виде.

Название диаграмма получила по имени Генри Лоуренса Гантта (Henry Laurence Gantt, 1861–1919), американского инженера-организатора, сподвижника Фредерика Тейлора, который с 1910-х годов применял ленточные графики в производстве и описал их в книгах Work, Wages, and Profits (издания 1910 и 1916 годов). Историческая справедливость, впрочем, требует оговорки: ещё в 1896 году польский инженер Кароль Адамецкий (Karol Adamiecki) разработал практически тот же инструмент — гармонограмму (harmonogram). Подробнее — в разделе «История».

Тезис, который стоит держать в голове при работе с Ганттом: это не «лучший инструмент планирования», а самый понятный для стейкхолдеров. Его сила — в коммуникации, и именно поэтому диаграмма пережила столетие и две смены управленческих парадигм.

История #

Гармонограмма Адамецкого (1896) #

Первым ленточные графики формализовал Кароль Адамецкий — польский инженер, работавший в конце XIX века в России над организацией металлургического производства. В 1896 году он разработал гармонограмму — графический метод согласования работ во времени, где операции изображались полосами, а их взаимное расположение подбиралось так, чтобы «гармонизировать» производственный поток. Адамецкий позже основал в Польше собственную научную школу организации труда; полное описание метода он опубликовал только в 1931 году — на польском языке, что надолго скрыло его приоритет от западного мира.

Генри Гантт и Первая мировая война (1910–1917) #

Генри Гантт пришёл к ленточным графикам независимо от Адамецкого — через работу с производственными заказами и учёт труда. В книгах Work, Wages, and Profits (1910) и последующих изданиях он описал «производственные календарные графики»: по строкам — станки или заказы, по столбцам — дни, в клетках — выполненная работа. Ключевая идея Гантта — сделать ход работы против плана видимым для мастера: график ежедневно обновлялся и показывал отставание ещё до того, как оно становилось необратимым.

Массовую известность диаграмма получила в годы Первой мировой войны (1917–1919), когда её применяли в американских судостроительных и военных программах: тысячи параллельных работ, жёсткие дедлайны и дефицит ресурсов требовали инструмента, который показывает расписание целиком. После войны диаграмма закрепилась в стандартах промышленного инжиниринга США.

XX век: от бумаги к плану-графику стройки #

В межвоенный и послевоенный период ленточные графики стали стандартным инструментом в строительстве и тяжёлой промышленности по обе стороны океана. Идеи Адамецкого развивались польской школой организации производства, а в советской инженерной традиции прижился «ленточный график» — упрощённый Гантт без явных зависимостей, ставший обязательным атрибутом строек и планов эпохи Госплана. Ограничение бумажной технологии было существенным: при десятках работ график приходилось перерисовывать, поэтому зависимости между задачами изображали редко — и именно этот пробел в 1950-х закрыли сетевые методы CPM и PERT (см. «Сетевое планирование»), которые дали ленточным графикам математическую основу: рассчитанные критический путь, резервы времени и даты раннего/позднего старта.

Цифровая эра #

Компьютеризация вернула диаграмме популярность: Primavera (с 1983 года) и Microsoft Project (с 1984 года) сделали пересчёт расписания с учётом зависимостей мгновенным, а Гантт — основным экраном проекта. В 2000-е появились облачные инструменты (Smartsheet, Asana, OpenProject, GanttPRO), а экосистема Jira — плагины BigGantt/BigPicture и встроенный модуль Advanced Roadmaps. Сегодня диаграмма Ганта — самый распространённый способ показать расписание: по оценке PMI, это основное представление расписания в подавляющем большинстве проектных организаций (см. Practice Standard for Scheduling, 2010).

Столетие инструмента подытожил историк James M. Wilson в статье Gantt Charts: A Centenary Appreciation (International Journal of Project Management, 2003): Гантт пережил свои технологические ограничения трижды — бумагу, калькулятор и мейнфрейм, — потому что решал не вычислительную, а коммуникационную задачу.

Анатомия диаграммы #

Классическая диаграмма Ганта собирается из небольшого набора элементов. Разберём их на примере упрощённого плана выпуска веб-сервиса:

                     Нед 1     Нед 2     Нед 3     Нед 4
                  ├─────────┼─────────┼─────────┼─────────┤
1. Анализ ТЗ      ▓▓▓▓▓▓▓▓
2. Дизайн               ▓▓▓▓▓▓▓▓▓▓▓▓
3. Разработка                   ▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░
4. Тестирование                             ░░░░░░░░░░░░░░
5. Релиз                                                ◆

▓  — выполненная часть задачи     ░  — план (ещё не выполнено)
◆  — веха (milestone), нулевая длительность

Зависимости в примере: 1 → 2 (Finish-to-Start), 2 → 3 (Finish-to-Start), 3 → 4 (Start-to-Start + 6 дней), 4 → 5 (Finish-to-Start). Теперь — по элементам.

Строки задач (task rows) #

Каждая строка диаграммы — задача, пакет работ или сводный элемент. Источник строк — иерархическая структура работ (Work Breakdown Structure, WBS), которая декомпозирует содержание проекта до измеримых пакетов работ; отдельной статьи о WBS в Базе Знаний пока нет. Чем ниже уровень декомпозиции, тем детальнее расписание — и тем дороже его поддержание: практический компромисс для большинства проектов — 100–500 строк задач.

Шкала времени (timeline) #

Горизонтальная ось — календарная шкала: дни, недели или месяцы в зависимости от горизонта и детализации проекта. На шкалу наносятся выходные и праздники (рабочий календарь), контрольные точки отчётности и текущая дата — вертикальная линия «сегодня», слева от которой план уже должен быть выполнен.

Выбор масштаба — баланс: слишком мелкая шкала (дни на годовом проекте) делает диаграмму нечитаемой, слишком крупная (месяцы на двухнедельном проекте) скрывает детали. Современные инструменты решают проблему скользящим масштабом: недели на общем виде, дни на выбранном фрагменте.

Полосы (bars) #

Полоса — главный элемент: её левый край — дата начала, правый — дата окончания, длина — длительность задачи. Внутри полосы часто показывают прогресс: закрашенную часть (на схеме выше — ▓) и оставшуюся (░). Полосы сводных (родительских) задач собираются из подчинённых и не имеют собственной длительности.

Вехи (milestones) #

Веха — точечное событие с нулевой длительностью: согласование требований, подписание контракта, старт приёмки, релиз. На диаграмме вехи изображаются ромбами (◆) или флажками. Вехи — «скелет» проекта для стейкхолдеров: топ-менеджменту обычно достаточно календаря из 10–15 вех, чтобы понимать состояние проекта.

По происхождению вехи делятся на два типа: внешние обязательства (даты из договора, регуляторные сроки, выставки — их нельзя двигать без изменений в договоре) и внутренние контрольные точки (согласованные командой моменты сверки — их можно пересматривать). Смешение этих типов — типичная причина конфликтов: внутренняя веха, которую заказчик считает обязательством, превращается в сюрприз для команды.

Зависимости (dependency links) #

Зависимости соединяют полосы стрелками и показывают логику расписания: что должно закончиться или начаться, чтобы могла начаться следующая задача. Различают четыре типа связей — Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish — им посвящён отдельный раздел ниже. Именно зависимости превращают набор полос в модель расписания: без них диаграмма — просто список дат, с ними — сеть, которую можно рассчитывать и оптимизировать.

Практическое правило: зависимости должны отражать логику работ («нельзя тестировать непостроенную сборку»), а не управленческие желания («начните дизайн 15-го, так написано в письме»). Календарные ограничения (не раньше чем / не позже чем) задаются отдельным механизмом constraints — смешение их с логическими связями делает модель хрупкой: при первом же сдвиге расписание рассыпается.

Сводные задачи (summary / roll-up tasks) #

Сводные задачи — родительские элементы иерархии: их полосы «накатываются» (roll-up) из подчинённых задач — от начала самой ранней до конца самой поздней. Они дают верхний обзор без детализации: на печати для руководства показывают два верхних уровня, команде — детальные нижние. Типичная иерархия выглядит так:

1.  Веб-сервис 0.1        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░   ← сводная (roll-up)
    1.1. Анализ ТЗ        ▓▓▓▓
    1.2. Дизайн                 ▓▓▓▓▓▓
    1.3. Разработка                       ▓▓▓▓▓▓▓▓░░░

Сводные задачи не имеют собственной длительности и не содержат работы — попытка «исполнять» сводную задачу вместо пакетов работ признак плохой декомпозиции.

Критический путь #

Расширенные диаграммы подсвечивают критический путь — цепочку задач, задержка каждой из которых сдвигает срок всего проекта (обычно красным цветом полос). Методика расчёта пути разобрана в статье «Критический путь»; здесь важно другое: подсветка критического пути — обязательный элемент любого Гантта с числом задач больше ~20. Без неё диаграмма не отвечает на главный вопрос — чем из текущих задач проект управляется, а чем рискует.

Базовый план и факт (baseline vs actual) #

Зрелые инструменты хранят baseline — утверждённую версию расписания — и рисуют фактические полосы поверх плановых: отставание видно как смещение полос, проценты выполнения — как заполнение полос. Без baseline диаграмма показывает только «текущее мнение» о проекте; с baseline — измеримую динамику против обязательств. Подробно — в разделе «Baseline и контроль».

Ресурсы (resource assignment) #

Рядом с полосой или внутри неё указывается исполнитель — человек, роль или команда. Назначение ресурсов связывает расписание с ответственностью и матрицей RACI (Responsible, Accountable, Consulted, Informed; отдельной статьи о RACI в Базе Знаний пока нет), а также является входом для ресурсного анализа: перегрузку одного исполнителя полосы не показывают — для этого строят ресурсные гистограммы и выравнивание (resource levelling).

Как читать диаграмму #

Последовательность, в которой имеет смысл разбирать Гантт человеку, не знакомому с проектом:

1. Шкала и горизонт — каков масштаб проекта: недели, месяцы, годы.
2. Вехи — календарь ключевых событий задаёт «скелет» повествования.
3. Критический путь и зависимости — что определяет срок проекта и от чего зависит текущая фаза.
4. Линия «сегодня» и проценты выполнения — где проект находится относительно плана прямо сейчас.
5. Отклонения от baseline — если план и факт расходятся, то насколько и на каких задачах.

Стейкхолдерам обычно достаточно пунктов 1–2; PM обязан видеть все пять.

Типы зависимостей и lead/lag #

Реалистичность расписания определяется не полосами, а связями между ними: именно зависимости решают, что произойдёт с датами, когда одна задача задержится. Стандарт (PMI Practice Standard for Scheduling) фиксирует четыре типа связей.

Замечания к таблице:

• FS — типовая связь: по разным оценкам, 90–95% зависимостей реальных расписаний — Finish-to-Start. Она соответствует естественной логике «сначала — потом».
• SS и FF используются для параллельных работ с общим ритмом: их применение — главный ресурс сжатия расписания без сокращения состава работ (длинные последовательные цепочки FS часто искусственны).
• SF — экзотика: в большинстве инструментов поддерживается, но осмысленно применяется редко (дежурные смены, замена систем без остановки сервиса). Если SF появляется в плане — это повод перепроверить логику.

Наглядно четыре типа связей выглядят так:

FS  финиш → старт
    A ██████████
                  B ██████████
    B стартует после окончания A

SS  старт → старт
    A ████████████████
    B ████████████
    B стартует вместе со стартом A (возможно, с лагом)

FF  финиш → финиш
    A       ██████████
    B ████████████████
    B заканчивается не раньше окончания A

SF  старт → финиш
    A             ██████████
    B ████████████████████
    B заканчивается после старта A

Lead и lag #

К любой связи можно добавить смещение:

• Lag (задержка, +n) — последующая задача сдвигается вперёд по времени относительно связи. Пример: FS + 3 дня — покраска начинается через 3 дня после окончания штукатурных работ, потому что стены должны высохнуть. Лаг — способ отразить в расписании технологические ожидания, не создавая фиктивных задач «сушка».
• Lead (забегание, −n) — последующая задача начинается до завершения предшественника. Пример: FS − 2 дня — тестировщики начинают прогонять готовые модули за два дня до формального окончания разработки. Lead — основной приём fast tracking (совмещения работ), и он небесплатен: совмещение увеличивает риск переделок, если предшественник «поплыл».

Когда какой тип связи применять:

• FS — по умолчанию: любую последовательность начинайте с Finish-to-Start — это наименее рискованная и лучше всего понимаемая связь.
• SS — для параллельных процессов с общим стартом: строительство и поставки оборудования, разработка и документация. Уточняется лагом: SS + 5 — «документация стартует через 5 дней после начала разработки».
• FF — для финальных синхронизаций: приёмка не закрывается раньше устранения замечаний; демонтаж старой системы заканчивается не раньше монтажа новой.
• SF — почти никогда: единичные сценарии с непрерывными процессами (сменный график, горячее резервирование систем).

Правило применения: lag — это честное отражение физики процесса, lead — осознанный риск-компромисс. Расписание, в котором десятки lead’ов, — это расписание, которое планирует одновременное делать всё сразу; его реалистичность следует отдельно проверять (например, методом Монте-Карло — см. «Статистический анализ»).

Baseline и контроль #

Что такое baseline #

Baseline (базовый план расписания) — утверждённая и «замороженная» версия расписания: состав задач, длительности, зависимости и даты. Baseline фиксируется после согласования плана и служит точкой отсчёта: с ней сравнивается факт. Без baseline невозможно ответить на вопрос «мы отстаём или нет» — можно только видеть текущее расписание, которое незаметно подстраивается под факт. В терминологии PMBOK базовый план расписания (schedule baseline) — один из обязательных артефактов плана управления проектом.

Сравнение факта с планом #

Контроль по Гантту сводится к регулярному (обычно еженедельному) обновлению фактических дат и процентов выполнения с привязкой к дате отчёта (status date):

• Смещение полос — фактические даты против плановых: задача началась позже, длится дольше, закончилась позже.
• Процент выполнения — заполнение полосы; способы оценки: 0/100 (задача либо не начата, либо готова), 50/50, физический процент (объём сделанного). Оценка «по ощущению 90%» — классическая ловушка: правило 90-процентного синдрома гласит, что задача может оставаться «почти готовой» сколь угодно долго.
• Скользящий прогноз — если полосы сместились, оценивается новая дата завершения проекта и расстояние до ближайших вех.

Фрагмент диаграммы с baseline (план — ░, факт — ▓):

3. Разработка
   план  ░░░░░░░░░░░░░░
   факт     ▓▓▓▓▓▓▓▓▓▓░
            ↑ фактический старт на 3 дня позже планового

На практике контроль оформляется в еженедельный цикл: обновление факта на status date, обзор сместившихся задач и вех, разбор причин топ-3 отклонений, пересмотр прогноза даты завершения. Важно обновлять расписание целиком, а не только «проблемные» задачи — иначе картина отклонений становится избирательной и деградирует в отчёт «всё идёт по плану».

Earned Value по задачам #

Количественная основа контроля — метод освоенного объёма (Earned Value Management, EVM): по каждой задаче сопоставляются плановая стоимость запланированных работ (PV), освоенный объём (EV) и фактические затраты (AC); индекс выполнения сроков SPI = EV / PV показывает, укладывается ли проект в календарь. EVM по задачам Гантта превращает «полосы сместились» в измеримые цифры; отдельной статьи об EVM в Базе Знаний пока нет. Ключевые сигналы контроля расписания — динамика SPI и сжимающийся резерв времени задач критического пути.

Управление изменениями расписания #

Baseline — не музейный экспонат, но и не черновик. Изменение базового плана (re-baselining) допускается только через процедуру управления изменениями: approved change request с анализом причин и последствий. Разница принципиальна:

• Уточнение прогноза (текущие даты плана сдвигаются, baseline остаётся) — нормальная работа с неопределённостью; отклонение фиксируется и разбирается.
• Re-baselining — признание, что исходные обязательства невыполнимы; выполняется редко и явно, иначе baseline теряет смысл, а вместе с ним проект теряет измеримость.

«Тихое» перетаскивание плановых дат под факт — самая распространённая болезнь Гантт-практики: диаграмма всегда зелёная, а проект всегда опаздывает.

Типичные антипаттерны контроля по Гантту:

• «Вечная девяностопятипроцентная» задача — неделями держит один и тот же процент выполнения; лечится декомпозицией на измеримые части.
• Обновление реже раза в две недели — расписание теряет связь с реальностью и превращается в презентацию для встреч.
• Re-baselining «на глазок» после каждого статуса — отклонения исчезают вместе с измеримостью проекта.
• Контроль только вех — вехи «сливаются» незаметно, когда плывут задачи под ними; обязательному контролю подлежат полосы задач критического пути.

Ограничения и критика #

Диаграмме более ста лет, и за это время накопилась систематическая критика. Честное знание границ инструмента — условие его полезного применения.

Не показывает поток работы #

Гантт отвечает на вопрос «когда», но не «как течёт работа». Полосы не показывают очереди, незавершённую работу и узкие места — то, что составляет ежедневную реальность команды. Для непрерывного потока задач (поддержка, operations, сопровождение) адекватны Kanban-доска и кумулятивная диаграмма потока (CFD): они делают видимым накопление работы, которого Гантт в принципе не замечает. Отсюда практическое правило: для continuous flow Гантт не подходит.

«Макароны» при большом числе задач #

Зависимости рисуются стрелками, и уже при 50–100 задачах диаграмма превращается в нечитаемое спагетти из пересекающихся связей. Стандартные противоядия: уровни детализации (сводный Гантт для обзора, детальный — для команды), логические подсети, показ связей только для выбранной задачи. Предел читаемости бумажной/экранной диаграммы — несколько сотен строк; enterprise-расписания на тысячи задач живут в инструментах с фильтрами, а не на одной картинке.

Быстро устаревает #

Расписание — модель будущего, и в среде с меняющимися требованиями (типичная продуктовая разработка) она деградирует быстрее, чем её успевают обновлять: явление называют plan rot. Гантт хорошо живёт там, где состав работ стабилен (стройка, интеграции, регуляторные проекты), и плохо — там, где backlog переприоритизируется каждую неделю. Для продуктовых сред честнее дорожная карта без жёстких дат (Now / Next / Later).

Скрытая ресурсная нереалистичность #

Полоса говорит «задача длится 10 дней», но не говорит, сколько людей и с какой загрузкой на неё нужно. Расписание, безупречное по зависимостям, легко оказывается нереалистичным по людям: три параллельные задачи на одного исполнителя, «сто процентов» загрузки без учёта совещаний, отпусков и контекстных переключений. Инструменты отвечают ресурсными гистограммами и выравниванием (resource levelling), но на самой диаграмме этого не видно — ресурсную реалистичность нужно проверять отдельным представлением.

Ложное ощущение точности — главный минус #

Самая глубокая критика: аккуратные полосы создают впечатление, что будущее известно. Дата «17 ноября» на диаграмме выглядит как факт, хотя на деле это сумма экспертных оценок с большими дисперсиями. Стейкхолдеры (и сами PM) начинают верить картинке, воспринимать прогноз как обязательство и наказывать за «отклонение от плана», которое на самом деле — нормальный разброс оценок. Лекарства: вероятностные оценки сроков (PERT, Монте-Карло — см. «Статистический анализ»), диапазоны вместо дат и явная коммуникация допущений, на которых построено расписание.

Альтернативы и дополнения #

Диаграмма Ганта в Agile и Scrum #

Почему чистый Scrum с Ганттом не дружит #

Scrum сознательно отказывается от детального календарного плана: состав работ спринта фиксируется только на спринт, а долгосрочный прогноз строится эмпирически — через velocity и product backlog. Release Gantt для скрам-команды (полосы задач на месяцы вперёд) противоречит самому принципу эмпирического управления: он фиксирует scope и даты, которые команда честно знать не может. Продуктом планирования в Scrum служат бэклог и release burn-down — график оставшегося объёма работ релиза; отдельной статьи о метриках прогресса проекта в Базе Знаний пока нет.

Когда Гантт полезен в Agile-среде #

Отказ от Гантта внутри команды не означает отказа на уровне координации. Гантт уместен:

• Зависимости между командами — интеграция, общая инфраструктура, последовательность релизов: несколько команд на одном расписании;
• Релизный план для внешних обязательств — маркетинг, продажи, регуляторные сроки нуждаются в календарных вехах, а не в бэклоге;
• Координация с непродуктовыми потоками — найм, закупки, миграции, у которых свои длительные циклы.

Уровень детализации при этом — вехи и эпики, а не задачи: «гибридный» Гантт высотой 20–30 строк. И важно, чего в Agile-Гантте быть не должно: оценённых задач нижнего уровня, привязанных к датам на месяцы вперёд, и еженедельных перетасовок полос — это возвращает waterfall-планирование под видом гибкости.

Гибриды: Scrumban и SAFe #

В гибридных подходах Гантт занимает нишу roadmap-планирования. В Scrumban (см. Kanban) ленточный график дополняет доску для долгосрочных обязательств. В SAFe (Scaled Agile Framework) планирование релизного поезда (PI Planning) включает программную доску, по сути — Гантт эпиков и зависимостей на горизонте планируемого инкремента; roadmap-Гантт — стандартный артефакт уровня программы. Инструментально ниша закрыта Jira Advanced Roadmaps и аналогами (см. следующий раздел).

Итоговое правило: внутри команды — доска и метрики потока; между командами и наружу — Гантт из вех и эпиков.

Инструменты #

Отдельный класс — библиотеки и форматы: проприетарный формат MPP и его открытый XML-вариант Microsoft Project, встраиваемые компоненты для собственных продуктов (dhtmlxGantt, Frappe Gantt), текстовые описания диаграмм в Mermaid. Для документации и статей часто достаточно текстовой схемы; для операционного управления расписанием нужен полноценный движок с пересчётом.

Критерии выбора, в порядке значимости для большинства команд:

1. Качество движка расписания. Пересчитывает ли инструмент даты при изменении зависимости (настоящий CPM-пересчёт), поддерживает ли все четыре типа связей, lead/lag, ограничения и календари. «Рисовалки полос» без пересчёта годятся только для презентаций.
2. Ресурсы и их выравнивание — нужны, если люди — ограниченный ресурс проекта (а они почти всегда ограниченный).
3. Baseline и отклонения — хранение нескольких базовых планов и отображение variance; без этого контроль из раздела выше невозможен.
4. Интеграции — с трекером задач, календарём, документами: расписание, которое живёт отдельно от задач, умирает первым.
5. Цена и порог входа — enterprise-мощность оправдана на проектах с сотнями задач и формальной отчётностью; для команды из десяти человек избыточна.

См. также #

• Критический путь — цепочка задач, определяющая срок проекта; на Гантте подсвечивается в первую очередь.
• Сетевое планирование — CPM и PERT: математическая основа расчёта расписания, которое отображает Гантт.
• Kanban — управление потоком работы: то, что Гантт не показывает в принципе.
• Дорожная карта (Roadmap) — альтернатива датированному Гантту в продуктовой среде (Now / Next / Later).

Заключение #

Диаграмма Ганта — старейший и самый распространённый инструмент визуализации расписания: задачи по строкам, время по столбцам, полосы, вехи и зависимости. Она не «лучший инструмент планирования», а самый понятный для стейкхолдеров — и в этой роли у неё нет замены уже более ста лет.

Практические выводы:

• Реалистичность расписания делают зависимости — четыре типа связей (FS, SS, FF, SF) и осознанные lead/lag, а не аккуратность полос.
• Критический путь на Гантте подсвечивается обязательно — для любого проекта больше ~20 задач это главный управленческий сигнал диаграммы.
• Baseline обязателен: без замороженного базового плана отклонения неизмеримы, а расписание незаметно подстраивается под факт.
• Гантт — не инструмент потока: для continuous flow и работы по запросу нужны Kanban и кумулятивная диаграмма потока; для продуктовой неопределённости — дорожная карта без жёстких дат.
• Главная опасность — ложное ощущение точности: дата на полосе — прогноз, а не обещание; честный Гантт сопровождается вероятностными оценками и диапазонами.

При уважении к границам применимости Гантт остаётся самым эффективным способом ответить на три вопроса любого проекта: что делаем, когда и что от чего зависит.