Диаграмма draw.io «Как будет оформление заявок на осмотр» · открыть файл .drawio (открывается в draw.io / diagrams.net)
Комментарии (3) · по состоянию на 2026-09-15
К странице
claude-code · 2026-09-15 09:13 МСК · открыт · 73074888
[Ревью] Общие замечания по странице «Как будет» и BPMN-диаграмме:
[Критично] Название страницы/диаграммы — «Бизнес-процесс оформления грузоперевозки» / «To Be Процесс оформления заявки на грузоперевозку» — терминология другого проекта (грузоперевозки), хотя описывается осмотр судна. Явный след копипасты, риск ошибочно расширить скоуп на домен грузоперевозок. Нужно переименовать.
[Критично, MVP] На BPMN-диаграмме есть открытый вопрос (стикер): не решено бизнес-правило — Агент сам назначает Исполнителя, или Исполнители откликаются, а Агент выбирает из откликнувшихся. Это ключевой сценарий модуля «Заявки», не зафиксирован.
[Критично, MVP] Не решено, кто инициирует дату/место осмотра — Агент планирует сразу при создании заявки, или Исполнитель предлагает вариант, а Агент подтверждает. Прямо влияет на модель данных заявки и экранные формы.
[Критично, MVP] Статус «Заявка отклонена» Исполнителем присутствует на диаграмме, но дальнейший процесс не описан: возврат заявки Агенту, лимит попыток переназначения, уведомление сторон.
[Критично, MVP] SLA из НПА («3 часа» на направление Акта, «48 часов» на осмотр судна) не оформлены как измеримое системное требование — нужны таймер, статус «Просрочено», механизм эскалации.
[Критично, MVP] Не формализован критерий «когда осмотр обязателен» (стартовое событие процесса) — нужно явное бизнес-правило для инициации осмотра.
Просьба зафиксировать решения по этим пунктам (можно прямо на BPMN-диаграмме или в отдельном разделе) — они влияют на ключевые сценарии MVP модуля «Заявки».
[Ревью] По пунктам: 1. Решено — страница и диаграмма переименованы («Как будет: Бизнес-процесс оформления заявки на осмотр» / «Как будет оформление заявок на осмотр»), термин «грузоперевозка» убран. 2-3. Уточнение внесено — стикеры с открытыми вопросами на диаграмме убраны, новый поток явно показывает: Агент назначает Исполнителя заявки (шаг «Назначить Исполнителя заявки»), а дату/место осмотра предлагает сам Исполнитель (шаг «Назначить время и локацию проведения осмотра» в дорожке Исполнителя). Правило зафиксировано. 4. Уточнение внесено — статус «Заявка отклонена»/«Возвращено» на диаграмме ведёт обратно к шагу «Назначить Исполнителя заявки», т.е. процесс переназначения виден на уровне диаграммы. 5. Пока актуально: в обновлённой диаграмме нет явного таймера/статуса «Просрочено» для SLA (3ч/48ч из НПА) — если эскалация не входит в MVP, предлагаем явно зафиксировать это как решение (аналогично п.6), чтобы не осталось недосказанности. 6. Решено, спасибо — согласны, что критерий обязательности осмотра определяется за рамками системы.
Комментарии (3) · по состоянию на 2026-09-15
К странице
[Ревью] Общие замечания по странице «Как будет» и BPMN-диаграмме:
Просьба зафиксировать решения по этим пунктам (можно прямо на BPMN-диаграмме или в отдельном разделе) — они влияют на ключевые сценарии MVP модуля «Заявки».
[Ревью] По пунктам: 1. Решено — страница и диаграмма переименованы («Как будет: Бизнес-процесс оформления заявки на осмотр» / «Как будет оформление заявок на осмотр»), термин «грузоперевозка» убран. 2-3. Уточнение внесено — стикеры с открытыми вопросами на диаграмме убраны, новый поток явно показывает: Агент назначает Исполнителя заявки (шаг «Назначить Исполнителя заявки»), а дату/место осмотра предлагает сам Исполнитель (шаг «Назначить время и локацию проведения осмотра» в дорожке Исполнителя). Правило зафиксировано. 4. Уточнение внесено — статус «Заявка отклонена»/«Возвращено» на диаграмме ведёт обратно к шагу «Назначить Исполнителя заявки», т.е. процесс переназначения виден на уровне диаграммы. 5. Пока актуально: в обновлённой диаграмме нет явного таймера/статуса «Просрочено» для SLA (3ч/48ч из НПА) — если эскалация не входит в MVP, предлагаем явно зафиксировать это как решение (аналогично п.6), чтобы не осталось недосказанности. 6. Решено, спасибо — согласны, что критерий обязательности осмотра определяется за рамками системы.