Я проверяю новую версию бизнес-системы на редком исключении раньше, чем на основном сценарии

Я не считаю новую версию бизнес-системы принятой только потому, что в ней удачно прошёл главный сценарий. Главный путь обычно репетируют. Настоящая проверка начинается там, где заказ пришёл с неполными данными, документ вернули на исправление или человек сделал обычную, но неидеальную вещь.

Это не любовь к сложностям. Так я ищу места, в которых команда после релиза снова откроет мессенджер и начнёт спасать процесс вручную. Если редкое исключение нельзя понять и безопасно довести до результата, новая версия пока удобна только для демонстрации.

Основной сценарий показывает намерение, исключение — устойчивость

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

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

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

Я начинаю с обещания, а не с кнопки

У каждого исключения должно быть простое описание результата. Не «обработать ошибку», а «клиент получит понятный статус до конца дня», «заказ не уйдёт в учёт с неверной ценой», «ответственный увидит возврат и сможет его принять». Тогда проверка не сводится к вопросу, нажимается ли кнопка.

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

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

Три проверки, которые часто забывают

Возврат назад. Сотрудник заметил проблему и отменил действие. Остались ли данные согласованными? Понятно ли, кому вернулась задача? Не пропало ли обещание клиенту?

Передача другому человеку. Исполнитель ушёл на встречу или смена закончилась. Может ли коллега продолжить без звонка и археологии в почте? Надёжная передача начинается с понятного результата этапа, а не с фразы «я почти закончил».

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

Как провести приёмку без театра

Я не собираю десяток наблюдателей у большого экрана. Беру одного человека, который будет выполнять работу, и один свежий пример. Рядом — владелец процесса, который может ответить, какой результат нужен бизнесу. Остальные подключаются только там, где действительно владеют решением.

Мы не читаем сценарий вслух. Человек действует так, как действовал бы в понедельник утром. Если он спрашивает, куда идти дальше, это уже результат проверки. Если приходится объяснять скрытое правило, его стоит вынести в интерфейс, подсказку или маршрут, а не считать ошибкой пользователя.

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

Не каждый редкий случай нужно автоматизировать

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

Ошибка — прятать такие случаи за универсальным статусом «в работе». Тогда их не видно в очереди, нельзя проверить срок и невозможно понять, что повторяется. Если исключение возникает регулярно, это уже не исключение, а кандидат на отдельное правило.

Откуда брать исключения для первой проверки

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

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

Что фиксировать после теста

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

Затем важно назначить владельца изменения и дату повторной проверки. Иначе найденное исключение превращается в ещё одну заметку после релиза. Хороший темп здесь небольшой: исправить один разрыв, снова пройти тот же сценарий, только потом брать следующий. Так команда не размывает ответственность и видит, как новая версия становится спокойнее.

Что я считаю хорошим результатом

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

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