Самый главный инструмент руководителя проектов — это тайм-план. Его можно строить разными способами, но часто используется диаграмма Гантта.

Про диаграмму Гантта уже было много обсуждений на Хабре:


Кто-то считает, что лучший тайм-план — это диаграмма Гантта, кто-то планирует даже agile-проекты с помощью этой диаграммы, а кто-то, наоборот, не видит в ней смысла и предлагает альтернативные подходы к планированию и тайм-планам.

Давайте всё-таки разберёмся, зачем вообще нужна диаграмма Гантта, как её надо составлять и какая от этого польза!

Что вас ждет в статье

Мануал по составлению диаграммы Гантта на разработку веб-проекта. Мы не будем заострять внимание на конкретном инструменте, обсудим лишь концептуальные и фундаментальные подходы. В основе — двенадцатилетний опыт работы на рынке заказной веб-разработки. За это время я смог запустить более 100 проектов. Последние три года я управляю производством в интерактивном агентстве AGIMA.

На кого рассчитана статья

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

Дисклеймер

Данная статья является не панацеей, а лишь сугубо личным мнением автора (Евгений Лобанов, исполнительный директор AGIMA). Зачастую для планирования проектов эффективен метод критической цепи, но в данной статье мы не будем его касаться и проводить каких-либо сравнительных анализов.

Для чего нужны тайм-планы


Тайм-планы нужны для корректного планирования загрузки и правильного управления ожиданиями бизнес-заказчика.

До того, как запустить любую задачу или проект в производство, у вас должен быть согласованный с командой и бизнес-заказчиком тайминг.

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

Часто используются два тайм-плана — внешний и внутренний:

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

Тайм-планы обычно представляются в виде диаграммы Гантта.

Рассмотрим, какие базовые действия необходимо совершить, чтобы приблизить наш тайм-план к реалистичности, то есть — к идеалу.

Максимально детализировать проект на этапе оценки


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

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

Если же задача оценена более чем в 6-8 часов и не имеет промежуточных результатов для детализации, то необходимо определить критерии для фиксации прогресса.

Установить актуальный производственный календарь, проверить все исключения, установить шестичасовой рабочий день



Многие при построении план-графиков забывают о производственных календарях. Кроме «стандартных» выходных есть «плавающие» из года в год праздники, замещение их рабочими днями и т.д.

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

Как правило, для добавления производственного календаря вам необходимо воспользоваться исключениями в настройке календаря инструмента, при помощи которого вы создаёте диаграмму Гантта.



Создать все необходимые этапы проекта. Все деятельности (задачи) заносятся внутрь этапов


Очень важно сделать корректную группировку для деятельностей в нашем тайм-плане. Если диаграмма простая, то достаточно сгруппировать по этапам проекта, например:

— аналитика,
— проектирование,
— дизайн,
— вёрстка,
— разработка,
— тестирование,
— внедрение.

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

Занести все деятельности на диаграмму


Очевидно, что чем более детализированы бизнес-задачи на конкретные деятельности, тем проще и точнее мы сможем контролировать ход разработки.

Кроме основных деятельностей, не забываем занести:

  • итерации правок согласно договору (если речь о заказной разработке);
  • время на согласование итераций владельцем бизнеса;
  • время на исправления в соответствии с обратной связью и  отладку согласно договору (если речь о заказной разработке);
  • 1-2 часа на неучтённые задачи по каждой деятельности;
  • создание первичного контента;
  • наполнение контентом;
  • тестирование в продакшене;
  • бизнес-тестирование;
  • внедрение.

Составить карту рисков


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

У каждого риска есть два основных параметра относительно проекта:

  1. Вероятность его наступления в окружении проекта.
  2. Степень влияния риска на ход проекта.

Вам предстоит определить оба параметра для каждого риска из перечня. Далее необходимо отфильтровать риски по их реальному воздействию на проект — проще всего это сделать при помощи карты рисков.

Когда все явные риски для проекта определены, необходимо учитывать их минимизацию при построении тайм-плана на диаграмме Гантта.

Я разделяю три основных способа минимизации явных рисков, влияющих на основные временные и бюджетные характеристики проекта:

  • дублирование ресурсов;
  • минимизация функционала относительно стоимости разработки;
  • определение «точек невозврата» относительно деятельностей третьих лиц в виде определения контрольной точки (milestone) на основании календарной даты.

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

Занести все контрольные точки по предоставлению информации от владельца бизнеса или заказчика




Важно не забыть:

  • спецификации;
  • заглушки или рабочие сервисы;
  • брендбук;
  • весь необходимый контент для реализации;
  • закрытие работ актами (если речь о заказной разработке);
  • подписание основных промежуточных документов;
  • предоплата (если речь о заказной разработке);
  • другие формальные обязательства.

Занести все ресурсы (включая время специалистов/сотрудников заказчика)






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

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

Указать критический путь


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

По сути, минимальный путь проекта будет соответствовать вашему внутреннему таймингу. В котором мы уже учли:

  • рабочее время специалистов;
  • явные риски, которые могут произойти, и время, которое требуется на их разрешение;
  • загрузку специалистов с нормальным распределением рабочего времени (без учёта овертаймов).

