Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

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

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

3 <ul><li>"Удобна ли диаграмма Гантта?"</li>

4 <li>Альтернативные методики "Как оценить срок выполнения работ?"</li>

5 <li>"Планирование Agile проектов с помощью диаграммы Гантта"</li>

6 <li>"О чем молчит диаграмма Гантта или почему проекты всегда опаздывают"</li>

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

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

9 <h2>Что вас ждет в статье</h2>

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

11 <h2>На кого рассчитана статья</h2>

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

13 <h2>Дисклеймер</h2>

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

15 <h2>Для чего нужны тайм-планы</h2>

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

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

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

19 <h4>Часто используются два тайм-плана - внешний и внутренний:</h4>

20 <ul><li>внутренний обсуждается только с командой и включает в себя плановые риски из перечня явных рисков на момент оценки проекта;</li>

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

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

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

24 <h2>Максимально детализировать проект на этапе оценки</h2>

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

26 <p>Поэтому все задачи важно укладывать в рабочий день специалиста (в нашей компании - это 6 часов эффективного времени; более подробно можно почитать в моей статье в разделе "рабочие процессы"). Такие задачи проще всего контролировать и повлиять на них, оставив во временном русле проекта.</p>

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

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

29 <p>Многие при построении план-графиков забывают о производственных календарях. Кроме "стандартных" выходных есть "плавающие" из года в год праздники, замещение их рабочими днями и т.д.</p>

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

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

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

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

34 <ul><li>аналитика,</li>

35 <li>проектирование,</li>

36 <li>дизайн,</li>

37 <li>вёрстка,</li>

38 <li>разработка,</li>

39 <li>тестирование,</li>

40 <li>внедрение.</li>

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

42 <h3>Занести все деятельности на диаграмму</h3>

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

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

45 <ul><li>итерации правок согласно договору (если речь о заказной разработке);</li>

46 <li>время на согласование итераций владельцем бизнеса;</li>

47 <li>время на исправления в соответствии с обратной связью и отладку согласно договору (если речь о заказной разработке);</li>

48 <li>1-2 часа на неучтённые задачи по каждой деятельности;</li>

49 <li>создание первичного контента;</li>

50 <li>наполнение контентом;</li>

51 <li>тестирование в продакшене;</li>

52 <li>бизнес-тестирование;</li>

53 <li>внедрение.</li>

54 </ul><h3>Составить карту рисков</h3>

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

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

57 <ol><li>Вероятность его наступления в окружении проекта.</li>

58 <li>Степень влияния риска на ход проекта.</li>

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

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

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

62 <ul><li>дублирование ресурсов;</li>

63 <li>минимизация функционала относительно стоимости разработки;</li>

64 <li>определение "точек невозврата" относительно деятельностей третьих лиц в виде определения контрольной точки (milestone) на основании календарной даты.</li>

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

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

67 <p>Важно не забыть:</p>

68 <ul><li>спецификации;</li>

69 <li>заглушки или рабочие сервисы;</li>

70 <li>брендбук;</li>

71 <li>весь необходимый контент для реализации;</li>

72 <li>закрытие работ актами (если речь о заказной разработке);</li>

73 <li>подписание основных промежуточных документов;</li>

74 <li>предоплата (если речь о заказной разработке);</li>

75 <li>другие формальные обязательства.</li>

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

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

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

79 <h3>Указать критический путь</h3>

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

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

82 <ul><li>рабочее время специалистов;</li>

83 <li>явные риски, которые могут произойти, и время, которое требуется на их разрешение;</li>

84 <li>загрузку специалистов с нормальным распределением рабочего времени (без учёта овертаймов).</li>

85 </ul><h2>Что дальше</h2>

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

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

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

89 <p><em>Больше материалов смотрите<a>здесь</a>.</em></p>