Тренд «сбор требований с помощью ИИ» меняет правила игры: теперь черновик ТЗ для разработки можно собрать за 1–3 часа вместо 1–2 недель, что резко снижает стоимость ошибки для новичка, но требует нового навыка — правильно задавать вопросы и проверять факты, а не верить красивому тексту.

Если вы хоть раз видели, как проект горит из‑за фразы «сделайте как в Тинькофф, только попроще», вы уже понимаете, зачем вообще нужен сбор требований. Проблема не в том, что люди «плохо формулируют». Проблема в том, что бизнес и разработка говорят на разных диалектах: один про «чтобы менеджеру было удобно», другой про «какие роли, сценарии, статусы и ограничения».

ИИ тут не волшебная кнопка и не замена аналитика. Это ускоритель: он помогает быстро развернуть хаос в структуру, подсветить дыры, собрать список вопросов к заказчику и набросать каркас ТЗ. А дальше включается взрослая часть: валидация, согласование, приоритизация и фиксация того, что именно будет сделано (и что не будет).

Почему ИИ ускоряет сбор требований, но не отменяет ответственность

Что ИИ делает хорошо: структурирует и провоцирует на конкретику

Тезис: ИИ сильнее всего в «первом проходе»: превратить разговорный запрос в список сущностей, сценариев, правил и вопросов.

Обоснование: на старте проекта 60–80% времени уходит не на «писать документ», а на распаковку: что за пользователи, какие процессы, какие исключения. ИИ быстро предлагает типовую структуру: роли (RBAC), user stories, acceptance criteria (критерии приёмки), нефункциональные требования (NFR: производительность, безопасность, доступность).

Практический вывод: используйте ИИ как «интервьюера», который не стесняется задавать 40 уточняющих вопросов подряд.

Подводный камень: ИИ легко «додумает» бизнес-правила. Если вы не проверили — вы уже согласовали выдумку.

Что ИИ делает плохо: ответственность за факты и контекст

Тезис: ИИ не знает вашей реальности: 1С, регламенты, 152‑ФЗ, интеграции, ограничения инфраструктуры.

Обоснование: в российских проектах «мелочь» вроде «у нас кадровый учёт в 1С:ЗУП» превращается в архитектурное решение и сроки. Точно так же влияет ГОСТ/регуляторика, требования ИБ (информационной безопасности), корпоративные SSO/AD, согласования через СЭД (например, Directum, ELMA365).

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

Подводный камень: «давайте потом уточним» в требованиях = «давайте потом подерёмся по срокам».

Как собрать требования (и использовать AI для требований) — пошаговый рецепт

Шаг 1. Зафиксировать цель и метрики (не «хотелки»)

Тезис: сбор требований начинается не с экранов, а с ответа «зачем».

• Цель: что меняется в бизнесе (скорость обработки заявки, конверсия, снижение ошибок).
• Метрики: чем измерим (SLA, время цикла, доля отказов, NPS, % ручных операций).
• Ограничения: сроки, бюджет, регуляторика, инфраструктура.

Практический вывод: попросите ИИ превратить ваш бриф в «цель → метрика → ограничение» и выдать список недостающих данных.

Подводный камень: «метрика» в духе «чтобы было удобно» — это не метрика.

Шаг 2. Описать пользователей и контекст (персоны + роли)

Тезис: роли и права — это половина системы, особенно в корпоративке.

Обоснование: типичный российский кейс: менеджер видит одно, бухгалтер — другое, служба безопасности — третье. RBAC (role-based access control) надо фиксировать рано, иначе «допилим права» съедает итерации.

Практический вывод: скормите ИИ список отделов/должностей — попросите предложить роли, матрицу доступа и вопросы по исключениям.

Подводный камень: «администратор может всё» без логирования (audit log) — подарок для будущего расследования.

Шаг 3. Собрать сценарии (Use Cases / User Stories) и исключения

Тезис: система — это не «счастливый путь», а обработка исключений.

1. Главные сценарии: создание, изменение, согласование, отмена, поиск.
2. Исключения: нет данных, дубль, конфликт статусов, таймаут интеграции, отказ прав.
3. Состояния: статусы сущностей и переходы (мини-«стейт машина»).

Практический вывод: просите ИИ: «сгенерируй таблицу сценариев + исключений + критерии приёмки» — а потом вы идёте по ней с заказчиком и отмечаете реальность.

Подводный камень: не описали статусы — разработка придумает. И да, придумает не так.

