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