23 сентября 2026 г. · 12 мин чтения

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

evanalysis.pro · сентябрь 2026 · 12 минут

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


Что такое критический путь проекта: определение

Критический путь проекта (Critical Path, CP) — это самая длинная непрерывная последовательность взаимозависимых задач от старта до финиша проекта. Ключевые свойства этой последовательности:

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

Метод расчёта критического пути называется CPM — Critical Path Method. Он разработан в конце 1950-х годов и до сих пор остаётся основой современного управления расписанием в PMI PMBOK, ISO 21500 и отраслевых стандартах строительства.


Метод расчёта критического пути (CPM): прямой и обратный проход

Расчёт критического пути выполняется на сетевом графике — диаграмме, где узлы представляют задачи, а стрелки — зависимости между ними (метод PDM, Precedence Diagram Method). Алгоритм состоит из двух проходов:

Прямой проход: ранние даты

При прямом проходе для каждой задачи определяют:

ПараметрОбозначениеФормула
Ранний стартESmax(EF всех предшественников)
Ранний финишEFES + Duration

Прямой проход идёт от первой задачи к последней. Ранний финиш последней задачи — это самая ранняя возможная дата завершения проекта.

Обратный проход: поздние даты

Обратный проход идёт от финиша к старту и определяет:

ПараметрОбозначениеФормула
Поздний финишLFmin(LS всех последователей)
Поздний стартLSLF − Duration

Полный резерв времени (Total Float)

После обоих проходов для каждой задачи рассчитывают полный резерв:

TF = LS − ES = LF − EF

Задачи с TF = 0 образуют критический путь. Задачи с TF > 0 — некритические: их можно сдвинуть на величину резерва без ущерба для даты финиша.


Пример расчёта критического пути

Разберём расчёт на конкретном примере — строительство складского комплекса. У нас шесть задач с зависимостями:

Сетевой график: задачи и зависимости

ЗадачаНазваниеДлит., дн.Предшественник
AПроектирование15
BСогласование ТУ10
CФундамент20A
DПрокладка коммуникаций12B
EМонтаж каркаса18C, D
FКровля и фасад14E

Выполняем прямой проход (ES и EF):

ЗадачаESEFLSLFTFСтатус
A0150150Критический
B010132313Некритическая
C153515350Критический
D1022233513Некритическая
E355335530Критический
F536753670Критический

Критический путь: A → C → E → F (15 + 20 + 18 + 14 = 67 дней). Задача B («Согласование ТУ») имеет резерв 13 дней — её можно начать позже или задержать на 13 дней без последствий для финиша. Задача D («Прокладка коммуникаций») тоже имеет резерв 13 дней — по той же причине.

Важный вывод из примера: задача E («Монтаж каркаса») зависит от двух предшественников — C и D. Её ранний старт определяется самым поздним из их EF: max(35, 22) = 35. Именно поэтому C является критической задачей, а D — нет.


Задачи критического пути и задачи вне него: разница в управлении

Одно из ключевых применений критического пути — дифференциация интенсивности контроля. Не все задачи проекта требуют одинакового внимания:

ХарактеристикаКритические задачиНекритические задачи
Резерв (TF)= 0> 0
Влияние задержки на финишПрямое (день в день)Нет (в пределах резерва)
Периодичность мониторингаЕжедневноЕженедельно
Приоритет при нехватке ресурсовПервыйВторой (можно «одолжить» ресурс)
Реакция PM на отставаниеНемедленная эскалацияАнализ остатка резерва

Практическое правило: PM управляет критическими задачами ежедневно и некритическими с малым резервом (TF ≤ 5 дней) — еженедельно. Задачи с резервом более 2–3 недель требуют только периодической проверки состояния.


Когда некритическая задача становится критической

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

Ситуация 1 — исчерпание резерва из-за накопленного отставания

Задача D из нашего примера имеет резерв 13 дней. Если реальное выполнение заданий B и D вместе займёт на 14 дней больше плана — задача D «входит в критический путь» и финиш сдвигается. Это не внезапное событие: резерв тает постепенно, и его снижение ниже 5 дней — ранний сигнал для усиления контроля.

