Привет, Habr!

Я – Анастасия Огудина, менеджер проектов онлайн-сервиса в «Лента Онлайн». В своей работе я часто использую диаграмму Ганта, и за годы практики заметила, какие ошибки в ее использовании могут сильно усложнить жизнь команде. В этой статье расскажу о четырех распространенных проблемах при работе с диаграммой и о том, как их избежать.

Сразу начнем с понятий: диаграмма Ганта — это тип столбчатых диаграмм, который используется для иллюстрации плана, графика работ по какому-либо проекту. Этот инструмент, помогает планировать проектные задачи, устанавливать сроки и показывать взаимосвязи между этапами. Разработанная Генри Л. Гантом в 1910 году, она до сих пор остается одним из самых популярных методов планирования.

Как построить диаграмму Ганта

Чтобы построить диаграмму, следуйте простым шагам:

  1. Определите цели проекта. Начните с того, чтобы четко понять, что вы хотите достичь. Это поможет правильно распределить задачи и приоритеты.

  2. Разбейте проект на задачи. Подумайте о том, какие шаги нужно сделать, чтобы двигаться вперед и достичь цели.

  3. Установите последовательность задач. Определите, какие задачи должны быть выполнены в первую очередь, а какие можно сделать позже.

  4. Оцените сроки. Оцените, сколько времени каждая задача может занять. Это поможет создать реальный план и избежать неприятных сюрпризов.

  5. Назначьте ответственных. Подумайте, кто из вашей команды будет отвечать за выполнение каждой задачи.

  6. Создайте диаграмму. Для этого можно использовать удобные инструменты, например, Microsoft Project, Jira с плагином Structure, или другие онлайн-сервисы.

  7. Отслеживайте прогресс. Регулярно обновляйте статус задач и при необходимости корректируйте сроки.

Ошибка 1. Диаграмма перегружена деталями

Кажется, чем подробнее расписан проект, тем лучше, но на деле чрезмерная детализация превращает инструмент планирования в неудобный и трудоемкий список задач. В команде тратится больше времени на обновление диаграммы, чем на саму работу.

Рисунок 1. Так не надо
Рисунок 1. Так не надо

Признаки того, что эта ошибка у вас есть:

●      в диаграмме описаны все задачи до мельчайших подробностей;

●      многие пункты дублируют уже утверждённые процессы или регламенты;

●      она выглядит перегруженной, и в ней сложно разобраться — даже авторам;

●      стейкхолдеры теряются в потоке информации и просто перестают её смотреть.

Итог — инструмент теряет смысл: вроде бы план есть, но никто им не пользуется.

Так бывает, когда мы хотим показать, что всё под контролем — буквально всё, потому что я - хороший менеджер. Бывает мы боимся, что забудем или пропустим важную деталь или не всегда понимаем, для кого мы вообще делаем эту диаграмму.

Что делать вместо этого:

  1. Определитесь с аудиторией. Для команды — подробности можно вести в таск-менеджере (Jira, Trello и т.п.) Для стейкхолдеров — только ключевые этапы: вехи, запуск, согласования.

  2. Ориентируйтесь на ёмкость экрана: Хорошая практика — не более 10–15 задач на одном экране, чтобы уместилось без прокрутки и было легко обсудить.

  3. Сделайте диаграмму визуальным резюме, а не логом всех действий.

Рисунок 2. Так лучше
Рисунок 2. Так лучше

Ошибка 2. Нет зависимостей между задачами

Диаграмма Ганта – инструмент, который показывает, как задачи связаны между собой. Если зависимость не учтена, может случиться так, что одна команда ждет завершения работы другой, но в графике этого не видно. В итоге сроки нарушаются, задачи пересекаются или оказываются в неправильном порядке.

Рисунок 3. Нет зависимостей, непонятна последовательность
Рисунок 3. Нет зависимостей, непонятна последовательность

Как это выглядит:

  • все задачи размещены на диаграмме отдельно, без стрелочек и связей;

  • команда не понимает, что блокирует запуск следующего этапа;

  • сдвигаешь одну задачу — и теряются важные зависимости. Визуально ничего не меняется, а фактически проект может съехать.

