Построение PERT-диаграммы по текстовому плану

1. Назначение документа

Этот документ задаёт правила, по которым нейронная сеть должна преобразовать текстовый план проекта в JSON-описание PERT-диаграммы для сервиса PERT.

Документ самодостаточен: для построения диаграммы не нужно читать другие файлы проекта.

Используемая модель — строгий сетевой график типа «работа на дуге» (Activity-on-Arrow, AOA), применяемый в классической методике PERT:

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

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

Расчёт записывает раннюю календарную дату в поле date каждого события и помечает работы критического пути обычным цветом red. Длительность работы задаётся отдельно от подписи. Одно заполненное поле означает одиночную оценку, два или три — расчёт PERT по формуле (оптимистичная + 4 × наиболее вероятная + пессимистичная) / 6; отсутствующее поле в формуле считается нулём.

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

Передайте модели:

1. текстовый план проекта;
2. этот документ;
3. команду: «Построй диаграмму строго по приложенной спецификации».

Модель работает в два этапа.

Этап 1. Проверка полноты плана

До построения JSON модель должна определить:

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

Отсутствие длительности само по себе не препятствует построению сети. Длительность требуется уточнять только тогда, когда пользователь явно просит отразить сроки, но не приводит их.

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

Пример допустимого ответа при нехватке данных:

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

Этап 2. Выдача результата

После получения всех существенных ответов модель должна вернуть ровно один блок json, содержащий один корневой JSON-объект. До и после блока не должно быть пояснений, таблиц, комментариев или Markdown-текста.

3. Основные понятия

3.1. Событие

Событие — момент, в котором зафиксирован результат одной или нескольких работ. Оно не занимает времени и не расходует ресурсы.

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

Название события должно описывать свершившийся факт, а не действие:

• правильно: Техническое задание утверждено;
• правильно: Оборудование доставлено;
• неправильно: Утвердить техническое задание;
• неправильно: Доставка оборудования.

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

3.2. Реальная работа

Реальная работа — действие, которое переводит проект из одного события в другое и может требовать времени и ресурсов. В JSON она задаётся дугой с lineStyle: "solid".

Название работы должно обозначать действие:

• Подготовить техническое задание;
• Провести испытания;
• Согласовать договор.

Название и длительность работы хранятся раздельно. Если дана одна оценка, используйте соответствующее ей поле, например:

"duration": { "mode": "single", "mostLikely": 3 }

Если даны две или три оценки, используйте режим pert, например:

"duration": { "mode": "pert", "optimistic": 2, "mostLikely": 3, "pessimistic": 7 }

Все оценки должны быть конечными неотрицательными числами и идти в порядке optimistic ≤ mostLikely ≤ pessimistic среди заполненных полей. Редактор автоматически выбирает single, когда заполнено одно поле, и pert, когда заполнено два или три. В расчёте PERT отсутствующая оценка считается нулём, но само пустое поле в JSON не записывается. Единица измерения в JSON не хранится и на диаграмме не выводится, поэтому все значения одной диаграммы должны использовать заранее согласованный масштаб. Не следует самостоятельно вычислять исходные оценки, нормализовать их или переводить в другие единицы.

3.3. Ожидание

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

Примеры:

• Ожидать решение ведомства с "duration": { "mode": "single", "mostLikely": 10 };
• Выдержать бетон с "duration": { "mode": "single", "mostLikely": 7 }.

Ожидание нельзя заменять фиктивной работой, поскольку фиктивная работа имеет нулевую длительность.

3.4. Фиктивная работа

Фиктивная работа выражает только зависимость. Она:

• не является действием;
• не занимает времени;
• не требует ресурсов;
• изображается пунктирной дугой;
• имеет пустую подпись "label": "";
• имеет lineStyle: "dashed";
• в каноническом результате имеет "duration": null.

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

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

3.5. Путь

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

4. Обязательные правила сетевого графика

Готовая диаграмма должна одновременно выполнять все следующие правила.

1. Существует ровно одно исходное событие без входящих дуг.
2. Существует ровно одно завершающее событие без выходящих дуг.
3. У каждого другого события есть хотя бы одна входящая и хотя бы одна выходящая дуга.
4. От исходного события достижима каждая вершина.
5. Из каждой вершины достижимо завершающее событие.
6. В сети нет изолированных компонентов, тупиковых ветвей и лишних событий.
7. В сети нет петель from == to.
8. В сети нет направленных циклов и возвратов к уже наступившим событиям.
9. Между одной упорядоченной парой событий существует не более одной дуги.
10. Каждая реальная работа представлена ровно одной сплошной дугой.
11. Каждая фиктивная дуга выражает необходимую логическую зависимость и имеет нулевую длительность.
12. Работа может начаться только после наступления её исходного события.
13. Событие наступает только после завершения всех входящих работ.
14. Граф не добавляет зависимостей, которых нет в подтверждённом плане.
15. Граф не теряет ни одной зависимости из подтверждённого плана.
16. Идентификаторы событий уникальны и стабильны; их числовая часть не определяет порядок или направление зависимостей.
17. Все дуги направлены слева направо: для каждой дуги выполняется from.x < to.x.

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

