В техническом задании написано: «Пользователь может отменить заказ». Разработчик добавил кнопку. Менеджер нажал ее после отгрузки. Склад уже передал товар перевозчику, а в личном кабинете заказ стал отмененным.
Кнопка работает. Правило бизнеса осталось за пределами документа.
Такую неоднозначность дешевле найти до оценки разработки. Проверка ТЗ начинается с простого действия: выберите одну операцию и пройдите ее от лица пользователя, сотрудника и внешней системы. На каждом шаге уточняйте, что должно произойти и как вы это увидите при приемке.
Ниже — учебный портал для дилеров: каталог, персональные цены, скидки и передача заказа в учетную систему. Это пример требований, не спецификация готового продукта.
Опишите первый законченный сценарий
«Вход, каталог, корзина, интеграция» — перечень частей. Чтобы оценить работу, подрядчику нужен путь между ними.
Дилер входит под своей учетной записью, видит согласованный прайс, добавляет товар и отправляет заказ. Если нужна нестандартная скидка, заявку получает менеджер. После согласования заказ передается в учетную систему. Дилер видит подтвержденный номер и статус.
Теперь можно задать ограничения первой версии. Работаем с одним юридическим лицом продавца и одной учетной базой. Историю заказов за прошлые годы не переносим. Оплату внутри кабинета пока не принимаем.
Эти границы должны совпадать в описании продукта, макетах и запросе на оценку. Если в макете уже есть оплата, исполнитель закономерно спросит о ней, даже если текст молчит.
Восемь формулировок, которые стоит уточнить
Числа и правила в таблице выбраны для учебного портала. В реальном ТЗ их согласуют с владельцами процесса. Для внешнего API сначала проверяют документацию и тестовый стенд.
| Исходный текст | Риск толкования | Уточненное требование и проверка | Кто дает исходные данные |
|---|---|---|---|
| «Каталог быстро загружается» | Непонятны объем, нагрузка и момент завершения | Для набора в 20 000 товаров и 50 одновременных сессий 95% открытий первой страницы укладываются в 2 секунды на согласованном стенде и сети. Приемка — сценарный нагрузочный прогон от запроса до отображения | Владелец продукта и ответственный за инфраструктуру |
| «Показывать индивидуальные цены» | Общий прайс может попасть клиенту с особыми условиями | Цена берется из привязанного к компании прайса; при отсутствии цены заказ по позиции заблокирован. Проверка — две компании с разными ценами и позиция без цены | Коммерческий отдел |
| «Менеджер согласует скидку» | Скидку меняют после согласования или согласует чужой менеджер | Согласование доступно назначенному менеджеру; изменение состава или цены возвращает заказ на согласование. Проверка — изменение уже согласованного заказа | Руководитель продаж |
| «Обмениваться заказами с учетной системой» | Отправку приняли за подтвержденный заказ | Статус «Принят» появляется только после получения номера из учетной системы. Проверка — успешный обмен и отказ внешней системы | Владелец интеграции |
| «При ошибке повторить отправку» | После потери ответа создается дубль | Одна операция имеет постоянный идентификатор; после неизвестного результата сначала восстанавливается ее статус. Проверка — внешняя система создала заказ, но ответ потерялся; повтор не создает второй | Владелец интеграции и разработчик API |
| «Пользователь может отменить заказ» | Отмена в портале расходится с отгрузкой | До подтверждения отмена завершает локальный заказ; после подтверждения становится запросом менеджеру. Отгруженный заказ автоматически не отменяется. Проверка — каждый из трех статусов | Продажи и склад |
| «Каждый видит свои заказы» | Доступ ограничен только списком на экране | Принадлежность компании проверяется сервером при чтении, изменении и выгрузке. Проверка — чужой идентификатор в прямом запросе; данные не раскрываются | Владелец продукта и ответственный за доступы |
| «Уведомлять об ошибках» | Показывается сообщение, которое никто не может обработать | Пользователь видит статус и номер обращения; ответственный — запись с идентификатором операции и причиной. Проверка — сбой API, попадание события в журнал и очередь разбора без паролей и токенов | Поддержка и владелец интеграции |
Последняя колонка нужна для сроков. Даже сильная команда разработки не может утвердить правила скидок за коммерческий отдел. Если владелец данных не назначен, вопрос способен остановить работу уже после подписания договора.
Разберите одну ошибку до конца
Повторная отправка выглядит технической мелочью. На деле в ней встречаются интерфейс, бизнес-правило и возможности внешней системы.
Пользователь нажал «Отправить». Учетная система создала заказ, но соединение оборвалось до ответа. Портал не знает, что случилось. Если он просто отправит те же данные еще раз, может появиться второй заказ.
Нужно заранее определить, как распознать уже выполненную операцию. Поддерживает ли внешняя система уникальный идентификатор? Можно ли запросить статус? Что увидит пользователь, пока результат неизвестен?
Даже стандарт HTTP отдельно ограничивает автоматический повтор неидемпотентных запросов: для него нужно основание считать повтор безопасным или знать, что исходная операция не была выполнена. Одного слова «API» в ТЗ недостаточно.
Если внешний сервис таких возможностей не дает, вопрос остается открытым до технической проверки. Не записывайте в требования гарантированное поведение, которое пока нечем обеспечить. Согласуйте ручное восстановление статуса или другой способ обмена.
Свяжите требование со способом приемки
Для обязательных функций заведите простой реестр: номер требования, сценарий, тестовые данные, ожидаемый результат, строка оценки и ответственный за приемку.
Например: «Требование 5 — повтор после потери ответа; тестовые данные — один заказ с постоянным идентификатором; результат — одна запись во внешней системе; работа — механизм сверки статуса в интеграции; приемка — владелец обмена».
Так можно обнаружить два разных пробела. Функция есть в ТЗ, но отсутствует в оценке. Или разработка оценена, но никто не определил, как проверить завершение.
Не все приемочные условия требуют числа. Запрет доступа к чужому заказу проверяется конкретным действием. А обещание «удобного интерфейса» придется разложить на сценарии и согласование прототипа: одного субъективного прилагательного для приемки мало.
Подрядчики должны оценивать одну версию
После проверки обновите документ целиком, поставьте дату и коротко перечислите изменения. Передайте всем участникам одинаковые ответы, приложения и тестовые данные, доступные на этом этапе.
Отдельно сохраните список открытых вопросов. Пусть исполнитель укажет, какие из них входят в оценку как допущения и какие требуют предварительной проверки. Тогда сравнение коммерческих предложений не начнется заново с расшифровки разных ожиданий.
Не стоит пытаться описать в ТЗ каждый пиксель будущего интерфейса. Если проект маленький, достаточно короткого согласованного набора сценариев с границами и приемкой. Подробность полезна там, где разные трактовки меняют работу, цену или риск.
Что можно передать на проверку
Если ТЗ уже существует, в MoranaLabs можно заказать его разбор перед оценкой разработки. Мы отметим противоречия, пропущенные сценарии и вопросы к внешним системам, свяжем требования с приемкой и покажем, какие неопределенности влияют на бюджет.
В результате у вас будет документ для рабочего обсуждения с исполнителями. Написание спецификации с нуля, прототипирование и технические эксперименты согласуем отдельно.
В первом сообщении достаточно указать, что разрабатываете и когда собираетесь запрашивать оценки. Проверку лучше провести до того, как каждый подрядчик заполнит пробелы по-своему.