Ситуация 2 — изменение объёма работ

Если длительность некритической задачи увеличивается (дополнительный объём, техническое усложнение), её резерв сокращается пропорционально. Любое изменение объёма работ требует пересчёта критического пути — не только для изменённой задачи, но для всего сетевого графика.

Ситуация 3 — новые зависимости между задачами

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

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


Критический путь и график Ганта: что Гант не показывает

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

Что нужно знатьГрафик ГантаСетевой график + CPM
Когда начинается задача✓ ВидноВидно (ES/LS)
Сколько длится задача✓ ВидноВидно
Цепочки зависимостей✗ Скрыто✓ Ключевая функция
Какие задачи критические✗ Не выделяет✓ TF = 0 → критический
Резерв времени задачи✗ Не показывает✓ TF и FF явно
Влияние задержки на финиш✗ Не очевидно✓ Прямой расчёт

На практике эти инструменты используются вместе: Гант даёт наглядную хронологию (понятную всем участникам проекта), а сетевой график с CPM — аналитическую основу для управления финишем. Современные системы управления проектами показывают критический путь прямо на диаграмме Ганта: задачи с нулевым резервом выделяются красным или другим цветом.


Критический путь и SPI: когда индекс расписания должен вас насторожить

Метод освоенного объёма добавляет к критическому пути количественный индикатор — SPI (Schedule Performance Index). Их связь принципиальна для понимания проблемы:

  • SPI < 1,0 означает, что проект в целом выполняет работы медленнее плана. Но это агрегированный показатель: он не говорит, где именно отставание — на критическом пути или на задачах с резервом.
  • Критический путь показывает, где именно нужно смотреть. Если отставание сосредоточено на некритических задачах — финишу ничего не угрожает. Если отставание на критических задачах — финиш сдвинется точно.

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

Практическое правило

Когда SPI падает ниже 0,90 два периода подряд — первый вопрос: «Где это отставание — на критическом пути или вне него?» Если на критическом пути — финиш уже под угрозой, нужна немедленная интенсификация именно этих задач. Если вне критического пути — есть время на анализ и плановую корректировку.


Что делать, когда критический путь поплыл

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

1. Fast-tracking — параллельное выполнение задач

Fast-tracking означает запуск задач, которые изначально были последовательными, параллельно — с перекрытием 20–40%. Например: начать закупку металлоконструкций на финальном этапе проектирования, не дожидаясь полного завершения проекта.

ПараметрFast-trackingCrashing
ПринципПараллельное выполнение последовательных задачДобавление ресурсов для сокращения длительности
СтоимостьНе растёт (если нет переработки)Растёт пропорционально добавленным ресурсам
РискПереработка из-за неготовности входовПадение производительности при перегрузке
Когда применятьЕсть задачи с частичной независимостьюЕсть бюджет на ускорение, штрафы за просрочку
ОграничениеНельзя применить к задачам с жёсткими FS-зависимостямиНе всегда линейный эффект (закон Брукса)

2. Crashing — интенсификация ресурсов

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

Цена дня = (Стоимость crash − Стоимость normal) / (Duration normal − Duration crash)

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

Алгоритм при срыве критического пути

  1. Пересчитайте критический путь по актуальным данным (где именно отставание?).
  2. Оцените доступность fast-tracking: есть ли задачи с частичной независимостью?
  3. Рассчитайте цену crashing и сравните со стоимостью просрочки.
  4. Выберите оптимальную комбинацию: часто применяют оба метода на разных задачах.
  5. Обновите базовый план через change control, зафиксируйте новый критический путь.
  6. Коммуницируйте прогноз заказчику с цифрами, не ожидая вопросов.

Critical Chain как альтернатива CPM