Опять же, так бывает, когда не хватило времени или желания разбираться с зависимостями. Надеемся, что команда как-нибудь сама поймёт, кто за кем. Спойлер: не поймет или поймет неправильно. Ну, и просто недооцениваем важность критического пути и логики проекта.

Что делать, чтобы было лучше:

  • добавляйте связи между задачами: например, "Задача Б начинается только после завершения Задачи А";

  • выделяйте критический путь: цветом, значками или другой визуальной меткой —чтобы сразу было видно, где риски;

  • используйте инструменты, которые помогают: например, GanttPRO, Structure — у них есть автоматическое построение зависимостей. Это экономит время и снижает шанс ошибиться.

Рисунок 4. Сразу видны зависимости
Рисунок 4. Сразу видны зависимости

Ошибка 3. Диаграмма статична и не обновляется

Проектные задачи постоянно меняются, сроки сдвигаются, но если этого не видно в диаграмме, она перестает отражать реальное состояние проекта и становится не полезной.

Рисунок 5. Непонятно, в каком статусе задачи в данный момент
Рисунок 5. Непонятно, в каком статусе задачи в данный момент

Что происходит:

  • сроки устарели, но никто не заметил;

  • задачи давно сделаны, а в диаграмме они всё ещё «в процессе»;

  • команда перестаёт сверяться с планом, а стейкхолдеры теряют к нему доверие.

Почему возникает такая проблема? Нет человека, который отвечает за актуальность или никто не заложил время на обновление — «и так работы хватает». Бывает, что не хватает инструментов, которые помогают легко синхронизировать статус с реальностью.

Как это исправить:

  1. Введите регулярное обновление: например, каждую пятницу или после завершения крупных этапов. Это может быть короткий ритуал: 15 минут на апдейт диаграммы перед статусом.

  2. Назначьте ответственного за актуальность: это может быть PM или человек, ведущий документацию проекта.

  3. Используйте интеграции с таск-трекером: многие системы подтягивают статус задач автоматически. Это убирает рутину и снижает шанс ошибки.

Рисунок 6. Диаграмма отражает актуальный статус
Рисунок 6. Диаграмма отражает актуальный статус

Ошибка 4. Диаграмма не отвечает на ключевые вопросы стейкхолдеров

Диаграмма занимает три экрана, но стейкхолдер так и не понял, где в ней его фича и когда она появится.

Что происходит:

  • план отражает внутреннюю кухню команды, но не учитывает бизнес-контекст;

  • нет информации, как изменения повлияют на сроки или бюджет;

  • стейкхолдеры не видят, когда появится результат их инициативы или как снизятся риски.

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

Как сделать лучше:

  1. Добавьте в диаграмму вехи, важные для бизнеса: запуск MVP, завершение этапа, маркетинговая активность, внешняя демонстрация.

  2. Разделите план на этапы с ценностью: сначала MVP, потом полноценная версия. Так проще показать, что будет «быстро», а что — «позже, но круто».

Пример:

Показываем такой план: задача - редизайн главной страницы.

  1. Собрать отзывы пользователей о текущей странице.

  2. Придумать новые баннеры и главные блоки.

  3. Обновить шрифты и цвета.

  4. Сделать черновой макет новой страницы.

    а. Упростить меню и навигацию.

    b. Добавить блок с отзывами.

    c. Перерисовать кнопки и иконки.

  5. Ускорить загрузку картинок и видео.

  6. Настроить системы для отслеживания.

Вопрос от стейкхолдера: «Как мы минимизируем риски, если пользователям не понравится новый дизайн?»

Что делаем - добавляем в диаграмму вехи:

  • запуск нового дизайна на часть аудитории;

  • анализ результатов А/Б-теста;

  • точка принятия решения о раскатке на всех.

Как мы используем диаграмму Ганта в «Ленте»

В «Ленте» сложно представить, чтобы задача или проект обошелся без планирования. Почти в каждой задаче мы используем диаграмму Ганта — она помогает держать все под контролем.

В этом году перед нашей командой стояла амбициозная задача — создать мобильное приложение для сети магазинов «Монетка». Нужно было перенести ключевой функционал из существующего приложения «Ленты», подгрузить каталог, убрать лишнее и собрать из всего этого удобный, рабочий продукт. Срок — всего 7 месяцев. В проекте участвовали более 140 человек.

