PERT (Program Evaluation and Review Technique)

Самая известная история успеха PERT — миф. Метод разработала команда Военно-морского флота США и консалтинговой компании Booz Allen Hamilton в 1958 году для программы баллистических ракет «Polaris», и десятилетиями повторяется утверждение, что именно PERT позволил завершить программу на полтора-два года раньше срока. Но детальное исследование историка Гарви Сапольски «The Polaris System Development» (MIT Press, 1972) показало: даже не большинство задач программы реально управлялись через PERT — метод в основном применялся постфактум, при подготовке отчётов для Конгресса, который распоряжался бюджетом программы. Вице-адмирал Уильям Рэйборн «безжалостно продвигал» эффектные PERT-диаграммы не столько ради управления проектом, сколько ради политической защиты: сложные на вид графики впечатляли контролирующих и держали на расстоянии другие ведомства, претендовавшие на бюджет программы. Британский королевский флот позже перенял PERT по той же причине — не ради реального управления, а ради бюрократической защиты проекта. В этой статье — точная история и формулы метода, разбор мифа Polaris, академическая критика PERT (систематическая недооценка риска расписания через «эффект слияния путей») и как использовать реальный калькулятор PERT в OrgDevTools.

Что такое PERT и когда он нужен

PERT нужен там, где длительность задачи невозможно оценить точно — в первую очередь для новых, ранее не выполнявшихся работ (НИОКР, разработка нового продукта, нестандартные проекты), где единственная точечная оценка систематически скрывает реальную неопределённость. Вместо одной цифры PERT требует трёх оценок — оптимистичной, наиболее вероятной и пессимистичной — и вычисляет ожидаемую длительность и меру неопределённости по каждой задаче. Метод особенно полезен вместе с методом критического пути (CPM), который определяет последовательность задач, но не учитывает неопределённость их длительности, и с реестром рисков — для задач, чья неопределённость (высокая σ) заслуживает отдельного риск-плана. Раскладку самого проекта на задачи для последующей оценки по PERT обычно готовят через иерархическую структуру работ (WBS).

Происхождение и исследовательская база

Программа Polaris, 1958 год

Метод создала исследовательская группа, которую возглавлял Дональд Дж. Малкольм (Donald G. Malcolm) из Booz Allen Hamilton, вместе со специалистами Отдела специальных проектов ВМФ США (Special Projects Office) — в частности, с Уиллардом Фазаром (Willard Fazar) — и инженерами Lockheed. Команда была сформирована в феврале 1958 года для управления беспрецедентно сложной программой: одновременной разработкой самой ракеты «Polaris», ядерной подводной лодки-носителя и системы навигации. Оригинальная методика была впервые опубликована в статье Malcolm, Roseboom, Clark, Fazar «Application of a Technique for Research and Development Program Evaluation» в журнале Operations Research (1959). Booz Allen сознательно не стала патентовать PERT, что позволило методу быстро распространиться сначала по другим программам Министерства обороны США, а затем в гражданской промышленности.

Реальность программы Polaris: не легенда, а бюрократическая защита

Согласно анализу RAND Corporation (цит. по Сапольски) даже не большинство задач программы Polaris реально контролировались через PERT — лишь относительно небольшая их часть. Основная практическая ценность PERT для программы заключалась не в улучшении реального управления, а в демонстрационном эффекте: цветные, технически сложные графики создавали образ высокой управленческой компетентности, что помогало защитить бюджет и автономию проекта от вмешательства других ведомств и политического давления. Более поздние опросы участников программы показали, что респонденты в целом признавали пользу PERT, но затруднялись привести конкретные примеры, где метод реально изменил решение или сроки.

«Сетевой анализ — вот реальная польза [PERT]. Он может снижать превышения сроков и бюджета, а заодно и делать его пользователей внешне похожими на лучших менеджеров» (обзор Cadmus, цит. по анализу Сапольски).

Ключевые идеи и принципы

1. Три оценки вместо одной точечной

   Для каждой задачи оцениваются оптимистичная длительность (O — если всё пойдёт идеально), наиболее вероятная (M — реалистичный сценарий) и пессимистичная (P — при значительных сложностях). Три оценки, желательно от разных членов команды или экспертов, обнажают реальный диапазон неопределённости, скрытый за единственной цифрой.

2. Ожидаемая длительность — взвешенное среднее по бета-распределению

   Формула te = (O + 4M + P) / 6 приближает математическое ожидание бета-распределения, придавая наиболее вероятной оценке вчетверо больший вес, чем крайним сценариям. Это даёт более реалистичную ожидаемую длительность задачи, чем простое среднее трёх оценок или единственная точечная оценка.

3. Стандартное отклонение как индикатор неопределённости

   Формула σ = (P − O) / 6 оценивает разброс возможных значений длительности. Задачи с большим разбросом между оптимистичной и пессимистичной оценкой имеют более высокую неопределённость и заслуживают приоритетного внимания — дополнительной проработки, резервов или более частого контроля.

4. Совокупная неопределённость проекта

   Дисперсии независимых задач складываются: совокупная дисперсия проекта — это сумма дисперсий отдельных задач (σ²), а совокупное стандартное отклонение проекта — квадратный корень из этой суммы. Ожидаемая длительность проекта te ± σ формирует доверительный интервал (около 68% для одного σ, около 95% для двух σ), в котором, по предположению модели, с заданной вероятностью уложится реальный срок.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: пессимистичная оценка систематически занижается из-за социального давления показаться уверенным.

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

   Как избежать

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

