Как построить
PERT-диаграмму

Главный закон

Событие ждёт все входящие работы

Слияние дуг всегда означает логическое «И». После наступления события все выходящие работы получают право начаться и наследуют полный набор его предпосылок.

Все выходящие работы наследуют все условия события

Если из события «A и B завершены» выходят C и D, обе работы зависят и от A, и от B. Если C должна зависеть только от A, а D — от A и B, начинать их из одной вершины нельзя. Нужно сохранить отдельное событие «A завершена» и создать отдельное объединённое событие.

Лишний вход создаёт ложную зависимость

Каждая входящая работа становится обязательной предпосылкой для каждой выходящей. Поэтому объединение ветвей «на всякий случай» незаметно запрещает параллельное выполнение и искусственно увеличивает срок.

Событие — контракт состояния

Читайте вершину как утверждение: «К этому моменту завершено следующее: …». Для каждой вершины проверьте три свойства.

1. 1
   Необходимость. Все ли входящие работы действительно нужны для наступления состояния?
2. 2
   Достаточность. Достаточно ли завершить все входы, чтобы считать состояние достигнутым?
3. 3
   Проверяемость. Можно ли однозначно подтвердить наступление события?

Когда план ещё не ясен

Стройте сеть как инструмент прояснения

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

Начните с двух известных состояний

Зафиксируйте текущее состояние и ближайший или конечный результат. Промежуток между ними пока может оставаться крупным.

Идите от результата назад

Для целевого события спрашивайте: «Что должно быть истинно непосредственно перед тем, как этот результат станет возможен?» Перед публикацией могут потребоваться принятый релиз-кандидат, готовность продакшена и открытое окно релиза. Повторите вопрос для каждого найденного состояния.

Затем пройдите сеть вперёд

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

Сохраняйте неизвестное как неизвестное

Если способ достижения результата пока неясен, оставьте одну укрупнённую реальную работу. Разверните её позже, когда детали изменят понимание порядка, параллельности, риска или точки контроля.

(Требования согласованы)
        ── Реализовать интеграцию с провайдером ──▶
(Интеграция готова к приёмочным тестам)

Превратите неопределённость в работу исследования

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

(Требование к авторизации сформулировано)
        ── Провести технический спайк ──▶
(Допустимый способ авторизации выбран)

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

Проясняйте ближайший полезный горизонт

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

Практический цикл построения

1. 01
   Постройте грубый путь к результату.

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

2. 02
   Найдите реальную параллельность.

   Разведите работы в ветви, только если им не нужны результаты друг друга.

3. 03
   Найдите обязательные слияния.

   Объединяйте результаты перед работой, которой действительно нужны все входы.

4. 04
   Уточните значимые внутренние зависимости.

   Разделите крупную работу там, где промежуточный результат открывает новую ветвь или требует отдельной приёмки.

5. 05
   Выполните обратный и прямой проходы.

   Сверьте необходимые условия результата и возможность старта каждой работы.

6. 06
   Повторяйте цикл.

   Возвращайтесь к укрупнённым участкам, когда появляется новая информация.

Масштаб модели

Выберите полезную степень детализации

Детализация нужна не сама по себе. Она полезна, если меняет зависимости, показывает параллельность, открывает точку контроля или позволяет принять решение.

Работа слишком крупная, если скрывает важный результат

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

Работа слишком мелкая, если не влияет на сеть

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

Оставляйте работу одной дугой, когда

• ✓
  Один набор входных условий.

  Всем внутренним действиям нужны одни и те же предпосылки.

• ✓
  Один проверяемый результат.

  Промежуточные состояния не используются другими ветвями.

• ✓
  Нет критичного ожидания внутри.

  Внешняя задержка не требует отдельного контроля.

• ✓
  Порядок никому не важен.

  Внутренняя последовательность не меняет остальную сеть.

События отражают готовность, а не процент

«Реализация выполнена на 50 %» редко является полезным событием. Хороший промежуточный результат можно передать или использовать: «Контракт API опубликован», «Авторизация работает в тестовом окружении», «Миграция совместима с предыдущей версией».

