ТЗ для ИИ-разработки: пять вопросов, которые экономят недели переделок

Анна руководит небольшой торговой компанией. Она написала подрядчику: «Нужен личный кабинет для клиентов». Одна строка, сорок символов. Подрядчик работал с ИИ, и через неделю показал аккуратный кабинет: вход по почте, список заказов, красивая шапка. Анна посмотрела и сказала: «Красиво. А где вход по телефону? Клиенты у нас без почты. И менеджеры должны видеть всё. И заказы из 1С, а не вручную».

Подрядчик не схалтурил. Он построил именно то, что было написано. Разница между «написано» и «имелось в виду» стоила команде ещё пять недель.

В этой статье мы разберём, почему при работе с ИИ эта проблема обострилась, какие вопросы нельзя пропускать и как выглядит спецификация, на которую можно положиться. Начнём с самой неприятной арифметики.

Почему ИИ делает цену неточного ТЗ выше

Раньше разработка занимала месяцы, и неточности всплывали по пути: вопросы возникали, пока писали код, заказчика дёргали, формулировки уточнялись. Растянутый процесс сам собой исправлял часть ошибок.

С ИИ код появляется за дни. Чтобы увидеть, как это меняет картину, подвигайте ползунок: на каком этапе обнаружилась ошибка в требованиях?

Выводы два. Первый: ИИ ускоряет не только хорошие решения, но и ошибочные. Второй: точка, где дешевле всего поймать ошибку, остаётся той же самой: до написания кода, на этапе идеи и спецификации. Именно туда и надо переносить усилия.

Одна фраза, три разных продукта

Чтобы почувствовать, насколько расплывчата фраза «личный кабинет», посмотрите, какие продукты из неё можно построить. Все три ответа формально правильные.

Видите, как расходятся эти три? Они отличаются по срокам, стоимости и по тому, кого придётся подключать (бухгалтерию, юриста, интеграторов 1С). И всё это скрыто в сорока символах брифа.

Как работает разработка по спецификации

Подход, который решает проблему, называют spec-driven development, то есть разработкой по спецификации. Идея простая: сначала фиксируют, что должно получиться, в виде короткого понятного документа. Потом ИИ-агент строит код по этому документу, а проверяют результат по критериям приёмки из него же. Спецификация становится источником правды, а не устный разговор.

Есть и готовые инструменты под этот подход (например, открытый набор Spec Kit от GitHub), но суть не в них. Достаточно текстового файла в репозитории, который читают и люди, и агенты. Связь с темой про окно контекста прямая: спецификация это постоянный слой знаний о проекте.

Конструктор: соберите кабинет по требованиям

Теперь самое интересное. Слева переключатели: что вы выяснили у заказчика. Справа экран кабинета, который собирается под ваши ответы. Пока ответы неизвестны, на экране остаётся то, что ИИ построил бы «по умолчанию», а пунктирные плашки показывают, во сколько обойдётся сюрприз. Попробуйте выяснить всё.

Три вещи, которые стоит заметить. Во-первых, каждое требование меняет архитектуру, а не картинку. Вход по телефону, роли, интеграция с 1С, хранение в РФ и оплата тянут за собой разные части системы. Во-вторых, косметика действительно дешёвая: тёмная тема, цвет кнопок и язык меняют внешний вид и больше ничего. Именно поэтому про них можно спрашивать последними. В-третьих, пять вопросов, которые вскрывают скрытое, укладываются в получасовой разговор.

Пять вопросов, которые нельзя пропускать

Конструктор выше построен на пяти вопросах. Разберём каждый подробнее: что спросить, почему это решает и где обычно спотыкаются.

1. Как клиенты входят? Спросите не «нужна ли авторизация», а «что есть у клиента под рукой». Если у аудитории нет почты или она ею не пользуется, вход по телефону и коду определяет весь дальнейший дизайн. Типичная ошибка: решить за заказчика («все же пользуются почтой»).

2. Кто ещё работает в системе? Скрытая вторая роль встречается постоянно. Менеджер, который должен видеть всех клиентов и действовать от их имени, превращает простой кабинет в систему с правами, журналом действий и вопросами безопасности. Спросите: «Кто, кроме клиента, будет туда заходить и что ему можно?»

3. Откуда берутся данные? Если ответ «из 1С» или «из CRM», то кабинет перестаёт быть самостоятельным продуктом и становится окном в чужую систему. Главная работа переезжает в интеграцию, а у неё свои сроки: нужен доступ, документация, тестовая среда. Спросите: «Кто источник правды и как часто данные обновляются?»

4. Где можно хранить данные? Для персональных данных граждан России действуют требования закона, они влияют на выбор хостинга и всей инфраструктуры. Поздно выяснять это после запуска. Спросите: «Какие данные о клиентах мы храним и есть ли отраслевые ограничения?» Если сомневаетесь, привлеките юриста на этом шаге: час консультации дешевле переезда.

5. Нужны ли платежи? Оплата тянет за собой чеки, возвраты, статусы, сверку и тесты. Это не «кнопка», а целая подсистема. Спросите: «Что должно случиться, когда клиент нажал “оплатить”, и что, если платёж не прошёл?»

Слова-ловушки в брифе

Вот формулировки, за которыми обычно прячутся неизвестные. Встретив такую в брифе, не соглашайтесь, а расшифровывайте.