2. Ошибка 2: ожидаемая длительность рассчитывается, но стандартное отклонение игнорируется.

   Команда получает te по формуле PERT, но не использует σ для выявления задач с наибольшей неопределённостью, теряя главную ценность метода — информацию о том, где реально нужны резервы и дополнительное внимание.

   Как избежать

   рассчитывать и явно использовать стандартное отклонение для выявления и приоритизации задач с наибольшей неопределённостью.

3. Ошибка 3: te воспринимается как жёсткий дедлайн, а не как ожидаемое значение с разбросом.

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

   Как избежать

   сообщать заказчику и руководству диапазон (te ± σ) вместо единственной цифры, и явно объяснять вероятностную природу оценки.

4. Ошибка 4: расчёт риска ведётся только по одному критическому пути без учёта эффекта слияния путей.

   При нескольких параллельных путях, сходящихся в одной точке сети, реальный риск расписания выше, чем показывает PERT по единственному критическому пути, — проект систематически завершается позже расчётного te (см. критику MacCrimmon и Ryavec).

   Как избежать

   для сетей с несколькими параллельными путями дополнять расчёт PERT имитационным моделированием (Монте-Карло) вместо расчёта по одному критическому пути.

5. Ошибка 5: PERT применяется постфактум для отчётности, а не как реальный инструмент управления рисками.

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

   Как избежать

   использовать оценки PERT на этапе планирования и регулярно пересматривать их по ходу проекта, а не готовить задним числом только для отчётов.

Как измерить эффект

• Точность прогноза: доля задач, фактическая длительность которых уложилась в интервал te ± σ (целевой ориентир около 68%, как и предполагает модель); систематическое отклонение вверх сигнализирует о заниженных пессимистичных оценках или об эффекте слияния путей.

• Доля задач с явно завышенной уверенностью (низкая σ при высокой фактической вариативности): снижение доли таких задач говорит о том, что команда преодолела социальное давление к оптимистичным пессимистичным оценкам.

• Своевременность расчёта: оценки PERT сделаны на этапе планирования, а не задним числом для отчётности — ключевое отличие реального использования метода от практики программы Polaris.

План внедрения

• Неделя 1: определить задачи проекта с высокой неопределённостью длительности (новые, ранее не выполнявшиеся работы).

• Неделя 2: собрать три независимые оценки (оптимистичную, наиболее вероятную, пессимистичную) для каждой такой задачи, явно поощряя честную пессимистичную оценку.

• Неделя 3: рассчитать ожидаемую длительность и стандартное отклонение по формулам PERT для каждой задачи и по проекту в целом.

• Неделя 4: выявить задачи с наибольшей неопределённостью (максимальным σ) и заложить под них резервы; для сетей с несколькими параллельными путями — дополнительно оценить риск слияния путей.

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

Как работать с фреймом «PERT» в OrgDevTools

Фрейм «PERT» в OrgDevTools — рабочий калькулятор, а не просто форма для заметок: во вкладке «Оценки» для каждой задачи вводятся три числа (O, M, P), и te = (O+4M+P)/6 и σ = (P−O)/6 считаются автоматически по настоящей формуле PERT; строка с максимальным σ подсвечивается как самая неопределённая. Вкладка «Визуализация» показывает диапазон te ± σ по каждой задаче на общей шкале. Вкладка «Итоги» суммирует ожидаемую длительность всех задач и совокупное σ проекта (по формуле корня из суммы дисперсий) и формирует вердикт с указанием самой рискованной задачи, а также позволяет прямо создать задачу на снижение её неопределённости.

Чего фрейм не делает. Фрейм суммирует te и σ по всем перечисленным задачам последовательно, как если бы они лежали на одном критическом пути, — он не строит сеть зависимостей между задачами и не учитывает параллельные пути и точки их слияния. Это значит, что фрейм воспроизводит именно классическую, критикуемую версию PERT (см. раздел «Ограничения») и не защищён от эффекта слияния путей — для проекта с параллельными ветками совокупное σ, показанное фреймом, может быть заниженной оценкой реального риска расписания. Полноценную сетевую диаграмму с зависимостями между задачами (метод критического пути) фрейм не строит — за этим нужно обращаться к разделу «Проекты и Задачи» → «Сетевой график».

Инструмент: ✅ Проекты и Задачи → «Сетевой график» (реальный, не учебный инструмент; отдельно от фрейма-калькулятора выше). Задачи и связи проекта представляются как настоящая PDM-сеть с зависимостями — в отличие от фрейма, который считает te/σ по списку задач без учёта их последовательности и точек слияния.

Книги и источники

• Malcolm D.G., Roseboom J.H., Clark C.E., Fazar W. — «Application of a Technique for Research and Development Program Evaluation» (Operations Research, 1959). Оригинальная статья, представившая метод PERT.

• Harvey M. Sapolsky — «The Polaris System Development: Bureaucratic and Programmatic Success in Government» (MIT Press, 1972). Детальное историческое исследование, показавшее, что успех PERT в программе Polaris во многом миф.

• K.R. MacCrimmon, C.A. Ryavec — «An Analytical Study of the PERT Assumptions» (RAND Corporation / Operations Research, 1964). Формальная критика статистических допущений PERT и эффекта слияния путей.