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

Знакомая ситуация: команда работает, все заняты, задачи закрываются одна за другой. А срок всё равно срывается.

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

Критический путь — это цепочка задач, которая определяет минимально возможную длительность проекта.

Если хотя бы одна задача на нём задерживается — сдвигается весь срок! Не «может сдвинуться». Сдвигается. Без вариантов.

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

Звучит просто. Но в реальном проекте с сотней задач и десятком зависимостей путь не найти глазом. А ошибки делают по одному и тому же сценарию.

Где кроются ошибки
Считаем срок задач по отдельности. Задача «А» — 3 дня, «Б» — 5 дней. Но «Б» не начнётся, пока не закончится «А». Реальный срок — 8 дней, а не «в среднем 4». Знакомо?

Игнорируем зависимости. Тестирование ждёт разработки, разработка — аналитики, аналитика — согласования с заказчиком. Каждое ожидание — это время. Оно не исчезает, потому что «мы же не сидим сложа руки».

Считаем по «нормальному» сценарию. Нормальный — это когда никто не заболел, ничего не переделали, все отвечали быстро. В реальности на каждый этап добавляется правка и уточнение. В критическом пути 10 задач — значит, 10 точек, где всё может пойти не так.

Как находить критический путь
Метод простой, но требует дисциплины.
Шаг 1. Список задач. Не «примерный», а конкретный: оценка длительности плюс зависимости.
Шаг 2. Определяем зависимости: что должно завершиться до начала каждой задачи.
Шаг 3. Строим сетевую диаграмму: задачи — узлы, зависимости — стрелки. Сразу видно, какие цепочки длиннее.
Шаг 4. Считаем ранние и поздние сроки: от начала — когда задача может стартовать не раньше, от конца — не позже, чтобы не сдвинуть итог.
Шаг 5. Находим резерв — разницу между поздним и ранним стартом. На критическом пути резерва нет. Ни минуты.

Как управлять критическим путём
Найти — полдела. Удержать — вторая половина.
Визуализируйте. Путь должен быть виден всей команде, а не лежать в таблице в папке «проектные документы». Когда цепочка на виду, проще объяснить, почему «ещё недельку» на одной задаче ломает весь план.
Контролируйте входы и выходы. У каждой задачи на критическом пути — чёткий критерий завершения. Не «вроде сделали», а «передано, принято, подписано». Мутные границы — главный источник задержек.
Планируйте ресурсы заранее. Если критический ресурс загружен двумя проектами — конфликт не «если», а «когда».
Пересматривайте регулярно. Путь может смениться: задача на «второстепенном» пути задержалась — и вот она уже на критическом. Считали путь только на старте — управляете прошлым.

Честно говоря, критический путь — это не методология ради методологии. Это способ сказать заказчику не «постараемся», а «вот конкретная цепочка, которая определяет ваш срок. Ускорим задачу X на 2 дня — проект готов на 2 дня раньше. Задача Y задержится на 3 — сдвинется и срок». Математика, а не обещания.

И ещё он объясняет, почему «просто добавить людей» не всегда помогает. Задаче на критическом пути нужно 10 дней — десять человек за день её не сделают. Закон Брука в действии.

Начните с малого: возьмите текущий проект, выпишите 5-7 ключевых задач и постройте простую цепочку зависимостей. Увидите свой критический путь. Возможно, он вас удивит.