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

Сразу начнем с понятий: диаграмма Ганта — это тип столбчатых диаграмм, который используется для иллюстрации плана, графика работ по какому-либо проекту. Этот инструмент, помогает планировать проектные задачи, устанавливать сроки и показывать взаимосвязи между этапами. Разработанная Генри Л. Гантом в 1910 году, она до сих пор остается одним из самых популярных методов планирования.
Как построить диаграмму Ганта
Чтобы построить диаграмму, следуйте простым шагам:
Определите цели проекта. Начните с того, чтобы четко понять, что вы хотите достичь. Это поможет правильно распределить задачи и приоритеты.
Разбейте проект на задачи. Подумайте о том, какие шаги нужно сделать, чтобы двигаться вперед и достичь цели.
Установите последовательность задач. Определите, какие задачи должны быть выполнены в первую очередь, а какие можно сделать позже.
Оцените сроки. Оцените, сколько времени каждая задача может занять. Это поможет создать реальный план и избежать неприятных сюрпризов.
Назначьте ответственных. Подумайте, кто из вашей команды будет отвечать за выполнение каждой задачи.
Создайте диаграмму. Для этого можно использовать удобные инструменты, например, Microsoft Project, Jira с плагином Structure, или другие онлайн-сервисы.
Отслеживайте прогресс. Регулярно обновляйте статус задач и при необходимости корректируйте сроки.
Ошибка 1. Диаграмма перегружена деталями
Кажется, чем подробнее расписан проект, тем лучше, но на деле чрезмерная детализация превращает инструмент планирования в неудобный и трудоемкий список задач. В команде тратится больше времени на обновление диаграммы, чем на саму работу.

Признаки того, что эта ошибка у вас есть:
● в диаграмме описаны все задачи до мельчайших подробностей;
● многие пункты дублируют уже утверждённые процессы или регламенты;
● она выглядит перегруженной, и в ней сложно разобраться — даже авторам;
● стейкхолдеры теряются в потоке информации и просто перестают её смотреть.
Итог — инструмент теряет смысл: вроде бы план есть, но никто им не пользуется.
Так бывает, когда мы хотим показать, что всё под контролем — буквально всё, потому что я - хороший менеджер. Бывает мы боимся, что забудем или пропустим важную деталь или не всегда понимаем, для кого мы вообще делаем эту диаграмму.
Что делать вместо этого:
Определитесь с аудиторией. Для команды — подробности можно вести в таск-менеджере (Jira, Trello и т.п.) Для стейкхолдеров — только ключевые этапы: вехи, запуск, согласования.
Ориентируйтесь на ёмкость экрана: Хорошая практика — не более 10–15 задач на одном экране, чтобы уместилось без прокрутки и было легко обсудить.
Сделайте диаграмму визуальным резюме, а не логом всех действий.

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

Как это выглядит:
все задачи размещены на диаграмме отдельно, без стрелочек и связей;
команда не понимает, что блокирует запуск следующего этапа;
сдвигаешь одну задачу — и теряются важные зависимости. Визуально ничего не меняется, а фактически проект может съехать.
Опять же, так бывает, когда не хватило времени или желания разбираться с зависимостями. Надеемся, что команда как-нибудь сама поймёт, кто за кем. Спойлер: не поймет или поймет неправильно. Ну, и просто недооцениваем важность критического пути и логики проекта.
Что делать, чтобы было лучше:
добавляйте связи между задачами: например, "Задача Б начинается только после завершения Задачи А";
выделяйте критический путь: цветом, значками или другой визуальной меткой —чтобы сразу было видно, где риски;
используйте инструменты, которые помогают: например, GanttPRO, Structure — у них есть автоматическое построение зависимостей. Это экономит время и снижает шанс ошибиться.

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

Что происходит:
сроки устарели, но никто не заметил;
задачи давно сделаны, а в диаграмме они всё ещё «в процессе»;
команда перестаёт сверяться с планом, а стейкхолдеры теряют к нему доверие.
Почему возникает такая проблема? Нет человека, который отвечает за актуальность или никто не заложил время на обновление — «и так работы хватает». Бывает, что не хватает инструментов, которые помогают легко синхронизировать статус с реальностью.
Как это исправить:
Введите регулярное обновление: например, каждую пятницу или после завершения крупных этапов. Это может быть короткий ритуал: 15 минут на апдейт диаграммы перед статусом.
Назначьте ответственного за актуальность: это может быть PM или человек, ведущий документацию проекта.
Используйте интеграции с таск-трекером: многие системы подтягивают статус задач автоматически. Это убирает рутину и снижает шанс ошибки.

