Почти все руководства по сбору требований написаны для бизнес-аналитиков и тестировщиков. Эта статья — для другой стороны: для заказчика, у которого есть идея, нет аналитика в штате и есть задача получить от разработчиков честную оценку, а не вилку «от месяца до года».

Хорошая новость: для этого не нужно осваивать профессию. Нужно ответить на правильные вопросы в правильном порядке.

Почему без требований не бывает честной оценки

Когда исполнитель получает описание из двух абзацев, он оценивает не вашу задачу — он оценивает своё понимание вашей задачи. Чем меньше информации, тем больше в цене заложено риска, а в сроках — запаса.

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

Шаг 1. Опишите проблему, а не решение

Первая ошибка — начинать со слов «нужен сайт с личным кабинетом». Это уже решение. Начните с проблемы:

  • что сейчас происходит и почему это больно;
  • сколько времени или денег на этом теряется;
  • что изменится, когда проблема будет решена.

«Менеджеры ведут заявки в Excel, теряют около 10% обращений и не видят, кто за что отвечает» — этого абзаца полезнее, чем страница про кнопки.

Шаг 2. Перечислите роли и сценарии

Выпишите всех, кто будет пользоваться системой: менеджер, руководитель, клиент, бухгалтер. Для каждой роли — 2-4 главных сценария в формате «кто → что делает → что получает»:

  • Менеджер создаёт заявку и назначает ответственного.
  • Руководитель видит все заявки по статусам и просроченные.
  • Клиент получает уведомление о смене статуса.

Сценарии — это скелет продукта. По ним можно оценивать, проектировать и принимать работу.

Шаг 3. Пройдите путь данных

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

Шаг 4. Отделите обязательное от желательного

Разделите всё, что выписали, на две колонки: без чего первая версия бессмысленна и что можно добавить потом. Это защищает бюджет лучше любого договора: первая версия выходит быстро, а «хотелки» не раздувают смету незаметно.

Шаг 5. Зафиксируйте, что не входит

Самый недооценённый пункт. Одна строка «мобильного приложения в первой версии нет» экономит недели споров. Если границы не записаны, каждая сторона рисует их в свою пользу — обычно уже после подписания сметы.

Чем здесь помогает AI

Всё перечисленное — структурированный разговор, и именно его хорошо ведёт AI. В coob этот процесс встроен в продукт: вы описываете идею своими словами, AI-ассистент задаёт уточняющие вопросы — про роли, сценарии, интеграции и границы — и собирает из ответов продуктовые требования. По ним вы получаете оценку стоимости ещё до старта разработки.

А о том, почему классическое ТЗ на десятки страниц эту задачу не решает, — отдельный разбор.