Шаг 4. Данные и интеграции: 1С, CRM, СЭД, платежи

Тезис: интеграции — главный источник скрытых сроков.

Обоснование: «просто выгрузка из 1С» может быть: обмен через COM, web-сервисы, файлы, шина (ESB), регламентные задания, плюс согласование доступов. В CRM (например, Битрикс24) упрётесь в лимиты API и права.

Практический вывод: делайте реестр интеграций: система‑источник, система‑приёмник, формат, частота, SLA, ответственный.

Подводный камень: забыли про миграцию данных (исторические записи) — получите «почему у нас пусто» в день запуска.

Шаг 5. Нефункциональные требования (NFR) — без них ТЗ неполное

Тезис: NFR — это не бюрократия, а защита от сюрпризов.

• Производительность: время ответа, количество пользователей, пики.
• Доступность: окна обслуживания, RTO/RPO (время восстановления/потеря данных).
• Безопасность: 152‑ФЗ, хранение ПДн, журналирование, шифрование, SSO.
• Эксплуатация: мониторинг, алерты, бэкапы, логирование.

Практический вывод: попросите ИИ сформировать чек-лист NFR под ваш тип системы (внутренняя/публичная/финансы/ПДн) и проставьте «есть/нет/нужно уточнить».

Подводный камень: «производительность потом» — это обычно «дорого потом».

Шаблон ТЗ: что должно быть внутри (минимум, который реально работает)

Кейсы из практики: когда ИИ помогает, а когда подставляет

Кейс «ускорили старт в 5 раз» (успешный)

Внутренний сервис заявок для отдела закупок. На входе — один абзац в чате: «нужна форма, согласование, выгрузка в 1С». Мы прогнали это через ИИ как через «пресс» для вопросов: роли, статусы, причины отклонения, SLA, интеграция с 1С:УТ, журналирование. За вечер получили каркас требований, на следующий день — 40‑минутное интервью с заказчиком по списку. Итог: вместо недели «переписки ни о чём» — согласованный документ за 2 дня и понятный бэклог для разработки.

Ошибка, которой избежали: сразу зафиксировали out of scope («не делаем каталог поставщиков в первой версии»), иначе проект бы раздувался как тесто.

Кейс «красивое ТЗ, которое не взлетело» (неудачный)

Личный кабинет для клиентов в B2B. Команда взяла нейро-черновик требований, почти не проверяя интеграции и права доступа. На демо выяснилось: у клиентов сложная иерархия договоров, часть данных только в старой базе, а авторизация через корпоративный SSO с дополнительными шагами согласования. ТЗ было «похожим на правду», но не про эту компанию. Потеряли спринт и доверие.

Корень проблемы: сбор требований без владельцев данных и ИБ — это как проектировать мост без геолога.

Коммерческие факторы: сколько стоит «быстрое ТЗ» на рынке и где скрытая цена

На российском рынке подготовка ТЗ/BRD (Business Requirements Document) и детализация в бэклог обычно оценивается по времени специалистов. Вилка по ощущениям рынка такая: фриланс/небольшие студии часто называют 30–150 тыс. ₽ за небольшой проект, в агентствах и интеграторах легко улетает в 200–600 тыс. ₽, если много интеграций, ИБ и согласований. ИИ снижает затраты именно на черновую работу и «первую структуру», но не отменяет часы интервью, согласований и прототипирования.

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

Экспертный вердикт и инструмент: чек-лист, чтобы ИИ не превратил ТЗ в фанфик

Используйте ИИ для требований как быстрый способ разложить задачу по полкам. Но «сбор требований как собрать требования» на практике решается не промптом, а дисциплиной: источники данных, владельцы процессов, критерии приёмки, границы.

• 5 вопросов к себе перед тем, как нести ТЗ в разработку:
• 1) Могу ли я одной фразой назвать цель и метрику успеха?
• 2) Есть ли список ролей и матрица «роль → действия → данные»?
• 3) Описаны ли статусы и исключения, а не только «счастливый путь»?
• 4) Зафиксированы ли интеграции со всеми ответственными и форматами?
• 5) Есть ли критерии приёмки (AC) и тестовые сценарии, по которым QA (тестировщик) реально проверит?

Если хотите посмотреть похожие разборы практик, инструментов и карьерных стратегий в IT — они лежат на https://itokno.ru (здесь как раз любят конкретику, а не «мы изменим вашу жизнь за 3 дня»).

Частые вопросы