5. Алгоритм преобразования плана в диаграмму

Шаг 1. Зафиксировать границы

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

Шаг 2. Выделить элементы плана

Внутренне составьте перечень со столбцами:

• работа;
• результат работы;
• непосредственные предшественники;
• тип: реальная работа или ожидание;
• длительность, если она дана;
• источник требования в плане.

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

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

Шаг 3. Уточнить зависимости

Для каждой работы определите:

1. что должно быть завершено непосредственно перед её началом;
2. что сможет начаться сразу после её завершения;
3. может ли она идти параллельно с соседними работами;
4. требует ли следующая работа всех предшественников или только их части.

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

Шаг 4. Построить сеть «работа на дуге»

1. Создайте исходное событие.
2. Представьте каждую реальную работу или ожидание отдельной сплошной дугой.
3. Создавайте событие там, где фиксируется результат работы, разветвляется последующая работа или объединяются обязательные зависимости.
4. Для каждой группы предшественников создайте такое исходное событие последующей работы, которое наступает только после завершения всей группы.
5. Если существующее событие добавляет последующей работе лишнего предшественника, разделите события и используйте фиктивную дугу.
6. Если две реальные работы получили одинаковые from и to, добавьте промежуточное событие и минимально необходимую фиктивную дугу.
7. Объедините все терминальные работы в одном завершающем событии, при необходимости используя фиктивные дуги.

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

Шаг 5. Пронумеровать события

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

node_1, node_2, node_3, ...

Пропуски номеров допустимы, например после удаления события. Направление дуги определяется только полями from и to, а не числовыми частями ID.

Шаг 6. Назначить координаты

Ранг события определяется только логической глубиной:

rank(node_1) = 0
rank(v) = 1 + max(rank(p)) для всех непосредственных предшественников p

Длительности работ на ранг и расстояние между колонками не влияют.

Используйте базовую сетку:

• первая колонка: x = 120;
• горизонтальный шаг ранга: 280 px;
• базовая горизонтальная ось: y = 400;
• вертикальный шаг между дорожками: 160 px;
• координаты — только целые числа.

Координата колонки:

x = 120 + rank * 280

Если в одном ранге m событий, первоначально распределите их симметрично:

y(i) = 400 + (i - (m - 1) / 2) * 160, где i = 0..m-1

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

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

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

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

Если самая верхняя координата меньше 120, сдвиньте все вершины и текстовые блоки вниз на одинаковое целое расстояние.

Шаг 7. Сформировать подписи

Для событий:

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

Для реальных работ:

• используйте действие;
• при необходимости переносите текст для удобства чтения — длина подписи и количество строк не ограничиваются;
• не добавляйте длительность в label: она задаётся отдельным полем duration.

Перенос строки внутри JSON задаётся последовательностью \n. Нельзя вставлять физический перевод строки внутрь JSON-строки.

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

Шаг 8. Сериализовать и проверить JSON

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

6. Канонический JSON-контракт

6.1. Корневой объект

Поля revision, createdAt и updatedAt относятся к серверному состоянию и не входят в переносимый ответ нейросети. id диаграммы и стабильные ID работ сохраняются при экспорте.

6.2. Событие — элемент nodes

Базовый размер карточки события в текущем рендерере — 140 × 50 px, скругление углов — 8 px. Подпись располагается внутри и центрируется. Высота остаётся фиксированной, а ширина автоматически увеличивается, если самая длинная строка подписи не помещается с горизонтальными отступами.

6.3. Работа — элемент edges

Допустимые значения orgUnit:

Отдел выбирается по результату работы, а не по названию продукта. Программная реализация ПП Бота относится к production, а методика, реализуемая в боте, — к development_pp. Неизвестный или пустой ключ допустим в черновике, но блокирует sync-readiness для реальной работы.

Формы поля duration:

null

{ "mode": "single", "mostLikely": 5 }

{ "mode": "pert", "optimistic": 2, "mostLikely": 5, "pessimistic": 8 }

