PERT-диаграмма: как увидеть зависимости и рассчитать срок проекта

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

PERT расшифровывается как Program Evaluation and Review Technique — метод оценки и пересмотра программ. На схеме работы или события соединены стрелками. Стрелка означает, что следующий элемент не может начаться или завершиться до выполнения предыдущего. Узлы показывают значимые результаты: утверждённый макет, готовую инфраструктуру, пройденное испытание. Рядом с работой указывают оценку длительности, а иногда ответственного и потребность в ресурсе.

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

PERT не обязана содержать каждую мелкую задачу. Для разговора с руководителем достаточно важных работ и контрольных точек. Для команды, которая рассчитывает критический путь, нужна более точная сеть. Уровень детализации выбирают по решению, которое предстоит принять. Если схема занимает несколько экранов и её никто не может прочитать, часть узлов лучше сгруппировать.

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

Например, в проекте открытия магазина Гант покажет, на какие недели назначены ремонт, закупка оборудования и обучение персонала. Сетевая схема покажет, что монтаж касс зависит от готовности электрики, а обучение продавцов можно начать до окончательной расстановки мебели. После согласования этой логики её разумно перенести в календарный план.

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

Сначала определите начало и конец проекта. Между ними разместите работы или вехи, которые действительно меняют состояние результата. Формулировка «дизайн согласован» яснее, чем «заняться дизайном»: в первом случае понятно, что проверять. Каждому элементу дайте короткое имя и уникальный номер, чтобы обсуждение не зависело от положения блока на рисунке.

Соедините элементы направленными стрелками. Для каждой связи задайте вопрос: что именно мешает начать следующую работу раньше? Иногда ответом будет готовый результат, иногда — решение заказчика, доступ к площадке или освободившийся сотрудник. Не проводите стрелку только потому, что задачи принято перечислять в таком порядке. Ложная зависимость превращается в лишнее ожидание.

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

В PERT часто используют три оценки для каждой работы: оптимистичную, наиболее вероятную и пессимистичную. Оптимистичная предполагает благоприятные, но достижимые условия; наиболее вероятная описывает обычный ход работы; пессимистичная учитывает правдоподобные препятствия. Это не три дедлайна, которые можно выбирать по настроению. Команда должна договориться, какие события включает каждая оценка.

Ожидаемую длительность рассчитывают по формуле (O + 4M + P) / 6, где O — оптимистичная оценка, M — наиболее вероятная, P — пессимистичная. Если задача может занять от двух до пяти дней, а чаще всего занимает три, результат равен (2 + 4 × 3 + 5) / 6 = 3,17 дня. Четырёхкратный вес наиболее вероятной оценки не устраняет неопределённость, а лишь даёт согласованный способ приблизить её в планировании.

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

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

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

Второй проход — провести зависимости. Для каждой работы перечислите непосредственных предшественников, а не все события, случившиеся раньше. Если C зависит от B, а B от A, отдельная стрелка A → C обычно не нужна. Проверяйте, не образовался ли цикл: работа A не может ждать B, если B одновременно ждёт A. Цикл означает, что команда смешала условие начала с обратной связью или не разделила работу на части.

Третий проход — поставить оценки времени. Попросите исполнителей назвать O, M и P по одному понятному сценарию. Зафиксируйте допущения: объём работы, доступность данных, число итераций согласования. Когда оценки делает один руководитель за всех, схема выглядит быстро, но ошибки обнаруживаются уже после запуска. Особенно тщательно обсудите ветки, сходящиеся перед общей контрольной точкой.

Четвёртый проход — нарисовать и проверить сеть. Расположите начало слева, конец справа; сгруппируйте параллельные ветки. Пройдите по каждой стрелке и спросите, нужна ли она на самом деле. Затем посчитайте суммарную длительность путей и проверьте ресурсные конфликты. Только после этой проверки переносите даты в детальный график работ проекта.

Предположим, команда готовит онлайн-курс. После утверждения темы параллельно начинаются две ветки. Первая: сценарий уроков — запись — монтаж. Вторая: платформа — настройки оплаты — проверка покупки. Финальное тестирование требует готовности обеих веток. Маркетинговая страница может создаваться параллельно и присоединяется к запуску перед публикацией.

Пусть сценарий занимает 4 дня, запись 3, монтаж 5. Ветка контента длится 12 дней. Настройка платформы занимает 5 дней, оплаты 2, проверка 2: техническая ветка длится 9 дней. Если тестирование после их слияния занимает 2 дня, минимальная оценка от старта веток до готовности курса — 14 дней. Сложить 12 и 9 было бы ошибкой: работы идут параллельно. Взять 9 тоже нельзя: тест ждёт более длинную ветку.

Теперь представим, что запись откладывается на четыре дня. Контентная ветка удлиняется до 16, а общий прогноз — до 18. Если же оплата задерживается на два дня, техническая ветка станет 11-дневной, но завершение пока не сдвинется: она всё ещё короче контентной. Это не повод игнорировать проблему. Запас технической ветки уменьшился, и следующая задержка может сделать её критической.

Реальный проект редко настолько прост. При десяти и более работах полезно собрать таблицу: работа, предшественники, три оценки, ожидаемая длительность, исполнитель, дата обновления. Из неё строится диаграмма. Расчёт и рисунок должны опираться на один набор данных, иначе руководитель увидит две несовместимые версии плана.

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

Не путайте критический путь с самыми дорогими или самыми сложными задачами. Небольшое согласование может быть критичным, потому что без него нельзя начать следующую работу. И наоборот, трудоёмкая параллельная задача может иметь несколько дней резерва. При изменении оценок критический путь меняется, поэтому его следует пересчитывать после значимых событий, а не считать раз и навсегда заданным.

Резерв показывает, насколько работа может сдвинуться без переноса конечного срока при нынешнем плане. Но резерв не является свободным временем конкретного сотрудника. Если специалист нужен сразу в нескольких ветках, календарь ресурсов может оказаться более жёстким, чем сеть логических зависимостей. Сверяйте выводы PERT с нагрузкой команды, особенно когда параллельных работ много.

PERT особенно помогает в проектах с несколькими потоками работ, неопределёнными сроками и внешними зависимостями: запуск продукта, строительство, внедрение системы, исследование или большое мероприятие. Она делает видимым путь к результату и даёт общий язык для разговора о рисках. Руководство видит узкие места, исполнители — причины приоритета, заказчик — условия обещанной даты.

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

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