4 типовые ошибки при работе с диаграммой Ганта

Если вы айтишный руководитель проектов, вам в любом случае придётся составлять диаграммы Ганта. Даже если вы работаете по скраму. Возможно, даже если вы работаете по канбану. Как минимум, для того, чтобы прикинуть дату для ответа на вопрос заказчика: «А когда всё это кончится?», который вам обязательно зададут.

Не буду останавливаться на том, как её составить, статья о другом. Поговорим о четырёх типовых ошибках, которые вы можете допустить при составлении этой диаграммы и работе с ней.

Диаграмма перегружена деталями

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

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

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

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

На диаграмме нет зависимостей между задачами

У вас может возникнуть соблазн не делать зависимостей, а просто накидать колбаски задач одну за другой на схему. Получится приемлемо, но первом же апдейте схема станет неактуальной.

Отображение и учёт зависимостей между задачами — одна из базовых целей составления диаграммы Ганта. Схема должна уметь обрабатывать сдвиг задач, особенно на критическом пути и строить расписание, исходя из зависимостей. Если задача Б должна стартовать никак не раньше завершения задачи А, старт задачи Б всегда должен сдвигаться вместе с просрочкой задачи А.

Отсутствием связей страдают диаграммы Ганта, составленные в экселе, а не в специализированной программе. И это плохо.

Диаграмма не обновляется

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

В Merlin Project я актуализировал схему так. Проходился по задачам, вбивал фактические трудозатраты по задачам и апдейтил оценки. Если какие-то задачи сдвигались, тут же продлял дату завершения. А так как я всегда выставлял зависимости, схема апдейтилась корректно. Кстати, если это делать, можно включать режим диаграммы, в котором статус просрочки будет подсвечиваться цветами, что очень удобно для оценки отставаний по проекту, много ли там красноты.

Но есть намного лучший подход. Использовать джира-плагины, structure или big picture. В них диаграмма Ганта строится на основании существующих задач и статус по ним апдейтится в реальном времени. Разраб закрыл задачу — это отобразилось на схеме. Очень комфортно.

Диаграмма не отвечает на главные вопросы заказчиков и стейкхолдеров

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

Разместите на диаграмме ключевые вехи, интересные заказчику. Даты демо и сдач этапов продукта, маркетинговые активности.

Мужчина турист с картой.

Опубликовано

в

от

Подпишитесь на новые посты, чтобы не пропускать их (РКН о сборе имейлов уведомлён должным образом):

Добавить комментарий

Предыдущий пост
Статья объясняет, зачем руководителю проектов программирование. Оно улучшает понимание процессов,…