Расчётное значение PERT является производным и не записывается в JSON. Интерфейс создаёт single, когда заполнено ровно одно из трёх полей, и pert, когда заполнено не менее двух; в последнем случае пустое поле не записывается, но при расчёте считается равным 0. Пунктирная дуга может технически сохранить ранее заданный объект длительности, но редактор не показывает и не рассчитывает его, пока стиль остаётся dashed; при подготовке нового канонического результата для фиктивной дуги используйте null.

Стиль lineStyle: "dotted" не имеет канонического смысла в строгой PERT-диаграмме и не поддерживается редактором. При загрузке старого файла такая дуга мигрирует в solid с предупреждением.

ID работы не меняется при переименовании, изменении длительности или вершин. Пара (from, to) также должна быть уникальной во всём массиве edges.

6.4. Текстовый блок — элемент textBlocks

Текстовые блоки используются только для легенды или явно запрошенного пояснения. Они не заменяют события и работы и не влияют на зависимости.

В канонический JSON запрещено включать вычисляемые и служебные поля _scroll, scrollY, isAutoSizing, _startWidth, _startHeight, _startX и _startY.

6.5. Палитра

Допустимы только:

• none — нейтральное оформление;
• green — исходное или завершающее событие, явно подтверждённая готовность;
• blue — явно указанная важная веха;
• yellow — явно указанная зона внимания или риск;
• red — критическая работа после расчёта либо явно указанный блокер;
• gray — внешний либо второстепенный элемент.

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

7. Полный пример

7.1. Исходный неполный план

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

План допускает несколько несовпадающих сетей, поэтому сначала модель должна спросить:

1. Могут ли подготовка технического задания и бюджета выполняться параллельно?
2. Создание прототипа зависит только от готовности технического задания или также от бюджета?
3. Для заключения договора требуются и техническое задание, и бюджет?
4. Проект считается завершённым только после готовности прототипа и заключения договора?
5. Каковы длительности четырёх работ, если их требуется показать на диаграмме?

7.2. Полученные уточнения

- Техническое задание и бюджет готовятся параллельно.
- Прототип зависит только от технического задания.
- Договор зависит одновременно от технического задания и бюджета.
- Для завершения нужны и прототип, и договор.
- Для ТЗ оценки составляют 2, 3 и 7 рабочих дней: оптимистичная, наиболее вероятная и пессимистичная соответственно.
- Для бюджета, прототипа и договора даны наиболее вероятные оценки: 2, 5 и 4 рабочих дня.

7.3. Итоговый ответ нейронной сети

{
  "id": "Guide101",
  "version": "1.2",
  "name": "Подготовка прототипа и договора",
  "strategicGoalId": "GUIDE-G1",
  "assignees": [],
  "nodes": [
    {
      "id": "node_1",
      "x": 120,
      "y": 440,
      "label": "Проект\nзапущен",
      "url": "",
      "color": "green",
      "date": null
    },
    {
      "id": "node_2",
      "x": 400,
      "y": 280,
      "label": "ТЗ\nподготовлено",
      "url": "",
      "color": "none",
      "date": null
    },
    {
      "id": "node_3",
      "x": 680,
      "y": 440,
      "label": "ТЗ и бюджет\nготовы",
      "url": "",
      "color": "none",
      "date": null
    },
    {
      "id": "node_4",
      "x": 680,
      "y": 120,
      "label": "Прототип\nсоздан",
      "url": "",
      "color": "none",
      "date": null
    },
    {
      "id": "node_5",
      "x": 960,
      "y": 280,
      "label": "Проект\nзавершён",
      "url": "",
      "color": "green",
      "date": null
    }
  ],
  "edges": [
    {
      "id": "work_zbAvnx0u1sJd",
      "from": "node_1",
      "to": "node_2",
      "label": "Подготовить ТЗ",
      "lineStyle": "solid",
      "url": "",
      "color": "none",
      "duration": { "mode": "pert", "optimistic": 2, "mostLikely": 3, "pessimistic": 7 },
      "orgUnit": "production",
      "status": "not_started",
      "checklist": []
    },
    {
      "id": "work_GxGg1kY59CQv",
      "from": "node_1",
      "to": "node_3",
      "label": "Подготовить бюджет",
      "lineStyle": "solid",
      "url": "",
      "color": "none",
      "duration": { "mode": "single", "mostLikely": 2 },
      "orgUnit": "admin",
      "status": "not_started",
      "checklist": []
    },
    {
      "id": "work_mO-DE51z5lyI",
      "from": "node_2",
      "to": "node_3",
      "label": "",
      "lineStyle": "dashed",
      "url": "",
      "color": "none",
      "duration": null
    },
    {
      "id": "work_TTs0T2v25_sM",
      "from": "node_2",
      "to": "node_4",
      "label": "Создать прототип",
      "lineStyle": "solid",
      "url": "",
      "color": "none",
      "duration": { "mode": "single", "mostLikely": 5 },
      "orgUnit": "production",
      "status": "not_started",
      "checklist": []
    },
    {
      "id": "work_Tr_HM-OO4xpE",
      "from": "node_3",
      "to": "node_5",
      "label": "Заключить договор",
      "lineStyle": "solid",
      "url": "",
      "color": "none",
      "duration": { "mode": "single", "mostLikely": 4 },
      "orgUnit": "admin",
      "status": "not_started",
      "checklist": []
    },
    {
      "id": "work_7oCuypxk4ipf",
      "from": "node_4",
      "to": "node_5",
      "label": "",
      "lineStyle": "dashed",
      "url": "",
      "color": "none",
      "duration": null
    }
  ],
  "textBlocks": [
    {
      "id": "text_1",
      "x": 120,
      "y": 640,
      "text": "**Обозначения**\nСплошная линия — работа.\nПунктир — логическая зависимость.",
      "fontSize": 14,
      "color": "#000000",
      "width": 320,
      "height": 90,
      "url": "",
      "bgColor": "gray"
    }
  ]
}