Что дальше




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

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

Именно такой тайм-план и будет хоть как-то отображать действительно необходимое время на реализацию проекта. Кстати, для расчёта отклонений по срокам на основании прогнозируемых рисков часто можно использовать диаграмму сгорания (Burn Down Chart). О том, по каким параметрам её можно строить, кроме примитивных «сжиганий features», и как собрать статистику об отклонениях — расскажу в следующей статье. Stay tuned…

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


  1. WizardryIB
    19.09.2018 14:59

    Приветствую!
    Лучше осветите возможности Мерлина, которые отсутствуют в продукте от Микрософт.)


    1. otherlight Автор
      19.09.2018 15:42

      Добрый день.
      Задача сложная, но такие возможности действительно есть!)
      Постараемся в одной из следующих статей.


  1. S_A
    19.09.2018 15:55

    Внутренний и внешний план — это так по-столичному… две непересекающихся реальности. Все потому что бюджет заказчику показывают совсем отличный от бюджета по себестоимости. И все потому что есть две ставки, одна для команды продажников, другая из ресурсного офиса. И в центре всего балета — шальная как ЭКГ маржа.


    1. otherlight Автор
      19.09.2018 16:28

      Спасибо за ваш комментарий.
      Ещё раз пожалуйста прочитайте формализацию понятий «внутренний» и «внешний» тайм-планы.
      Если вы можете за все неявные риски на моменте оценки в последствии костить клиента — это отлично. Но в действительности должен ли любой крупный клиент за вас сам закладывать риски в годовой бюджет на разработку?
      И, кстати, «по себестоимости», наверное, это не про бизнес ;)


      1. S_A
        20.09.2018 14:21

        А вы перечитайте комментарий… вообще говоря, честно лень спорить о сортах московского бюджетирования.

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


    1. otherlight Автор
      19.09.2018 16:48

      Кстати, «команды продажников»/отдела продаж в компании AGIMA уже как, минимум, лет 5 — нет.


  1. Soborov
    19.09.2018 16:29

    otherlight, спасибо! Кратко и по существу ) Есть небольшая боль с командами крупных брендов – принципиально не принимают тайминги НЕ в Excel. В итоге делаешь тайминг в Мерлине/ОмниПлане/Прожекте, а аккаунт для клиента всё равно в Excel перерисовывает ;)


    1. otherlight Автор
      19.09.2018 16:30

      Спасибо за позитивную обратную связь.
      Выгружайте план-график в html из Merlin и на хостинг — никакой эксель тогда не нужен, тк таймплан всегда должен быть актуален!


  1. hardmodebitch
    19.09.2018 16:32

    Вы действительно верите, что можно заранее предугадать все сроки всех этапов разработки?


    1. otherlight Автор
      19.09.2018 16:37

      Прошу прощения, но в статье уже содержится ответ на ваш вопрос в предпоследнем абзаце.
      Предугадать все сроки никогда нельзя, но управлять требованиями, рисками, бюджетом и контрольными точками по продукту — вполне. Без предварительного тайм-плана это будет в разы менее эффективно. И чем более реален предварительный план — тем больше шансов на успех.
      Данная практика была проверена на достаточно большом количестве действительно сложных и крупных проектов, но конечно же не может являться панацеей ;)


      1. hardmodebitch
        20.09.2018 10:27

        А зачем, когда есть итеративные системы вроде Scrum?


        1. otherlight Автор
          20.09.2018 11:48

          В целом гибкие методики скорее применимы когда нет точного понимания по конечному продукту и надо проверять бизнес гипотезы и подтверждать их количественными показателями. В других случая — в сравнение с водопадом, например, они будут в разы дороже, а речь всё-таки про коммерческую разработку где часто надо сэкономить бюджет заказчика.
          К тому же, я считаю что есть необходимость и при использовании фреймворков гибких методологий, планировать и прогнозировать каждую итерацию разработки версии продукта для принятия тех или иных управленческих решений.
          Если всё утрировать и обсуждать разработку сложного приложения в вакууме по гибким методологиям, то при наличие дорожной карты по фичам в разрезе версий — диаграммой Гантта, имхо, лучше всего планировать именно итерацию разработки версии. Версия содержит эпики, эпики в свою очередь спринты, спринты несколько стримов. При адекватной и устоявшейся команде разработки почти все риски являются явными на момент планирования итерации версии продукта, что позволяет достаточно точно определить критический путь этой итерации.
          Диаграмма Гантта — это не про то, как точно определить даты дедлайнов. Это про то, как зафиксировать абсолютные контрольные точки по пути решения и далее уже работать с минимизацией рисков и другими параметрами проекта. Ресурсы, бюджеты и даты — всё относительно на Гантте, а вот майлстоуны — абсолютны!


          1. WizardryIB
            20.09.2018 14:13

            И в таких случаях (Ваше первое предложение) в стандарте PRINCE2 предусмотрены предпроекты.