В проекте может быть десятки или сотни работ, но не каждая из них одинаково влияет на конечный срок. Одну задачу можно задержать на два дня, не изменив дату проекта. Другая задержка даже на один рабочий день сразу передвинет весь последующий график.
Критический путь помогает отличить эти ситуации. Он показывает последовательность работ с нулевым временным резервом в классической сетевой модели проекта.
Разберём смысл критического пути, построим небольшой проект, выполним прямой и обратный проход и посмотрим, где появляется резерв времени.
Главная идея критического пути
Предположим, проект состоит из нескольких связанных работ. Некоторые выполняются последовательно, другие можно делать параллельно.
Если одна параллельная ветка закончится раньше остальных, у её работ может появиться запас времени. Их небольшая задержка не обязательно повлияет на дату всего проекта.
Но существует как минимум одна последовательность, которая определяет минимально возможную длительность проекта при текущих зависимостях и длительностях.
Это и есть критический путь.
Чтобы увидеть это на практике, возьмём условный проект запуска новой версии сервиса.
| Код | Работа | Длительность | Предшественник |
|---|---|---|---|
| A | Уточнение требований | 3 дня | — |
| B | Архитектура | 4 дня | A |
| C | Дизайн | 5 дней | A |
| D | Backend-разработка | 6 дней | B |
| E | Frontend-разработка | 5 дней | B, C |
| F | Интеграция и тестирование | 4 дня | D, E |
| H | Настройка аналитики | 3 дня | A |
| G | Запуск | 1 день | F, H |
Для простоты будем считать длительности в условных рабочих днях от начала проекта и пока не учитывать выходные, отпуска и ограничения ресурсов. Это классическая модель CPM — Critical Path Method.
Почему самая длинная задача не обязательно критическая
Сначала посмотрим на распространённую ошибку: считать критической самую длинную работу.
В нашем примере самая длинная отдельная работа — backend-разработка, 6 дней. Но критический путь определяется не длиной одной задачи, а всей сетью зависимостей.
Например, настройка аналитики длится всего 3 дня и начинается после требований. После неё до запуска остаётся большой запас времени, пока команда заканчивает разработку и тестирование.
Поэтому важны не только длительности, но и положение работы в графике.
Посмотрим на несколько возможных веток:
| Последовательность | Суммарная длительность |
|---|---|
| A → B → D → F → G | 3 + 4 + 6 + 4 + 1 = 18 дней |
| A → C → E → F → G | 3 + 5 + 5 + 4 + 1 = 18 дней |
| A → H → G | 3 + 3 + 1 = 7 дней |
Но простого сложения веток недостаточно во всех сетях. Например, работа E имеет сразу два предшественника — B и C. Она сможет начаться только тогда, когда выполнены оба условия.
Поэтому критический путь корректнее определять расчётом ранних и поздних дат.
Как найти критический путь вручную
Классический расчёт состоит из двух проходов по сети:
- прямой проход — определяем самые ранние возможные даты;
- обратный проход — определяем самые поздние допустимые даты без изменения срока проекта.
Шаг 1. Прямой проход
Начало проекта принимаем за день 0.
Для каждой работы рассчитываем:
- ES — Early Start: самый ранний старт;
- EF — Early Finish: самое раннее окончание.
Упрощённо:
Если у работы несколько предшественников, её ES равен максимальному EF этих предшественников.
| Работа | Длительность | ES | EF |
|---|---|---|---|
| A | 3 | 0 | 3 |
| B | 4 | 3 | 7 |
| C | 5 | 3 | 8 |
| D | 6 | 7 | 13 |
| E | 5 | 8 | 13 |
| F | 4 | 13 | 17 |
| H | 3 | 3 | 6 |
| G | 1 | 17 | 18 |
Обратите внимание на работу E. Архитектура B заканчивается в день 7, дизайн C — в день 8. Поскольку E требует завершения обеих работ, она может стартовать только в день 8.
Аналогично G ждёт и F, и H. Аналитика H готова уже в день 6, но интеграция F заканчивается только в день 17. Поэтому запуск начинается в день 17.
По прямому проходу минимальная продолжительность этого проекта составляет 18 рабочих дней.
Шаг 2. Обратный проход
Теперь идём от конца проекта к началу и вычисляем:
- LF — Late Finish: самое позднее допустимое окончание;
- LS — Late Start: самый поздний допустимый старт без сдвига проекта.
Для последней работы G позднее окончание равно дню 18.
Далее:
Если у работы несколько последователей, её LF определяется самым ранним LS среди этих последователей.
| Работа | ES | EF | LS | LF | Резерв |
|---|---|---|---|---|---|
| A | 0 | 3 | 0 | 3 | 0 |
| B | 3 | 7 | 3 | 7 | 0 |
| C | 3 | 8 | 3 | 8 | 0 |
| D | 7 | 13 | 7 | 13 | 0 |
| E | 8 | 13 | 8 | 13 | 0 |
| F | 13 | 17 | 13 | 17 | 0 |
| H | 3 | 6 | 14 | 17 | 11 |
| G | 17 | 18 | 17 | 18 | 0 |
Резерв можно получить как:
или эквивалентно
LF − EF.
У работы H резерв составляет 11 дней. Это означает, что при текущей модели её можно начать значительно позже, не меняя дату запуска проекта.
У остальных работ резерв равен нулю.
Что меняют ограниченные ресурсы
Классический CPM отвечает на важный вопрос, но делает сильное допущение: нужные ресурсы доступны тогда, когда этого требует сеть работ.
В реальной компании это часто не так.
Предположим, backend-разработка D должна стартовать в день 7. Но нужный разработчик занят другим проектом до дня 10.
Логика зависимостей разрешает старт в день 7, а ресурсное ограничение — только в день 10.
Тогда D заканчивается уже не в день 13, а позже. Вместе с ней сдвигаются F и G.
| Ситуация | Старт D | Окончание D | Последствие |
|---|---|---|---|
| Ресурс свободен | 7 | 13 | Проект укладывается в 18 дней |
| Ресурс доступен с дня 10 | 10 | 16 | Последующая ветка проекта сдвигается |
Именно поэтому критический путь сетевой модели и реальный ограничивающий контур проекта могут различаться.
Это особенно заметно в портфеле, где один сотрудник участвует сразу в нескольких проектах.
Подробнее: как ресурсные ограничения влияют на сроки проекта.
Зачем руководителю критический путь
Практическая ценность критического пути — не в красивом выделении красным цветом на диаграмме Ганта. Он помогает понять, где изменение действительно влияет на обязательство по сроку.
1. Понимать последствия задержки
Если некритическая работа имеет резерв пять дней, задержка на два дня сама по себе ещё не означает срыв проекта.
Если работа имеет нулевой резерв, аналогичная задержка требует внимания сразу.
2. Не распределять внимание одинаково
У руководителя проекта ограничено время. Критический путь помогает выделить те работы, изменение которых сейчас наиболее чувствительно для конечной даты.
Это не означает, что остальные работы «неважны». Они могут быть критичны по качеству, стоимости, безопасности или содержанию. Критический путь характеризует именно влияние на срок.
3. Проверять эффект ускорения
Ускорение некритической работы необязательно сократит проект.
Если аналитика H вместо трёх дней займёт один, проект всё равно завершится в день 18 — запуск ждёт другую ветку.
Поэтому перед тем как добавлять людей или платить за ускорение, полезно проверить, находится ли работа на ограничивающей последовательности.
4. Видеть изменение критического пути
Критический путь не высечен в камне. Он зависит от текущих длительностей, связей и условий.
После изменения оценки, зависимости или доступности ресурса критическая последовательность может измениться.
Поэтому её полезно рассматривать не как постоянное свойство проекта, а как характеристику текущей версии плана.
Типичные ошибки при работе с критическим путём
| Ошибка | Почему это неверно |
|---|---|
| «Критическая = самая важная задача» | Критичность относится к влиянию на срок, а не к бизнес-важности |
| «Самая длинная задача и есть критический путь» | Путь — это последовательность зависимых работ |
| «Критический путь всегда один» | В проекте могут существовать несколько критических веток одинаковой длительности |
| «Один раз рассчитали — больше не меняется» | Он может измениться после пересчёта графика |
| «CPM автоматически учитывает занятость сотрудников» | Классический расчёт сети не решает проблему ограниченных ресурсов сам по себе |
Короткий чек-лист
- работы проекта связаны реальными зависимостями;
- для них определены длительности;
- выполнен прямой проход;
- известна минимальная длительность сетевой модели;
- выполнен обратный проход;
- рассчитан общий резерв;
- работы с нулевым резервом проверены как критические;
- дополнительно проверена доступность ограниченных ресурсов;
- критический путь пересматривается после существенных изменений плана.
Что делать дальше
Чтобы разобраться с критическим путём на собственном проекте, не обязательно начинать с большого графика. Возьмите 7–10 крупных работ, укажите длительность и реальные зависимости, а затем выполните прямой проход от начала к концу.
После этого пройдите график обратно и сравните ранние и поздние даты. Работы с нулевым резервом покажут критическую последовательность вашей модели.
Затем сделайте второй шаг, которого нет в упрощённом учебном примере: проверьте, действительно ли назначенные специалисты доступны в рассчитанные периоды. Именно здесь теоретический сетевой график превращается в реальный календарно-ресурсный план.