• «Простой». Простой для кого и в чём? «Простой кабинет» с оплатой и ролями не простой.
• «Как у конкурентов». У конкурентов может быть то, чего вы не видите: интеграции, процессы, команда. Попросите ссылки и конкретные экраны.
• «Удобный» и «современный». Это оценки, а не требования. Замените критерием: «клиент находит свой заказ за два нажатия».
• «Быстро». Быстро в секундах отклика, в днях разработки или в числе кликов? Каждый вариант измеряется по-своему.
• «И так далее». Всё, что скрывается за этими словами, будет добавлено позже и без оплаты. Попросите перечислить.
• «Интеграция с нашими системами». Каждая система отдельная работа. Выпишите их списком и узнайте, есть ли у каждой документация.

Как выглядит кусок настоящей спецификации

Чтобы это не звучало абстрактно, вот фрагмент спецификации для того самого кабинета. Он короткий, но по нему можно писать код и можно проверять результат.

## Вход
- Клиент входит по номеру телефона, код приходит по СМС.
- Email необязателен. Пароля нет.
- Менеджер входит по корпоративной почте через SSO.

## Роли
- Клиент: видит только свои заказы и счета.
- Менеджер: видит заказы всех клиентов, может создать обращение от имени клиента.
- Каждое действие менеджера от имени клиента попадает в журнал.

## Данные
- Заказы читаются из 1С, обновление не реже раза в 5 минут.
- Кабинет ничего не пишет в 1С, кроме статуса «клиент подтвердил».

## Критерии приёмки
- Клиент входит за 3 шага и видит свои заказы за 2 секунды.
- Клиент не может увидеть чужой заказ ни по ссылке, ни по перебору номера.
- Данные хранятся на серверах в РФ.

Обратите внимание на последний блок. Каждый пункт можно превратить в проверку, ручную или автоматическую. Если пункт нельзя проверить, он не критерий.

Что должно быть в спецификации

Спецификация на пару страниц, как правило, закрывает пять блоков. Листайте карточки.

Как провести разговор за один вечер

Брифинг не требует недели совещаний. Его можно провести за вечер, если идти по порядку.

Что ИИ может сделать для самого брифинга

Хорошая новость: ИИ можно привлечь и на этом этапе. Не как замену разговору, а как помощника: он умеет по короткому брифу составить список уточняющих вопросов, найти противоречия между пунктами и предложить типовые сценарии, о которых вы забыли. Но у такого помощника есть обратная сторона. Он охотно достроит недостающее правдоподобными допущениями и не скажет, что это была догадка. Поэтому правило такое: все допущения, которые он сделал, выписываются отдельным списком и подтверждаются у заказчика.

Если заказчик не знает ответов

Бывает, что на вопрос «откуда данные» заказчик отвечает «не знаю, наверное, из 1С». Это нормально, и это не повод останавливаться. Варианты действий такие.

Выяснить за пределами разговора. Спросить у человека, который знает: бухгалтера, ИТ-специалиста, администратора системы. На это уходит день, а не неделя.

Зафиксировать допущение. «Предполагаем, что данные лежат в 1С версии такой-то, доступ через такой-то интерфейс. Подтвердить до такого-то числа.» Допущение записано, у него есть владелец и срок. Оно перестаёт быть скрытым риском и становится управляемым.

Заложить гибкость. Если неизвестно, как будут входить пользователи, можно отделить вход от остальной системы так, чтобы смена способа не ломала остальное. Это стоит чуть больше времени сейчас, но страхует от дорогой переделки.

Не начинать с самого рискованного. Если от ответа зависит основа системы, лучше сначала сделать небольшой пробный кусок и проверить на нём главную неизвестную: например, получить тестовые данные из 1С и убедиться, что формат подходит.

Что ещё часто забывают

Помимо пяти вопросов из конструктора, в брифах регулярно не хватает ещё нескольких вещей. Кто будет поддерживать продукт после запуска и кто отвечает за данные. Какие объёмы ожидаются: сто пользователей и сто тысяч требуют разных решений. Какие есть требования к доступности: можно ли остановить систему на ночь. Как будет устроена миграция существующих данных, если они есть. Кто принимает работу и по каким критериям. Эти вопросы не обязательны для каждого проекта, но их полезно хотя бы проговорить.

Что сделать до начала следующего проекта

1. Не принимайте бриф из одной строки. Договоритесь о получасовом разговоре по пяти блокам выше.
2. Попросите записать допущения отдельным списком. Особенно те, что сделал ИИ.
3. Положите спецификацию в репозиторий, рядом с кодом. Пусть будет единым источником правды.
4. Для каждого главного сценария зафиксируйте критерий приёмки, который можно проверить.
5. Договоритесь, как вы будете менять спецификацию: через документ, а не через устные «а давайте ещё».

Какой объём реально поместить в первую версию, мы разбирали в статье про MVP за 2–4 недели. А если вы выбираете между подрядчиком, наймом и ИИ, посмотрите честное сравнение.

Источники и что почитать

• GitHub: Spec-driven development with AI — введение в подход и открытый набор инструментов.
• Martin Fowler: Understanding Spec-Driven-Development — трезвый разбор возможностей и ограничений подхода.
• Anthropic: Claude Code best practices — как ставить задачи агенту и организовывать работу.

---

Пишу из практики студии MKDGRUPP: перед стартом проводим разбор и фиксируем ТЗ, модель данных и критерии приёмки, а КП с дизайн-концептом присылаем за час. Подробнее про запуск продукта: mkdgrupp.ru/uslugi/mvp.