Типовые конструкции

Основные схемы зависимостей

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

(Исходное состояние) ── Выполнить A ──▶ (A завершена)
                                           ── Выполнить B ──▶ (B завершена)

                    ┌── Выполнить B ──▶ (B завершена) ──┐
(A завершена) ──────┼── Выполнить C ──▶ (C завершена) ──┼──▶ (B, C и D завершены)
                    └── Выполнить D ──▶ (D завершена) ──┘

(A завершена) ── Выполнить C ──▶ (C завершена)
      └── фиктивная связь ──▶ (A и B завершены) ── Выполнить D ──▶
                                  ▲
(B завершена) ────────────────────┘

(A завершена) ── Выполнить C ──▶ (C завершена)
      └── фиктивная ──┐
                      ├──▶ (A и B завершены) ── Выполнить E ──▶
      ┌── фиктивная ──┘
(B завершена) ── Выполнить D ──▶ (D завершена)

(Требования согласованы)
        ── Подготовить и утвердить контракт API ──▶ (Контракт API утверждён)
                                                       ├── Реализовать backend ──▶
                                                       └── Реализовать frontend ──▶

(Заявка отправлена провайдеру)
        ── Получить доступ к API ──▶
(Доступ к API получен)

(Первичное ревью завершено) ── Устранить замечания ──▶ (Замечания устранены)
                                                ── Провести повторное ревью ──▶

(Изменения объединены)
        ── Выполнить CI-сборку и тесты ──▶
(Сборка прошла CI)

(Варианты известны)
        ── Выбрать механизм авторизации ──▶
(Механизм авторизации выбран)

(Релиз-кандидат принят) ── Ожидать окна релиза ──▶ (Окно открыто)
                                            ── Выпустить релиз ──▶

Нулевая логическая связь

Когда действительно нужна фиктивная работа

Фиктивная работа требуется, когда без неё нельзя одновременно сохранить обязательную зависимость и не добавить лишнюю другой работе.

Признак необходимости

Предположим, интеграция требует готовности backend и frontend, а документацию API можно закончить после backend, не ожидая frontend. Нельзя начинать документацию из общего события «Backend и frontend готовы»: возникнет лишняя зависимость. Сохраните «Backend готов» отдельно и передайте его в событие начала интеграции пунктирной связью.

Тест удаления

1. 1
   Мысленно удалите пунктирную связь.
2. 2
   Определите, какая работа после этого сможет начаться раньше.
3. 3
   Сравните получившееся разрешение старта с реальной логикой проекта.

Если удаление ничего не меняет, связь, скорее всего, избыточна.

Что нельзя изображать пунктиром

• ожидание ответа или окна;
• согласование и принятие решения;
• code review и тестирование;
• сборку, публикацию и развёртывание;
• получение доступа;
• технический спайк;
• исправление дефектов;
• резерв времени.

Не используйте пунктир и для неизвестности. Неясный участок остаётся крупной реальной работой или превращается в работу исследования.

Не минимизируйте число фиктивных связей любой ценой

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

Ограничение редактора: одна дуга на пару событий

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

                    ┌── Выполнить A ───────────────────────────────┐
(Можно начинать) ───┤                                              ├──▶ (A и B завершены)
                    └── Выполнить B ──▶ (B завершена) ── фиктивная ┘

Нумерация нужна сервису, но не логике

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

Структура и аудит

Как проверить готовую сеть

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

Структурные правила

• ✓
  Один исходный и один итоговый результат.

  Все обязательные ветви начинаются после старта и приводят к финишу.

• ✓
  Граф ацикличен.

  Ни одна стрелка не возвращается в уже достигнутое событие.

• ✓
  Каждая работа встречается один раз.

  Общий результат разветвляется после единственного выполнения работы.

• ✓
  Нет скрытых предпосылок.

  Доступы, решения, окружения и внешние данные выражены структурой.

• ✓
  Нет лишних предпосылок.

  Работа не ждёт ветвь, результат которой ей не нужен.

