Срок проекта с параллельными этапами: проверка по сценариям

Какой вопрос решает этот расчёт

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

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

В GAO Schedule Assessment Guide, Best Practice 8 объясняется риск точек слияния: их момент определяется наиболее поздней входящей ветвью, и определяющая ветвь может меняться. Это методический источник по расписаниям; требования государственных проектов не переносятся на обычный сервисный заказ.

Учебные условия: две подготовки и общий финал

Рассмотрим полностью вымышленный проект. Подготовки A и B стартуют одновременно на отметке 0 и используют разных доступных исполнителей и оборудование. Финал C длится ровно 2 часа, начинается сразу после завершения обеих подготовок и имеет отдельный доступный ресурс. Отсчёт ведётся непрерывными рабочими часами без перерывов и внешних ожиданий.

Каждая подготовка занимает либо 2, либо 8 часов. Для обеих условно заданы вероятности 50% и 50%. В первом варианте длительности A и B независимы. Это явные предположения учебной модели, а не результат измерений компании и не оценка рынка. Поэтому вероятность каждой из четырёх комбинаций равна 0,5 × 0,5 = 0,25.

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

Сначала рассчитайте четыре полных исхода

1. A = 2, B = 2: финал идёт с 2 до 4; проект готов на отметке 4. Вес сценария — 25%.
2. A = 2, B = 8: финал идёт с 8 до 10; проект готов на отметке 10. Вес — 25%.
3. A = 8, B = 2: финал также идёт с 8 до 10; готовность — 10. Вес — 25%.
4. A = 8, B = 8: обе подготовки готовы к 8, финал завершается на 10. Вес — 25%.

План по средним длительностям даёт среднее A = среднее B = (2 + 8) / 2 = 5 часов. Подстановка этих двух средних в схему даёт max(5, 5) + 2 = 7 часов. Однако средняя длительность полного проекта по сценариям равна 0,25 × 4 + 0,75 × 10 = 8,5 часа.

Это разные операции: максимум средних длительностей и среднее максимумов не обязаны совпадать. Ни семь, ни восемь с половиной часов сами по себе не означают определённой надёжности обещания. В этой модели к отметке 7 готовы только проекты из первого сценария: 25%. К отметке 8,5 доля та же, потому что промежуточных исходов здесь нет.

К отметке 10 готовы все четыре сценария. Это 100% внутри специально ограниченной модели, где более длинных исходов не предусмотрено. Объявлять на этом основании безусловную гарантию реальному клиенту нельзя: неполный перечень рисков не превращается в отсутствие рисков.

Одинаковые оценки этапов не задают их совместное поведение

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

• Обе всегда короткие или обе всегда длинные. Сценарии (2, 2) и (8, 8) имеют по 50%. Проект завершается на 4 или 10; среднее равно 7, вероятность готовности к 7 равна 50%.
• Одна всегда короткая, другая длинная. Сценарии (2, 8) и (8, 2) имеют по 50%. Проект всегда заканчивается на 10; среднее равно 10, вероятность готовности к 7 равна 0%.

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

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

Как подготовить данные для решения о дате

1. Зафиксируйте версию состава работ, точку начала отсчёта и определение готового результата. Передача файла и подтверждённая приёмка могут быть разными событиями.
2. Отделите фактически завершённые этапы от оставшихся. Для открытого проекта оценивайте оставшуюся работу из текущего состояния, а не повторяйте уже потраченное время.
3. Для каждого совместного сценария укажите длительности, условия, вес и основание веса: наблюдения сопоставимых проектов либо явно обозначенное экспертное предположение.
4. Проверьте зависимости, сотрудников, оборудование и рабочие окна внутри каждого сценария. Невыполнимое расписание нельзя считать благоприятным исходом.
5. Сложите веса только тех сценариев, где весь результат готов не позже рассматриваемого срока. Сохраните также причины опоздания и ветви, определившие завершение.

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

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

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

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

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

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

Проверки и вывод

• Четыре независимых сценария имеют веса по 25%, их сумма равна 100%.
• Финал не начинается, пока не готовы обе ветви.
• План по средним даёт 7, среднее полных исходов — 8,5, готовность к 7 — 25%.
• Изменение совместных сценариев при прежних отдельных оценках меняет результат.
• Неизвестные вероятности и недоступные ресурсы не скрыты убедительной датой.

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

Источник и границы примера

GAO: Schedule Assessment Guide, GAO-16-89G, раздел Best Practice 8; печатные страницы 100–103 посвящены неопределённости и слиянию ветвей, 115–116 — корреляции. Проверено 12 октября 2026 года.

Все длительности, веса и расчёты приведены как оригинальный учебный пример редакции. Они не характеризуют клиентов SABSUS, не подтверждают коммерческое обещание и не задают норматив срока.