Ошибка 4. Диаграмма не отвечает на ключевые вопросы стейкхолдеров
Диаграмма занимает три экрана, но стейкхолдер так и не понял, где в ней его фича и когда она появится.
Что происходит:
план отражает внутреннюю кухню команды, но не учитывает бизнес-контекст;
нет информации, как изменения повлияют на сроки или бюджет;
стейкхолдеры не видят, когда появится результат их инициативы или как снизятся риски.
Тут причина может быть в слишком глубоком фокусе на задачах разработки, а не на ценности, слабое взаимодействие с бизнесом или заказчиком, или план делается «для команды» — а потом ими же показывается стейкхолдерам.
Как сделать лучше:
Добавьте в диаграмму вехи, важные для бизнеса: запуск MVP, завершение этапа, маркетинговая активность, внешняя демонстрация.
Разделите план на этапы с ценностью: сначала MVP, потом полноценная версия. Так проще показать, что будет «быстро», а что — «позже, но круто».
Пример:
Показываем такой план: задача - редизайн главной страницы.
Собрать отзывы пользователей о текущей странице.
Придумать новые баннеры и главные блоки.
Обновить шрифты и цвета.
-
Сделать черновой макет новой страницы.
а. Упростить меню и навигацию.
b. Добавить блок с отзывами.
c. Перерисовать кнопки и иконки.
Ускорить загрузку картинок и видео.
Настроить системы для отслеживания.
Вопрос от стейкхолдера: «Как мы минимизируем риски, если пользователям не понравится новый дизайн?»
Что делаем - добавляем в диаграмму вехи:
запуск нового дизайна на часть аудитории;
анализ результатов А/Б-теста;
точка принятия решения о раскатке на всех.
Как мы используем диаграмму Ганта в «Ленте»
В «Ленте» сложно представить, чтобы задача или проект обошелся без планирования. Почти в каждой задаче мы используем диаграмму Ганта — она помогает держать все под контролем.
В этом году перед нашей командой стояла амбициозная задача — создать мобильное приложение для сети магазинов «Монетка». Нужно было перенести ключевой функционал из существующего приложения «Ленты», подгрузить каталог, убрать лишнее и собрать из всего этого удобный, рабочий продукт. Срок — всего 7 месяцев. В проекте участвовали более 140 человек.
Чтобы не утонуть в хаосе и синхронизировать команды, мы построили диаграмму Ганта на базе Jira с использованием плагина Structure. В неё вошли ключевые задачи, этапы и важные зависимости.
Каждую неделю мы собирались на межкомандные встречи, открывали диаграмму и смотрели: Укладываемся ли в ближайшие вехи? Что блокирует продвижение? Можно ли какие-то задачи распараллелить или нужно дождаться окончания предыдущих?
Благодаря связям и зависимостям, диаграмма помогала быстро это понять. Некоторые задачи оказались объёмнее, чем мы предполагали. Но так как мы видели их заранее — могли вовремя подключить дополнительные ресурсы или упростить подход.
Также мы постоянно отслеживали критический путь и, при необходимости, двигали задачи, которые на него не влияли. Это помогло сохранить баланс — проект шёл по графику без переработок и авралов на финише.
В результате приложение было выпущено в срок, и пользователи уже могут оформлять доставку продуктов из магазинов «Монетка».

А мне, как менеджеру одной из команд, диаграмма помогала ещё до созвонов: в любой момент я могла открыть график, увидеть статус задач у коллег и сразу понять, можем ли мы приступать к следующему этапу. Это экономило время и снижало зависимость от ручной коммуникации между командами — просто видим, что задача готова, и берём в работу.
Как выбрать инструмент для построения диаграммы
Для работы с диаграммой Ганта существует множество инструментов: онлайн-сервисы, плагины, отдельные приложения и утилиты для таск-трекеров. Например, во многих современных таск-трекерах есть встроенные плагины для Jira, а также решения от Microsoft.
Выбор подходящего инструмента во многом зависит от корпоративной культуры и доступных ресурсов. Если у вас есть опыт работы с какой-то системой и вы можете быстро в ней разобраться, лучше использовать ее. Если же такого опыта нет, стоит оценить доступные решения по критериям:
какие функции в них есть;
подходят ли они под ваш бюджет;
насколько удобен интерфейс;
поддерживают ли они привычные вам инструменты.
В целом, большинство таких сервисов схожи по функционалу, так что переход с одного на другой не займет много времени.
Заключение
Диаграмма Ганта — популярный и наглядный инструмент. Но он помогает только тогда, когда построен с умом: для конкретной аудитории, с учётом логики, текущего статуса и бизнес-ценности. Избегая типичных ошибок, вы делаете диаграмму не просто красивой, а рабочей. Такой, к которой хочется вернуться, чтобы понять, где мы есть и что будет дальше.
А какие ошибки в работе с диаграммой Ганта встречались вам?
Комментарии (5)
SolidSnack
15.05.2025 07:16Статья интересная, диаграммы и показатели круто. Но если честно у меня глаз зацепился за 140+ человек участвующих в работе над продуктом, диаграммами можно все покрыть и посмотреть, но точно ли нужно столько людей?
ogudinaan Автор
15.05.2025 07:16Хороший вопрос! Давайте уточню: это не 140 человек, работающих full-time 7 месяцев. У большинства из них параллельно были другие задачи — поддержка, развитие текущих направлений, техдолг. Кто-то был вовлечён глубоко и постоянно, а кто-то подключался точечно, когда требовалась его экспертиза. Когда мы подвели итоги, оказалось, что к проекту приложили руку более 140 специалистов — и каждый внёс свой вклад.
SolidSnack
15.05.2025 07:16Да, я понимаю как это происходит в коммерческой разработке. Я больше про то что, впринципе 140+ человек для такого приложения это перебор 2 раза :) Это скорее про корпоративные моменты, и как видно из статьи диаграммы не помогают сократить количество участников процесса. Я к тому что 2 программиста не сделают приложение в 2 раза быстрее, а скорее наоборот все усложнят.
HabraReaderZH
Спасибо за статью. Зачастую самые банальные и очевидные вещи оказываются сложно понимаемые для руководства. Все хотят иметь детализированный план проекта с количеством задач 150+. А потом в этих проектах разобраться не могу и требуют отчётность и статус в одно предложение.)) Просьба в следующей статье разобрать такое тонкое место проектного управления как выравнивание загрузки ресурсов.
ogudinaan Автор
Благодарю за отзыв и идею для следующего поста!