План проекта часто начинают с таблицы, диаграммы Ганта или списка задач. Это удобный способ быстро получить картинку, но не всегда — хороший способ получить работающий план. Если даты поставлены вручную, зависимости не определены, а доступность людей не учтена, такой график показывает ожидания, а не реальную последовательность проекта.
Практический порядок другой: сначала определить результат и границы проекта, затем построить структуру работ, связать этапы зависимостями, назначить ограниченные ресурсы и только после этого рассчитывать даты. Ниже разберём этот процесс на простом примере.
Начните не с дат, а с результата
До календарного планирования сформулируйте, что должно существовать после завершения проекта. Результат должен быть достаточно конкретным, чтобы по нему можно было определить окончание проекта.
Например, формулировка «сделать новый сайт» слишком широкая. Для планирования полезнее:
Одновременно зафиксируйте границы. Если в проект не входит переработка фирменного стиля, написание всех текстов или интеграция с CRM, это лучше обозначить сразу. Иначе объём будет увеличиваться уже после того, как сроки рассчитаны.
На этом этапе полезно ответить на четыре вопроса:
- Что именно должно быть получено в конце?
- По каким признакам мы поймём, что результат готов?
- Что входит в проект?
- Что сознательно остаётся за его пределами?
Пока на эти вопросы нет ответа, точная дата окончания проекта создаёт больше иллюзии определённости, чем пользы.
Разбейте результат на крупные этапы
Следующий шаг — декомпозиция. Для календарного плана не обязательно переносить в него каждое действие команды. План проекта и ежедневный список задач решают разные задачи.
На верхнем уровне достаточно этапов, которые:
- имеют понятный результат;
- можно оценить по длительности или трудоёмкости;
- имеют владельца или основной ресурс;
- влияют на последовательность следующих работ.
Для нашего примера структура может выглядеть так:
| Этап | Оценка | Основной ресурс |
|---|---|---|
| Требования и структура | 5 рабочих дней | Руководитель проекта |
| Прототипирование | 4 рабочих дня | Дизайнер |
| Дизайн | 7 рабочих дней | Дизайнер |
| Разработка | 10 рабочих дней | Разработчик |
| Наполнение | 5 рабочих дней | Контент-менеджер |
| Тестирование | 4 рабочих дня | Тестировщик |
| Запуск | 1 рабочий день | Руководитель проекта |
Это ещё не календарный план. Пока мы знаем состав работ, но не знаем, какие из них можно выполнять параллельно и какие должны ждать завершения предыдущих.
Добавьте зависимости
Теперь для каждого этапа задайте вопрос: что обязательно должно произойти до его начала?
Например:
| Этап | Предшественник |
|---|---|
| Требования и структура | — |
| Прототипирование | Требования и структура |
| Дизайн | Прототипирование |
| Разработка | Дизайн |
| Наполнение | Разработка основных шаблонов |
| Тестирование | Разработка и наполнение |
| Запуск | Тестирование |
Зависимости принципиально отличаются от вручную указанных дат. Если дизайн задержался на три дня, зависимая разработка должна автоматически сдвинуться. Если этого не происходит, план приходится поддерживать вручную, а его актуальность быстро теряется.
При этом не нужно связывать всё со всем. Фиксируйте только реальные ограничения последовательности. Например, подготовку текстов можно начать до окончания разработки, если для неё уже известны структура и требования.
Назначьте ограниченные ресурсы
После построения логики работ появляется второй источник ограничений — люди. Именно здесь многие планы, которые хорошо выглядят на диаграмме, перестают быть выполнимыми.
Предположим, дизайнер должен выполнить семь дней работы по проекту. Формально можно поставить этот этап сразу после прототипа. Но если тот же дизайнер следующие четыре дня занят в другом проекте, новая работа физически не может начаться в рассчитанную дату.
Поэтому для ключевых этапов желательно назначать не только абстрактную роль вроде «дизайнер» или «аналитик», а конкретный ограниченный ресурс либо явно определённую доступную ёмкость команды.
Если один специалист участвует в трёх проектах, планирование должно учитывать суммарный спрос на его время. Иначе конфликт проявится не на этапе планирования, а уже в работе — обычно в виде задержки одного из проектов.
Подробнее эту механику мы разобрали в материале о ресурсном планировании проекта.
Примените рабочие календари
После зависимостей и ресурсов можно переходить к календарю. Здесь важно различать календарную продолжительность и рабочее время.
Пять рабочих дней, начавшиеся в четверг, не заканчиваются в понедельник. Между ними есть выходные. Аналогично на дату влияют праздники, отпуска, индивидуальный график сотрудника и периоды его недоступности.
Например, разработка требует десяти рабочих дней и должна стартовать 14 сентября. Если разработчик работает по стандартной пятидневной неделе, окончание будет рассчитываться по рабочему календарю, а не простым прибавлением десяти календарных дней.
Если внутри этого периода сотрудник два дня отсутствует, окончание сдвигается ещё дальше.
структура работ → зависимости → доступность ресурса → рабочий календарь → дата.
Именно такой порядок позволяет объяснить, откуда появилась дата окончания, а затем корректно пересчитать её при изменении исходных условий.
Подробнее: как построить календарный план проекта.
Если проект содержит несколько зависимых веток, отдельно проверьте, какие работы непосредственно определяют конечную дату. Подробнее об этом — в материале о критическом пути проекта.
Проверьте реалистичность
Первый рассчитанный график редко должен сразу становиться утверждённым планом. Сначала его стоит проверить на ограничения и чувствительность.
Минимальная проверка включает:
- нет ли одного сотрудника одновременно на нескольких работах;
- не назначены ли работы на период отсутствия исполнителя;
- есть ли этапы, задержка которых сдвигает весь проект;
- не построены ли даты на слишком оптимистичных оценках;
- какие работы можно выполнять параллельно;
- что произойдёт, если ключевой этап задержится.
Допустим, первоначальный расчёт показывает запуск сайта 20 октября. После учёта отпуска дизайнера дата становится 26 октября. Это не означает, что план «стал хуже». Наоборот, он стал точнее: ограничение существовало и раньше, просто теперь оно стало видимым до начала работ.
После этого руководитель может выбрать управленческое действие: поменять приоритет другого проекта, заменить ресурс, уменьшить объём первой версии или принять новую дату.
Планировщик не должен принимать такое решение вместо руководителя. Его задача — показать последствия каждого варианта.
Поддерживайте план через сценарии
Проектный план устаревает не потому, что был плохо составлен, а потому что меняется реальность. Появляется новый проект, сотрудник уходит в отпуск, оценка этапа увеличивается, меняется приоритет.
Поэтому полезно отделять текущий согласованный план от сценария будущих изменений.
Например:
- есть опубликованный план с датой запуска 26 октября;
- разработчик сообщает, что этап займёт не 10, а 14 рабочих дней;
- система рассчитывает новый сценарий;
- руководитель видит новую дату и влияние на остальные проекты;
- только после принятия решения новая версия становится рабочим планом.
Так изменение срока остаётся объяснимым. Можно ответить не только «дата стала другой», но и «дата изменилась на четыре рабочих дня из-за новой оценки этапа разработки».
Короткий чек-лист хорошего плана проекта
- понятен конечный результат проекта;
- зафиксированы границы;
- есть крупные планируемые этапы;
- между этапами определены реальные зависимости;
- назначены ограниченные ресурсы;
- учтены рабочие календари и отсутствия;
- даты рассчитываются из модели, а не вводятся произвольно;
- план проверен на перегрузки;
- изменения сначала моделируются как сценарий.
Что делать дальше
Если проект пока ведётся в таблице, не обязательно сразу переносить в систему сотни мелких задач. Для начала достаточно взять один реальный проект: определить 5–15 крупных этапов, связать их зависимостями, назначить ключевых сотрудников и посмотреть, какую дату даст расчёт.
Если результат заметно отличается от даты в текущем плане, полезно разобраться почему. Обычно причина обнаруживается в зависимостях, рабочих календарях или конкуренции нескольких проектов за одного специалиста.
КОРДО предназначен именно для календарного и ресурсного планирования проектов и портфелей. Он не требует заменять существующий таск-трекер команды.