Сценарии и исключения: основной поток пишется за час, альтернативные — неделю

Сценарий согласован, разработка идёт, и на третий день разработчик спрашивает: «а если заказ отменили, пока покупатель оформлял возврат?» В постановке на это ни слова — и ответ сочиняется прямо в коде.

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

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

Почему диаграмма их прячет

Схема процесса показывает те ветки, которые нарисовали. Пустое место на ней не выглядит пустым: стрелка уходит дальше, и кажется, что всё учтено. Текст устроен иначе. Пронумерованный шаг сам задаёт вопрос «а если нет?», и отсутствие ответа видно сразу — под шагом нет ни одной строки.

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

Как выглядит сценарий, который держит исключения

Формат не важен, важна привязка: каждое отклонение прикреплено к шагу, на котором оно возникает, и у каждой ветки есть свой результат.

СЦЕНАРИЙ  Оформление возврата товара
Участник      покупатель
Предусловие   заказ доставлен, прошло не больше 14 дней
Триггер       покупатель нажимает «Вернуть товар»

1. Система показывает позиции заказа, доступные к возврату
2. Покупатель выбирает позиции и причину
3. Система рассчитывает сумму к возврату
4. Покупатель подтверждает возврат
5. Система создаёт заявку и отправляет её на склад

1а. Доступных позиций нет → сообщение с причиной, сценарий завершён
3а. Товар куплен со скидкой на комплект → сумма по правилу BR-12
4а. Покупатель закрыл окно до подтверждения → черновик хранится 24 ч
5а. Склад не ответил → заявка создана со статусом «ожидает склад»,
    повторная отправка раз в 10 минут, покупателю — обычное подтверждение

Результат     заявка создана, покупатель видит её в списке возвратов

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

Где искать исключения

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

Вопрос к шагу	Что обычно обнаруживается
Данных нет или они в неверном формате?	Пустой список, обязательное поле, пришедшее пустым из другой системы
Внешняя система не ответила или ответила поздно?	Нет решения, ждать ли, повторять ли и что видит пользователь
Пользователь прервался и вернулся?	Неясно, сохраняется ли ввод и сколько живёт черновик
Действие выполнено дважды?	Двойной клик создаёт две заявки, повторная отправка — два списания
Права или статус изменились по ходу?	Заказ отменили, пока покупатель оформлял возврат
То же самое одновременно делает другой?	Два оператора берут одну заявку, последний перезаписывает первого

Последние три строки — краевые случаи времени: повтор, изменение по ходу, одновременность. Их почти никогда не называет заказчик и почти всегда встречает поддержка.

Кто решает, что делать в исключении

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

Если ответа нет, а сроки идут, допустимо записать допущение: «принимаем, что заявка создаётся без ответа склада; уточнить до релиза». Записанное допущение отличимо от решения и может быть оспорено. Решение, принятое молча в коде, оспорить уже нельзя — о нём не знают.

Не всякое исключение — ошибка. Ветка «склад не ответил» не должна показывать покупателю сообщение об ошибке: для него ничего не сломалось. Исключение сценария описывает поведение системы, а не текст на экране.

Когда остановиться

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

То, что решили не описывать, лучше не оставлять пустым, а пометить явно: «поведение не определено; по умолчанию — отказ с общим сообщением». Тогда разработчик не сочиняет, а тестировщик знает, что проверять.

Признак, что исключения искали: под основным потоком строк больше, чем в нём самом.

Проверка за двадцать минут

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

Готовая форма с заполненным примером — шаблон сценария с исключениями.

Что дальше

Сценарии оперируют объектами — заказ, позиция, возврат, заявка. Следующий разрыв появляется, когда у этих объектов нет общего описания, и каждый участник понимает «заказ» по-своему. Это предмет модели данных.