Метод Critical Chain (CC), разработанный Элияху Голдраттом, предлагает альтернативный взгляд на управление расписанием. Ключевые отличия от CPM:

  • Критическая цепь учитывает ресурсы. В отличие от классического CP, который смотрит только на зависимости задач, критическая цепь — это самая длинная цепочка с учётом конкуренции за ресурсы между задачами. Задача на «обычном» критическом пути может оказаться некритической, если ресурс занят более приоритетной задачей.
  • Буферы вынесены явно. В CC «страховые» резервы убираются из индивидуальных задач и переносятся в явные проектный буфер (Project Buffer, в конце проекта) и буферы слияния (Feeding Buffers — перед входами в критическую цепь). Это делает расписание прозрачным: видно, сколько буфера использовано и сколько осталось.
  • Нет мультизадачности на критической цепи. Ресурсы, занятые на критической цепи, защищены от параллельного назначения на другие задачи. Переключение контекста — один из главных «пожирателей» производительности на крупных проектах.

Critical Chain особенно эффективен для проектов с жёсткими ресурсными ограничениями и высокой конкуренцией за ключевых специалистов. Для строительных и промышленных проектов чаще используется классический CPM — он более распространён в отраслевых нормах и понятен всем участникам.


Типичные ошибки при работе с критическим путём

Ошибка 1 — рассчитать критический путь один раз и не обновлять

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

Ошибка 2 — игнорировать зависимости или задавать ложные зависимости

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

Ошибка 3 — применять crashing к некритическим задачам

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

Ошибка 4 — не учитывать ресурсные ограничения

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


С чего начать

  1. Составьте список всех задач проекта с длительностями и зависимостями FS (finish-to-start) — минимальная сеть, достаточная для расчёта критического пути.
  2. Выполните прямой и обратный проход вручную или в любом планировщике (MS Project, Primavera, GanttPro, даже Excel с формулами). Критический путь — задачи с TF = 0.
  3. Установите еженедельный ритм обновления: актуализируйте фактические данные → пересчитайте EF задач → проверьте, не изменился ли критический путь.
  4. Подключите SPI из EVM: при SPI < 0,90 два периода подряд немедленно проверяйте состояние критического пути. Система в evanalysis.pro считает SPI и SPI(t) автоматически — и показывает их в разрезе задач, а не только по проекту в целом.
  5. Если критический путь «поплыл»: сначала оцените fast-tracking (дёшево, но рискованно), затем — crashing (дорого, но предсказуемо). Применяйте только к задачам актуального критического пути.


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

Что такое критический путь проекта простыми словами?

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

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

Для расчёта критического пути нужно: (1) составить список всех задач с длительностями; (2) определить зависимости между задачами; (3) выполнить прямой проход (ранний старт/финиш) и обратный проход (поздний старт/финиш); (4) рассчитать полный резерв TF = LS − ES для каждой задачи. Задачи с TF = 0 образуют критический путь. Большинство современных систем управления проектами делают это автоматически.

Может ли критический путь измениться в ходе проекта?

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

Чем критический путь отличается от критической цепи (Critical Chain)?

Классический критический путь (CPM) учитывает только зависимости между задачами. Критическая цепь (Critical Chain) учитывает ещё и ограничения ресурсов: если один ресурс нужен одновременно на двух задачах, цепь корректируется. Кроме того, в Critical Chain буферы вынесены явно — в конец проекта (Project Buffer) и перед критическими точками входа (Feeding Buffer). CPM более распространён в строительстве и промышленности, Critical Chain — в высокотехнологичных проектах.

Что делать, если в проекте два критических пути?

Несколько критических путей означают, что проект работает с минимальными резервами сразу по нескольким цепочкам. Это существенно повышает риск срыва финиша: достаточно задержки на любом из путей. Рекомендуемые действия: (1) попытаться устранить один из путей через fast-tracking или crashing одной из цепочек; (2) если невозможно — контролировать все критические пути ежедневно, не только один; (3) добавить явный резерв (contingency) в базовый план.

Как связаны критический путь и SPI из метода освоенного объёма?

SPI (Schedule Performance Index) — агрегированный показатель для всего проекта: он показывает, насколько быстро проект выполняет работы в целом. Критический путь даёт локализацию: где именно отставание — на критических задачах или вне них. Правильная реакция на снижение SPI — это сначала проверить критический путь, и только если отставание там — интенсифицировать именно эти задачи.

Посмотрите, как это выглядит на живом проекте

Тест-драйв →

Демо-проект с реальными данными. Бесплатно, без регистрации.

Читайте также

Комментарии

Войдите, чтобы оставить комментарий.