Роли, сценарии, данные, интеграции и критерии приёмки. Структура понятного задания и короткий шаблон для заказчика цифрового продукта.
Запрос «сделай красивый сервис для клиентов» оставляет слишком много решений на усмотрение исполнителя и модели. Чтобы ИИ-разработка приводила к нужному результату, важнее описать правила работы продукта, чем подобрать длинный промпт. Ниже — практическая структура задания, которую можно подготовить без технического образования.
1. Опишите проблему обычными словами
Начните с того, что происходит сейчас. Например: «Заявки приходят в мессенджер, оператор переносит их в таблицу, руководитель вечером уточняет статусы. Иногда одна заявка учитывается дважды». Это учебный пример, но по нему уже видно, что будущему сервису нужны единый реестр, назначенный ответственный и история изменений.
Фраза «нужна CRM с современным дизайном» не даёт такого понимания. Она называет класс программы, но не объясняет, какую работу следует облегчить. Укажите, кто сталкивается с проблемой и как выглядит удовлетворительный результат.
2. Назовите роли и их полномочия
Не ограничивайтесь словом «пользователь». Клиент, оператор, исполнитель и администратор могут видеть разные данные и выполнять разные действия. Для каждой роли опишите три группы возможностей: просмотр, изменение и подтверждение.
- Клиент видит собственные заявки и добавляет комментарий.
- Оператор создаёт заявку и назначает исполнителя.
- Исполнитель обновляет статус назначенной работы.
- Руководитель просматривает сводку и историю действий.
Уточните, что должно быть запрещено. Например, исполнитель не должен получать чужую заявку через прямую ссылку. Скрытая кнопка в интерфейсе сама по себе не описывает правило доступа к данным.
3. Запишите сценарий от начала до результата
Хороший сценарий имеет условия, действие и наблюдаемый итог. «Оператор открывает форму, заполняет обязательные поля, сохраняет заявку и получает её номер. После обновления страницы заявка остаётся в списке». Такой текст можно использовать при разработке и затем при приёмке.
Отдельно опишите отклонения: обязательное поле пустое, контакт введён неверно, связь с внешней системой пропала, пользователь нажал кнопку дважды. Именно в этих местах часто обнаруживаются различия между ожидаемым и реализованным поведением.
4. Укажите данные и источник истины
Для каждого важного поля достаточно знать его смысл, обязательность и происхождение. Статус заявки хранится в новом сервисе или берётся из CRM? Номенклатуру редактируют вручную или импортируют из учётной системы? Кто отвечает за актуальность контактных данных?
Если две системы меняют одну сущность, нужно договориться о правилах синхронизации. Фраза «интеграция с CRM» слишком общая: перечислите, какие данные передаются, в какую сторону и что делать при неуспешной передаче. Подробный технический контракт подготовит разработчик, но бизнес-правила должен подтвердить заказчик.
5. Обозначьте границы первой версии
Разделите требования на обязательные для запуска и последующие. В отдельный список вынесите то, что сознательно не входит в проект. Например: первая версия работает только с одним подразделением; автоматическое распределение заявок появится позже; данные за прошлые годы пока не переносятся.
Это помогает оценивать изменения. Новая функция может быть хорошей идеей, но она всё равно меняет объём работ. Список границ защищает совместное понимание результата и позволяет честно пересматривать сроки.
6. Сформулируйте критерии приёмки
Критерий должен допускать проверку. Вместо «удобная форма» напишите: «Поля имеют подписи; при ошибке видно, что исправить; корректно заполненные значения сохраняются; после отправки показан дальнейший шаг». Вместо «работает на мобильных» перечислите основные сценарии, которые нужно пройти на телефоне.
Для производительности и нагрузки согласуйте конкретное окружение, объём данных и ожидаемое поведение. Не стоит переносить произвольные показатели из чужого проекта: они могут не соответствовать вашей задаче.
7. Договоритесь о передаче и эксплуатации
В задании должны быть исходники, инструкция запуска, список внешних зависимостей и порядок получения доступов. Уточните, кто оплачивает хостинг и API, где хранятся настройки и кто разбирает ошибки после публикации.
Если ИИ встроен в сам продукт, дополнительно опишите допустимые ответы, контроль качества и действия при недоступности модели. Если ИИ используется только для написания кода, эти требования могут не понадобиться. Это разные виды проекта, и смешивать их при оценке не следует.
Шаблон на одну страницу
- Проблема: что неудобно сейчас и для кого.
- Результат: какую работу должен выполнять продукт.
- Роли: кто видит и изменяет данные.
- Сценарии: основной путь и важные ошибки.
- Данные: источники, обязательные поля, интеграции.
- Границы: что входит в запуск и что отложено.
- Приёмка: как проверяем готовность.
- Передача: код, инструкция, доступы и сопровождение.
Не обязательно готовить подробный документ самостоятельно. Для начала достаточно описания текущего процесса и примеров. В FOCUS-group поможем превратить их в объём ИИ-разработки. А если интерфейс уже существует, UX/UI-аудит поможет понять, какие требования к его улучшению действительно нужны.