Попробовать бесплатно
Каскадная модель (Waterfall)планированиесредний уровень

Календарный план: зависимости, критический путь и резервы

Календарный план — не список дат, а сеть зависимостей. Пока не построены связи «что после чего», непонятно, какие работы определяют общий срок, а какие можно сдвинуть безболезненно. Разбираем, как строить план, находить критический путь и куда закладывать резерв.

16 мин чтенияобновлено

Сначала работы, потом даты

План начинается с разбиения результата на пакеты работ, и только потом появляется календарь. Пакет — это то, что можно оценить и поручить одному ответственному; ориентир по размеру — от нескольких дней до двух недель.

Слишком крупный пакет невозможно контролировать: он неделями находится «в работе на 60%», и понять, отстаёт ли он, нельзя. Слишком мелкий на старте бессмысленен: детали дальних работ всё равно изменятся, а план превратится в тысячу строк, которые никто не поддерживает.

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

Проверьте разбиение на полноту: пакеты нижнего уровня должны покрывать результат целиком, без строки «и прочие работы». Забытая работа в договоре с фиксированной ценой оплачивается из вашей маржи, и обнаруживается она обычно на приёмке. Полезно завести короткое описание к каждому пакету — что входит в результат, кто принимает, чем подтверждается готовность.

План для договора и план для работы — разные планы

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

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

Правило простое: в договор попадает то, за что вы готовы отвечать датами и деньгами, всё остальное живёт в рабочем плане. Связь односторонняя: рабочий план обязан обеспечивать договорные вехи, и обратной зависимости здесь нет.

Критический путь: где живёт срок проекта

Критический путь — самая длинная по суммарной длительности последовательность связанных работ; её длина и есть расчётный срок проекта при неограниченных ресурсах. Сдвиг любой работы на этом пути сдвигает окончание: собственного запаса у таких работ нет. Если срок задан директивно и он короче расчётного, запас критического пути отрицательный — это повод признать разрыв вслух; подгонять даты в плане бессмысленно.

Запас у остальных работ бывает двух видов, и путать их дорого. Общий резерв — на сколько работу можно сдвинуть, не сдвигая окончание проекта; он принадлежит всей ветке целиком: израсходовав его на первой работе, вы обнуляете его для всех последующих. Свободный резерв — на сколько можно сдвинуть, не трогая начало следующей работы; только он расходуется действительно без последствий для соседей. Планируя сдвиг, смотрите на свободный резерв; отслеживая риск срыва — на общий.

Практический вывод: контроль должен быть неравномерным. Ежедневное внимание — работам на критическом пути; остальным достаточно следить за остатком запаса. Обратная ситуация — равномерное внимание ко всему — приводит к тому, что мелкая задержка критической работы теряется в общем шуме.

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

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

Ресурсы: план без загрузки людей ничего не показывает

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

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

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

Резервы: отдельная строка вместо запаса в оценках

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

Рабочий приём — попросить оценку без страховки, а резерв вынести отдельной строкой в конце цепочки. Условие, без которого приём не работает: такая оценка перестаёт быть личным обязательством исполнителя. Если срыв оценки без запаса разбирают как срыв срока, через две недели запас вернётся в оценки — только теперь скрытно и с бо́льшим коэффициентом. Резервом распоряжается руководитель проекта.

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

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

Вехи: контрольная точка с проверяемым результатом

Веха — не «середина этапа» и не «прошло два месяца». Это точка, в которой есть проверяемый результат: подписан документ, принята подсистема, получено заключение. Веха без критерия проверки не контролирует ничего.

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

У вехи нет длительности: она либо достигнута, либо нет. Формулировка «веха выполнена на 70%» означает, что результат сформулирован нечётко и по нему нельзя принять решение.

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

Типы зависимостей и что с ними делать

ТИППРИМЕРКАК ИСПОЛЬЗОВАТЬ ПРИ СЖАТИИ СРОКА
ОбязательнаяПроектирование до реализацииНе снимается: только сокращение самих работ
ОрганизационнаяИванов делает сначала A, потом BСамый дешёвый выигрыш: перераспределить людей
ВнешняяСогласование у заказчика, поставка оборудованияЗапускать раньше, дублировать поставщиков, эскалировать
С задержкойПосле заливки — выдержка 7 днейНе сжимается, но можно параллелить соседние работы

Чек-лист качества плана

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

Отмечено 0 из 9

Как построить план в Shtab

Веха в Shtab — задача нулевой длительности: на шкале Ганта видно, какая работа её сдвигает.

  • Задачи с датами и зависимостями строятся на диаграмме Ганта: связь между работами задаёт их порядок, и сдвиг одной подтягивает остальные.
  • Пакет работ — задача с подзадачами; ответственный назначается на пакет целиком.
  • Вехи удобно вести отдельным типом задачи нулевой длительности с критерием в описании.
  • Оценка трудозатрат и трекер времени дают план-факт по каждому пакету.
  • Резерв заводите отдельной задачей в конце цепочки — тогда его расход виден на той же шкале.
  • Календарь и списки дают тот же план в другом виде: по датам и по ответственным.

Частые вопросы

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

Соберите свой процесс в Shtab

Доски и статусы, оценка трудозатрат, дерево целей, отчёты и трекер времени — в одном инструменте.