Зачем рассчитывается критический путь?

Критический путь в управлении проектами

Критический путь это последовательность задач, которая определяет минимальное время выполнения всего проекта. За 10+ лет я видел, как правильное понимание критического пути спасало проекты от срыва сроков.

Что такое критический путь?

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

Зачем это рассчитывается?

1. Прогнозирование реальных сроков

Но-критический путь показывает, когда проект действительно закончится. Многие PM ошибаются, складывая просто все длительности задач — это неправильно, потому что некоторые задачи могут выполняться параллельно.

Пример:

• Задача A: 3 дня
• Задача B: 5 дней
• Задача C: 2 дня (зависит от A)

Если B и A выполняются параллельно, проект закончится в max(3+2, 5) = 5 дней, не 10.

2. Определение задач, требующих особого внимания

Задачи на критическом пути — это узкие места. Если они задержатся, задержится весь проект. Поэтому:

• Выделяем им лучших разработчиков
• Мониторим их часто
• Готовим плаву B, если что-то пойдёт не так

Задачи НЕ на критическом пути имеют "slack" (резерв времени). Они могут немного задержаться без влияния на общий срок.

3. Оптимизация ресурсов

Когда ты знаешь критический путь:

• Не нужно ускорять задачи вне критического пути (потратишь ресурсы впустую)
• Можно перенести ресурсы с некритических задач на критические

Реальный пример: Проект мобильного приложения:

• Критический путь: Backend API (8 недель)
• Некритический: Design UI (3 недели, slack = 5 недель)

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

4. Управление рисками

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

• Начинаем её раньше
• Выделяем лучших людей
• Готовим альтернативный подход

Тазначи вне критического пути могут быть более экспериментальными.

Как рассчитывается критический путь?

Метод CPM (Critical Path Method)

Шаг 1: Разбиваем проект на задачи с зависимостями.

Шаг 2: Рассчитываем Forward Pass (от начала к концу):

• Early Start (ES) — самое раннее начало
• Early Finish (EF) — самый ранний конец

Шаг 3: Рассчитываем Backward Pass (от конца к началу):

• Late Start (LS) — самое позднее начало
• Late Finish (LF) — самый поздний конец

Шаг 4: Рассчитываем slack (резерв времени):

• Slack = LS - ES
• Если Slack = 0, задача на критическом пути

Пример из реальной жизни

Проект: Website redesign (8 недель)

Задачи:

1. Research (A): 2 недели (зависит от начала)
2. Design (B): 4 недели (зависит от A)
3. Frontend (C): 6 недель (зависит от B)
4. Backend (D): 5 недель (зависит от A, параллельно с C)
5. Testing (E): 2 недели (зависит от C и D)
6. Launch (F): 1 неделя (зависит от E)

Критический путь: A → B → C → E → F = 2+4+6+2+1 = 15 недель

Задачи на критическом пути: A, B, C, E, F Задачи с резервом: D (slack = 3 недели, может начаться позже)

Мой опыт

В одном проекте я пересчитал критический путь и обнаружил:

• PM ошибочно считал Frontend критическим
• На самом деле критический путь был через Database migration
• Мы выделили лучшего DBA на migration
• Результат: проект завершился в срок вместо 4 недель отставания

Инструменты

• MS Project — старый стандарт
• Gantt Chart — визуализация
• Jira — для Agile проектов с зависимостями
• Monday.com, Asana — для управления проектами

Когда это важно?

• Важно: Большие проекты (6+ месяцев), много зависимостей
• Менее важно: Agile проекты с 2-недельными спринтами (легче реагировать на изменения)
• Не критично: Маленькие задачи (1-2 недели)

Для большинства стартапов я рекомендую проще — использовать Gantt чарт и визуально видеть критический путь, не углубляясь в математику CPM.