• ✓
  Нет потерянных ветвей.

  Каждая работа имеет понятное отношение к итоговому результату.

Повторную работу нельзя показывать циклом. Разверните её вперёд: «Первичная проверка завершена» → «Устранить замечания» → «Замечания устранены» → «Провести повторную проверку».

Проверка без таблиц

1. 01
   Прочитайте каждую вершину.

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

2. 02
   Проверьте каждую выходящую работу.

   Можно ли начать её сразу после события, если не учитывать занятость людей и календарь?

3. 03
   Проверьте каждое слияние.

   Должна ли каждая последующая работа действительно ждать каждый вход?

4. 04
   Проверьте каждое разветвление.

   У всех ли выходящих работ полностью одинаковые условия начала?

5. 05
   Удалите мысленно каждый пунктир.

   Должна появиться конкретная ошибка — преждевременный старт или потеря условия.

6. 06
   Пройдите от финала назад.

   Найдите забытые внешние входы и ветви, которые не приводят к результату.

7. 07
   Выполните прямой прогон.

   Отмечайте, какие работы открываются после каждого достигнутого события.

Типичные ошибки

Развёрнутый пример

Небольшой программный релиз

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

(Цель релиза определена)
        ── Уточнить и согласовать требования ──▶
(Требования согласованы)

                              ┌── Подготовить контракт API ──▶ (Контракт API утверждён)
                              ├── Подготовить макеты ────────▶ (Макеты утверждены)
(Требования согласованы) ─────┼── Настроить тестовое окружение ▶ (Окружение готово)
                              └── Подготовить сценарии ──────▶ (Сценарии готовы)

(Контракт API утверждён) ── фиктивная ──┐
                                        ├──▶ (Можно реализовывать backend) ── Реализовать backend ──▶ (Backend готов)
(Окружение готово) ──────── фиктивная ──┘

(Контракт API утверждён) ── фиктивная ──┐
                                        ├──▶ (Можно реализовывать frontend) ─ Реализовать frontend ─▶ (Frontend готов)
(Макеты утверждены) ──────── фиктивная ──┘

(Backend готов) ────────── фиктивная ──┐
(Frontend готов) ───────── фиктивная ──┼──▶ (Можно начинать интеграцию)
(Окружение готово) ─────── фиктивная ──┘              └── Интегрировать систему ──▶ (Интеграция завершена)

(Интеграция завершена) ── фиктивная ──┐
                                      ├──▶ (Можно начинать приёмочные тесты)
(Сценарии готовы) ─────── фиктивная ──┘              └── Провести тесты ──▶ (Релиз-кандидат принят)
                                                                                   └── Развернуть релиз ──▶ (Релиз опубликован)

Что показывает пример

• полный реестр работ не требовался до начала построения;
• контракт API выделен как событие, потому что открывает две ветви;
• каждая работа получила только необходимые предпосылки;
• приёмочные сценарии готовятся параллельно реализации;
• пунктир используется только для объединения условий;
• каждое слияние читается как логическое «И».

Перед публикацией

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

Десять правил в короткой форме

1. Вершина — состояние, дуга — работа.
2. Событие наступает после завершения всех входящих работ.
3. Все выходящие работы наследуют полный набор предпосылок события.
4. Слияние и разветвление ветвей означают «И», а не «или».
5. Фиктивная работа передаёт только логику и всегда имеет нулевую длительность.
6. Ожидание, ревью, тестирование и автоматическая операция — реальные работы, если занимают время.
7. Полный список работ заранее не обязателен: сеть уточняется итеративно.
8. Детализируйте только там, где это меняет зависимости или решения.
9. В сервисе между одной парой событий допустима только одна дуга.
10. Сначала проверяйте логику, затем добавляйте время.

Материалы для углубления

• ГОСТ Р 56716-2015 «Проектный менеджмент. Техника сетевого планирования» ↗
• GAO Schedule Assessment Guide ↗
• Praxis Framework: Activity-on-Arrow diagram ↗
• NASA Systems Engineering Handbook ↗
• ASQ: Arrow Diagram ↗