Кнопка передачи заказа готова, но никто не решил, что произойдёт после изменения количества. Так список экранов превращается в спор при запуске. Техническое задание на разработку системы должно описывать действия, условия и ожидаемый результат.
На условном заказе разберём сценарий, словарь данных, исключения и критерии приёмки. Это заготовка требований для внутреннего сервиса, а не обещание функций готового продукта.
Начните с одного законченного процесса
Соберите менеджера, диспетчера и владельца процесса. Попросите пройти один реальный обезличенный заказ: от согласования состава до появления в производственной очереди. Запишите, какие сведения нужны каждому участнику, где он их получает и в какой момент считает свою работу завершённой. Отдельно разберите заказ, который недавно пришлось исправлять.
Согласуйте значение ключевых состояний. Для продаж «передано» может означать отправленное сообщение, для производства — проверенный состав. Зафиксируйте одно определение и событие, которое его подтверждает. Иначе новая система лишь ускорит появление спора.
Границу первой версии сформулируйте прямо: сервис проверяет полноту заказа и передаёт его диспетчеру; расчёт производственной мощности остаётся в действующей системе. Укажите также владельца решения по спорным правилам. Иначе автор задания вынужден будет выбирать их самостоятельно.
Опишите потребность и заполните сценарий
Свяжите роль с результатом: «Диспетчер получает проверенный состав заказа, чтобы начинать подготовку без повторного запроса спецификации». Затем раскройте условия и исключения. Одна фраза о потребности задаёт смысл, но не заменяет сценарий и проверку.
Для рабочего обсуждения дополните её конкретной карточкой:
- Сценарий: ORD-03, передача заказа в производство.
- Участник: менеджер продаж, отвечающий за заказ.
- Исходное состояние: заказ № 047 находится в статусе «Подготовка».
- Данные: изделие К-12, количество 80 штук, согласованная редакция спецификации 3.
- Действие: менеджер отправляет заказ диспетчеру.
- Проверки: количество положительное, спецификация приложена, ответственный указан.
- Результат: заказ получает статус «На проверке», диспетчер видит его в очереди.
- Подтверждение: сохраняются отправитель, время и редакция переданного состава.
Последний пункт отвечает на вопрос, с чем именно начал работать следующий участник. Дальше нужно решить, разрешены ли изменения после передачи. В нашем примере менеджер создаёт запрос изменения, а исходная редакция остаётся доступной. Это выбранное бизнес-правило, которое команда должна подтвердить, а не универсальное требование ко всем системам.
Зафиксируйте смысл данных и допустимые переходы
Поле «Дата» бесполезно без определения. Это желательная дата клиента, обещанный срок отгрузки или внутренний срок подготовки? В словаре данных укажите смысл, источник, обязательность, формат и роль, которая вправе менять значение. Для количества нужны единица измерения и допустимая точность. Для справочника изделий — ответственный за создание новых позиций.
Опишите статусы через условия перехода. Например, из «На проверке» диспетчер переводит заказ в «Принят» либо возвращает «На уточнение» с обязательной причиной. Менеджер не может самостоятельно поставить «Принят». Отмена уже принятого заказа требует отдельного согласованного действия.
Для обмена с другой системой укажите владельца каждого факта, направление передачи и подтверждение обработки. При задержке сотрудник должен видеть состояние данных и допустимое действие. Например, неподтверждённое наличие нельзя показывать как разрешение запуска заказа.
Добавьте исключения до начала разработки
Обычный сценарий показывает желаемый путь. Исключения выявляют требования, которые чаще всего остаются за кадром. Для условного заказа подготовьте несколько отдельных проверок.
- Нет спецификации. Отправка не выполняется, система объясняет причину, введённые данные остаются в черновике.
- Два сотрудника редактируют заказ. Второй видит, что данные изменились, и не перезаписывает чужое изменение без предупреждения.
- Ответ сервера потерян. Повторная отправка того же действия не создаёт второй производственный заказ.
- Нет права передачи. Пользователь получает отказ; изменение состояния не происходит.
- Диспетчер вернул заказ. Менеджер видит причину и понимает, что исправить перед повторной передачей.
Поведение при сбое должно быть наблюдаемым. «Обработать ошибку» недостаточно: надо указать, что увидит человек, сохранится ли его работа и где появится задача на восстановление процесса.
Превратите описание в критерии приёмки
У каждого сценария должен быть заранее подготовленный набор данных. Проверка «покажите работающую передачу» слишком свободна: демонстратор выберет удобный случай. Проверка на согласованном заказе позволяет сопоставить ожидание с результатом.
Дано: менеджер открыл заказ № 047 без спецификации. Когда он нажимает «Передать», статус остаётся «Подготовка», карточка не появляется в очереди диспетчера, пользователь видит сообщение о недостающем документе. После добавления спецификации повторная передача создаёт одну запись в очереди.
Отдельно запишите требования к скорости и нагрузке. Вместо «система должна работать быстро» договоритесь о конкретном измерении: например, открытие списка из 10 000 тестовых заказов за согласованное время при 20 одновременных пользователях. Числа здесь иллюстративные; реальные значения выбирают по рабочей нагрузке и условиям эксплуатации.
Мини-шаблон проверки можно копировать для каждого сценария:
- идентификатор требования и ответственный за его принятие;
- роль и исходное состояние;
- тестовые данные;
- действие пользователя;
- ожидаемые изменения и сообщение;
- запрещённые последствия;
- способ проверки и фактический результат.
Проведите короткую проверку задания с будущими пользователями
До передачи документа в разработку попросите сотрудника объяснить по нему обычный заказ и один сбой. Если для ответа требуется новая договорённость, зафиксируйте её в сценарии. После согласования сохраняйте версию задания, дату и причину изменения. При изменении правила проверяйте связанные сценарии, данные и критерии приёмки.
Соберите итоговый пакет из карты процесса, словаря данных, сценариев, правил доступа и набора приёмочных примеров. Экраны и макеты приложите к соответствующим действиям. Такой документ помогает выяснить, сможет ли команда закончить свою работу, ещё до того, как появится готовый интерфейс.
Следующий шаг
Возьмите один обезличенный заказ и заполните карточку сценария: роль, исходные данные, действие, результат и три исключения. Попросите будущего пользователя пройти её без устных пояснений. В ExtentLab этот пример поможет обсудить первую версию и критерии её приёмки.