Цифровые продукты ·
Техническое задание с ИИ начинается не с промпта
ИИ способен за минуту составить объёмное техническое задание на сайт или приложение. В таком документе будут роли, функции, интеграции и даже рекомендуемый стек. Проблема в том, что убедительная структура ещё не означает понимания задачи. Хорошее ТЗ начинается с решений, которые принял человек, а ИИ помогает сделать их явными и связными.
Сначала нужно описать изменение
Фраза «нужен сайт» сообщает только предполагаемую форму. Она ничего не говорит о том, кто придёт на сайт, что этот человек должен понять или сделать и какой результат получит бизнес. Для приложения вопрос тот же: какую работу оно переносит в новый интерфейс и почему существующий способ больше не подходит.
Начинать полезно с изменения, которое должно произойти. Клиент сможет выбрать услугу без звонка. Сотрудник перестанет переносить данные между таблицей и CRM. Руководитель увидит отклонение до конца месяца. Эта формулировка задаёт границу проекта лучше, чем перечень экранов.
ИИ помогает проверить исходную формулировку: задать уточняющие вопросы, найти неописанного участника и показать, где желаемый результат нельзя проверить. Но ответы должны исходить из реального процесса, а не из наиболее вероятного шаблона модели.
Сценарий важнее списка функций
Перечень «регистрация, личный кабинет, уведомления» выглядит конкретно, хотя не объясняет, как человек достигает цели. Один и тот же личный кабинет может хранить документы, показывать состояние заказа или управлять подпиской. Это разные продукты с разными данными и рисками.
Сценарий связывает пользователя, отправную точку, действие и результат. Что человек знает в начале? Какие сведения вводит? Где выбирает? Что происходит после подтверждения? Как он исправляет ошибку и возвращается к незавершённой задаче? Ответы превращают функцию в наблюдаемое поведение.
ИИ удобно использовать как собеседника, который проходит сценарий по ролям. Он может сыграть нового клиента, опытного сотрудника или администратора и обнаружить пропущенный переход. Найденное предположение затем проверяют с теми, кто действительно будет пользоваться продуктом.
Данные и исключения формируют сложность
Два одинаковых на схеме сайта могут радикально отличаться по устройству. Один показывает заранее подготовленный каталог. Другой рассчитывает персональное предложение, проверяет остатки, создаёт договор и передаёт заказ во внешнюю систему. Внешне это одна кнопка, технически — несколько зависимостей.
Поэтому в ТЗ нужно назвать источник каждого важного значения, владельца данных и ожидаемое действие при ошибке. Что произойдёт, если CRM недоступна? Можно ли повторить платёж? Кто исправит неверный адрес? Какие сведения пользователь вправе удалить? Исключения показывают настоящий объём разработки раньше, чем он проявится в коде.
ИИ может составить перечень пограничных случаев, но не знает внутренние правила компании. Его список служит материалом для разговора, а не готовой политикой продукта.
Ограничения защищают Замысел
ТЗ часто описывает, что система должна делать, и умалчивает, чего она делать не должна. Между тем ограничение помогает сохранить направление. Первая версия работает только с одним типом заявки. Агент готовит ответ, но не отправляет его. Приложение хранит минимум персональных данных. Ручная проверка остаётся обязательной для нестандартной цены.
Такие границы уменьшают число скрытых решений во время разработки. Если ограничение не записано, модель или разработчик выберет правдоподобный вариант самостоятельно. Он может работать технически и при этом противоречить бизнесу, праву или характеру продукта.
Полезно отдельно зафиксировать устройства, языки, доступность, требования к скорости, безопасность и системы, с которыми предстоит работать. Это не приложение к дизайну, а часть формы продукта.
Приёмка должна быть записана до реализации
Фраза «сделать удобный интерфейс» не даёт основания принять работу. Проверяемый критерий описывает условия и наблюдаемый результат: новый клиент отправляет заявку с телефона; менеджер видит её в CRM не позднее чем через минуту; повторная отправка не создаёт дубль; ошибка интеграции остаётся видимой и не теряет введённые данные.
Критерии приёмки полезно писать рядом со сценарием, а не после завершения разработки. Они помогают выбрать размер первой версии, подготовить тестовые данные и отличить готовый путь от красивой демонстрации.
В рамках Метода я использую ИИ для уточнения и проверки ТЗ, но не передаю ему постановку задачи целиком. Замысел задаёт нужное изменение, сценарии описывают путь, ограничения удерживают границы, а критерии приёмки связывают обещание продукта с его реальной работой.
Сайт начинается с задачи
Если вы планируете новый сайт или пересматриваете существующий, начнём с его роли в бизнесе, структуры и пути посетителя к обращению.