Первая фиктивная работа node_2 → node_3 гарантирует, что договор начнётся только после готовности и ТЗ, и бюджета, но прототип по-прежнему сможет начаться сразу после ТЗ. Вторая фиктивная работа node_4 → node_5 гарантирует, что завершающее событие наступит только после готовности прототипа и заключения договора.

Пояснение выше предназначено для чтения примера. В реальном ответе модели должен присутствовать только JSON-блок.

8. Обязательная проверка перед выдачей

8.1. Синтаксис и контракт

• JSON разбирается стандартным JSON.parse без исправлений.
• Корень содержит только id, version, name, strategicGoalId, assignees, nodes, edges, textBlocks.
• У каждого элемента присутствуют все поля его канонического типа.
• Типы всех значений соответствуют таблицам раздела 6.
• Нет комментариев, завершающих запятых, undefined, NaN или физических переводов строк внутри строк.
• Нет служебных полей рендерера.

8.2. Идентификаторы и ссылки

• Все node.id уникальны и имеют вид node_N; пропуски номеров допустимы.
• Все textBlocks.id уникальны и имеют вид text_N; пропуски номеров допустимы.
• Каждый edge.from и edge.to ссылается на существующую вершину.
• Все edge.id уникальны и имеют формат work_<12 URL-safe символов>.
• Нет дуг вершины в саму себя.
• Нет повторяющихся пар (from, to).
• Для удобства чтения дуги располагаются слева направо: from.x < to.x; номера from и to порядок не задают.

8.3. Структура сети

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

8.4. Содержание и оформление

• Названия событий описывают свершившиеся факты.
• Названия реальных работ описывают действия.
• Ожидания изображены сплошными дугами.
• Фиктивные дуги имеют пустые подписи и стиль dashed.
• Стиль dotted не используется.
• Длительности хранятся отдельно от label, а у новых фиктивных дуг равны null.
• Для PERT присутствуют как минимум два числовых поля в порядке optimistic ≤ mostLikely ≤ pessimistic; отсутствующая оценка считается нулём при расчёте.
• Неизвестные длительности не придуманы.
• Координаты целочисленные и соответствуют рангам.
• Стрелки не проходят через посторонние вершины.
• Подписи и текстовые блоки не перекрывают элементы сети.
• Цвета не приписывают элементам неподтверждённый статус.

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

9. Соответствие возможностям сервиса

Спецификация использует фактические возможности текущего редактора:

• прямоугольные вершины высотой 50 px, минимальной шириной 140 px и адаптивным расширением под подпись;
• прямые направленные дуги от границы одной вершины до границы другой;
• подписи дуг в середине линии и вдоль её направления;
• необязательные длительности над дугами: одиночные или рассчитанные по трём оценкам PERT;
• стили линий solid и dashed;
• цвета none, green, blue, red, yellow, gray;
• ссылки у вершин, дуг и текстовых блоков;
• Markdown и переносы строк в подписях;
• отдельные текстовые блоки с заданным размером и цветом фона.

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

10. Методологическая основа

Правила логической последовательности, связности сети и проверки зависимостей согласованы с GAO Schedule Assessment Guide. Представление работ на дугах, событий в узлах и фиктивных зависимостей соответствует описанию Activity-on-Arrow в Praxis Framework.

Русская терминология событие, работа, ожидание, фиктивная работа и сетевой график согласована с пособием И. Г. Бороздина «Сетевое планирование и управление строительством» (Стройиздат, 1967) и условными обозначениями сетевого графика в ГОСТ Р 59113-2020.