Чтобы не утонуть в хаосе и синхронизировать команды, мы построили диаграмму Ганта на базе Jira с использованием плагина Structure. В неё вошли ключевые задачи, этапы и важные зависимости.

Каждую неделю мы собирались на межкомандные встречи, открывали диаграмму и смотрели: Укладываемся ли в ближайшие вехи? Что блокирует продвижение? Можно ли какие-то задачи распараллелить или нужно дождаться окончания предыдущих?

Благодаря связям и зависимостям, диаграмма помогала быстро это понять. Некоторые задачи оказались объёмнее, чем мы предполагали. Но так как мы видели их заранее — могли вовремя подключить дополнительные ресурсы или упростить подход.

Также мы постоянно отслеживали критический путь и, при необходимости, двигали задачи, которые на него не влияли. Это помогло сохранить баланс — проект шёл по графику без переработок и авралов на финише.

В результате приложение было выпущено в срок, и пользователи уже могут оформлять доставку продуктов из магазинов «Монетка».

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

Как выбрать инструмент для построения диаграммы

Для работы с диаграммой Ганта существует множество инструментов: онлайн-сервисы, плагины, отдельные приложения и утилиты для таск-трекеров. Например, во многих современных таск-трекерах есть встроенные плагины для Jira, а также решения от Microsoft.

Выбор подходящего инструмента во многом зависит от корпоративной культуры и доступных ресурсов. Если у вас есть опыт работы с какой-то системой и вы можете быстро в ней разобраться, лучше использовать ее. Если же такого опыта нет, стоит оценить доступные решения по критериям:

  • какие функции в них есть;

  • подходят ли они под ваш бюджет;

  • насколько удобен интерфейс;

  • поддерживают ли они привычные вам инструменты.

В целом, большинство таких сервисов схожи по функционалу, так что переход с одного на другой не займет много времени.

Заключение

Диаграмма Ганта — популярный и наглядный инструмент. Но он помогает только тогда, когда построен с умом: для конкретной аудитории, с учётом логики, текущего статуса и бизнес-ценности. Избегая типичных ошибок, вы делаете диаграмму не просто красивой, а рабочей. Такой, к которой хочется вернуться, чтобы понять, где мы есть и что будет дальше.

А какие ошибки в работе с диаграммой Ганта встречались вам?

Комментарии (5)


  1. HabraReaderZH
    15.05.2025 07:16

    Спасибо за статью. Зачастую самые банальные и очевидные вещи оказываются сложно понимаемые для руководства. Все хотят иметь детализированный план проекта с количеством задач 150+. А потом в этих проектах разобраться не могу и требуют отчётность и статус в одно предложение.)) Просьба в следующей статье разобрать такое тонкое место проектного управления как выравнивание загрузки ресурсов.


    1. ogudinaan Автор
      15.05.2025 07:16

      Благодарю за отзыв и идею для следующего поста!


  1. SolidSnack
    15.05.2025 07:16

    Статья интересная, диаграммы и показатели круто. Но если честно у меня глаз зацепился за 140+ человек участвующих в работе над продуктом, диаграммами можно все покрыть и посмотреть, но точно ли нужно столько людей?


    1. ogudinaan Автор
      15.05.2025 07:16

      Хороший вопрос! Давайте уточню: это не 140 человек, работающих full-time 7 месяцев. У большинства из них параллельно были другие задачи — поддержка, развитие текущих направлений, техдолг. Кто-то был вовлечён глубоко и постоянно, а кто-то подключался точечно, когда требовалась его экспертиза. Когда мы подвели итоги, оказалось, что к проекту приложили руку более 140 специалистов — и каждый внёс свой вклад.


      1. SolidSnack
        15.05.2025 07:16

        Да, я понимаю как это происходит в коммерческой разработке. Я больше про то что, впринципе 140+ человек для такого приложения это перебор 2 раза :) Это скорее про корпоративные моменты, и как видно из статьи диаграммы не помогают сократить количество участников процесса. Я к тому что 2 программиста не сделают приложение в 2 раза быстрее, а скорее наоборот все усложнят.