Сбор требований и разработка от спецификации (SDD)
В блоке 03 я говорил, что при разработке от спецификации работа руководителя смещается с проверки кода на проверку постановки задачи. Этот блок о том, как ИИ меняет сам сбор требований, от бизнес-формулировок до внутренних процессов, а также о том, где он помогает и где создаёт иллюзию работы.
Вы отвечаете за то, как в команде ставятся задачи. Дальше о том, что меняется в работе с требованиями, когда их читает не только человек, но и модель, и какие поля спецификации нельзя оставлять пустыми.
Сбор требований
В блоке 03 я говорил, что при разработке от спецификации работа руководителя смещается с проверки кода на проверку постановки задачи. Этот блок о том, как ИИ меняет сам сбор требований, от бизнес-формулировок до внутренних процессов, а также о том, где он помогает и где создаёт иллюзию работы.
С бизнес-требованиями ИИ хорошо делает 3 вещи. Во-первых, он превращает запись встречи или переписку с заказчиком в структурированный документ: цели, ограничения, открытые вопросы. Во-вторых, он находит противоречия и пробелы: «в пункте 3 сказано одно, а в пункте 7 другое, при этом не описано, что происходит при ошибке оплаты». В-третьих, он генерирует вопросы для заказчика, которые аналитик мог забыть.
Главное ограничение ИИ: он не знает вашего бизнеса и не отличит важное требование от второстепенного, поэтому расстановка приоритетов остаётся за человеком. Есть ещё одна ловушка: документ, сгенерированный ИИ, выглядит законченным и убедительным, даже если наполовину выдуман из общих соображений. Отсюда правило: всё, что модель написала о вашем бизнесе, проверяется у заказчика.
ИИ полезен как собеседник при проектировании: он может описать варианты, перечислить компромиссы, напомнить про известные подводные камни. Ещё он полезен как генератор архитектурной документации по существующему коду, особенно для легаси, где документации нет.
Архитектурное решение при этом принимает человек, и на это есть основание в данных: в исследовании METR опытные разработчики в знакомой кодовой базе работали с ИИ медленнее. Одна из вероятных причин, по мнению авторов, – модель не знала неявных договорённостей проекта. Архитектура как раз и состоит из таких договорённостей. Выход в том, чтобы записать их явно в файлы контекста (блок 15), тогда генерация кода и обсуждение архитектуры с моделью становятся осмысленными.
Спецификация для ИИ отличается от спецификации для человека одним: человек домыслит недостающее, а модель либо не домыслит, либо домыслит непредсказуемо. Поэтому спецификация должна явно содержать то, что для коллеги подразумевалось бы.
Минимальный состав такой: что сделать и зачем, где в коде это находится, какие есть ограничения (производительность, совместимость, безопасность), как проверить, что сделано правильно (желательно в виде тестов или критериев приёмки), чего делать нельзя (не трогать такие-то модули, не менять публичный интерфейс).
Инструменты разработки от спецификации (Spec Kit, Kiro, OpenSpec из блока 03) предлагают свои форматы. В Kiro требования записываются в нотации EARS (Easy Approach to Requirements Syntax, простой способ формулировать требования: набор шаблонных фраз вроде «когда X, система должна Y»). В OpenSpec каждое изменение живёт в своей папке: предложение, задачи, изменения спецификаций и, если нужно, проектирование, а требование пишется одной фразой со словом SHALL («система должна») и сценариями вида WHEN/THEN («когда пользователь нажимает X, тогда система делает Y»); после внедрения папка уходит в архив, а спецификации системы обновляются. Шаблон спецификации лежит в блоке 15.
То, что должно быть в спецификации для существующего кода и чего нет в большинстве шаблонов, я вынес в собственный инструмент Brownspec из блока 03. Вы можете пользоваться им бесплатно. В него входят: не-цели, то есть соседние вещи, которые изменение намеренно не делает; поведение при отказах, то есть что происходит, когда каждая зависимость медленная, недоступная или отвечает неверно; влияние на контракты (кто сломается и как мигрирует); критерии приёмки как наблюдаемые факты, которые проверит человек, не писавший код; отвергнутые альтернативы, чтобы спор не начался заново через 3 месяца. Спецификация, которая пересказывает код, превращается в мёртвый груз: она устаревает за спринт и уносит с собой доверие команды. Спецификация должна записывать то, чего код сказать не может.
Важный организационный момент: хорошая спецификация пишется дольше, чем плохая. Если команда привыкла ставить задачи 2 строчками в трекере, то переход на спецификации меняет сам процесс, одной сменой инструмента он не ограничивается, поэтому вводить его нужно осознанно.
спецификацию пишет аналитик, а критерии приёмки подписывает тот, кто принимает код; порог «что идёт через спецификацию» фиксируется в файле контекста и один для всех команд.
спецификацию пишет сам инженер за 15–20 минут по шаблону из блока 15; это дешевле, чем переделывать. Аналитика может не быть вовсе, тогда роль заказчика играет продукт-менеджер или основатель, и его подпись под критериями приёмки – единственная защита от выдуманных требований.
В корпорации требования приходят от бизнеса и из других мест: есть регламенты, согласования, ограничения ИБ, стандарты кодирования. Раньше эти знания жили в головах и в разрозненных документах, поэтому новый сотрудник узнавал их через ошибки.
ИИ делает эти знания рабочим инструментом, но только если они записаны. Соберите регламенты, стандарты и типовые решения в файлы контекста, тогда модель будет применять их автоматически: правильный формат логов, принятые библиотеки, обязательные проверки. Есть побочный эффект: вы впервые обнаружите, что часть регламентов противоречит друг другу или устарела. Это полезная находка, хоть и неприятная.
Вайбкодинг – что это?
Вайбкодинг (vibe coding) – способ писать программы, когда человек описывает задачу словами, ИИ генерирует код, а результат принимают без детального ревью. Для прототипов он подходит. В команде с продакшеном вместо него работают от спецификации и с обязательным ревью.
Что такое spec-driven development?
Разработка от спецификации (spec-driven development, SDD) – подход, при котором сначала пишут спецификацию: что сделать, ограничения, критерии приёмки, – и только потом ИИ генерирует код. Агент выполняет ровно то, что написано, поэтому качество спецификации определяет качество кода.
Что говорят коллеги
Даниил и Мария о том, кто в их компаниях пишет спецификации и что из этого вышло.
С тем, что модель не домыслит, согласен полностью: у нас половина требований хранится в регламентах, которые никто не читает целиком. Но в банке нельзя просто собрать регламенты в файлы контекста. Сначала ИБ спросит, какие из них можно отдавать модели, потом юристы спросят, какие из них вообще действуют. Я бы начинал с этой инвентаризации и только после неё брался за спецификации, иначе модель будет применять устаревшее правило. И ещё: по моему опыту, чем больше правил мы положим в контекст, тем хуже модель их соблюдает: на десятках правил она начинает терять одни и путать другие. Поэтому даже после инвентаризации в файл контекста пойдут 10–20 правил, которые нарушают чаще всего, а остальное останется по ссылке и в проверках конвейера. Баланс между «модель не знает правила» и «модель тонет в правилах» придётся искать руками.
Про иллюзию работы в блоке сказано точнее всего. В первый год мы получили красивые документы от модели и пропустили 2 выдуманных требования, которых заказчик никогда не называл. Теперь правило простое: всё, что модель написала о бизнесе, подтверждает заказчик, а спецификацию пишет тот инженер, который потом примет код. Аналитик помогает, но писать за инженера не должен, иначе ответственность размывается.
Обсуждение:
Спецификация под свой проект
Возьмите 1 реальную задачу из ближайшего спринта и опишите её по шаблону из блока 15. Промпт добавляет к шаблону 2 поля для существующего кода: поведение при отказах и влияние на контракты. Вопросы модели покажут, что она домыслила бы за вас. Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем.
Промпт для документа
скопируйте в свою модельТы – опытный системный аналитик. Помоги мне превратить задачу из трекера в спецификацию, по которой ИИ-агент сможет работать без догадок. Сначала задай 4 вопроса о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Если требования ИБ или регулятора есть, в поле «Ограничения» спроси, какие данные затрагивает задача. Затем попроси текст задачи, как он записан в трекере, и по очереди выясни: - Проект и задача: сервис, номер задачи, короткое название. - Зачем: какую проблему бизнеса или пользователя решаем. - Что сделать: поведение системы по шагам, включая граничные случаи. - Где: модули, классы, таблицы, которые затронуты. - Ограничения: производительность, запреты на изменения схемы, совместимость. - Критерии приёмки: проверяемые условия, лучше с числами. - Чего не делать: что агенту нельзя трогать. - Поведение при отказах: что происходит, если зависимость медленная, недоступна или отвечает неверно. - Влияние на контракты: кто из потребителей заметит изменение и что им нужно сделать. - Открытые вопросы: что не решено и к кому вопрос. Ищи решения, которые модель иначе приняла бы сама: часовой пояс, обработка ошибок, что попадает в журнал, что считать, а что нет. Задай не больше 5 таких уточняющих вопросов, остальное вынеси в «Открытые вопросы». Если я отвечаю «не знаю», тоже записывай вопрос туда и указывай, к кому он. Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: таблица «Поле | Содержание» с 10 полями выше. 8 полей совпадают с шаблоном спецификации (название задачи и 7 разделов), «Поведение при отказах» и «Влияние на контракты» добавлены для существующего кода. Под таблицей – список решений, которые мы приняли явно, хотя в исходной задаче их не было.
ПримерЗаполненная спецификация на реальную задачу
Задача из бэклога банка Даниила, как она выглядела в трекере: «Добавить лимит на количество переводов в сутки». 2 строчки, по которым модель домыслит всё остальное. Та же задача по шаблону:
| Поле | Пример заполнения |
|---|---|
| Проект и задача | transfers-service, TRF-2231 «Суточный лимит на число исходящих переводов» |
| Зачем | Служба антифрода фиксирует схему с десятками мелких переводов с одного счёта в течение часа. Лимит по количеству закрывает схему без снижения лимита по сумме, который задел бы обычных клиентов. |
| Что сделать | При создании перевода проверять число успешных исходящих переводов со счёта за текущие календарные сутки по московскому времени. При превышении лимита (по умолчанию 30, настраивается по тарифному плану) отклонять перевод с кодом ошибки LIMIT_COUNT_EXCEEDED и писать событие в журнал антифрода. |
| Где | Модуль transfers/limits/, класс LimitChecker, вызывается из TransferService.create() после проверки лимита по сумме. Счётчик хранить в той же таблице daily_limits, где уже лежит сумма за сутки. |
| Ограничения | Проверка не должна добавлять больше 20 мс к созданию перевода (сейчас p95 – 180 мс: 95% переводов создаются быстрее). Никаких новых таблиц: миграция схемы требует отдельного согласования. Код ошибки должен быть добавлен в общий справочник errors.yaml. Персональные данные в журнал не пишем, только идентификатор счёта. |
| Критерии приёмки | 1. 30 переводов за сутки проходят, 31-й отклоняется с LIMIT_COUNT_EXCEEDED. 2. Отменённые и отклонённые переводы в счётчик не входят. 3. В 00:00 по Москве счётчик обнуляется, проверено тестом с подменой времени. 4. Для тарифа «Премиум» лимит 100. 5. Событие в журнале антифрода содержит идентификатор счёта, время и текущее значение счётчика. 6. Существующие тесты лимита по сумме проходят без изменений. |
| Чего не делать | Не трогать логику лимита по сумме. Не менять публичный контракт API создания перевода. Не добавлять настройку лимита в клиентское приложение (отдельная задача TRF-2240). Не рефакторить LimitChecker попутно. |
| Поведение при отказах | Если таблица daily_limits недоступна или отвечает дольше 50 мс, перевод отклоняется с кодом TEMPORARY_ERROR: пропустить проверку молча нельзя. |
| Влияние на контракты | Публичный контракт не меняется. Новый код ошибки LIMIT_COUNT_EXCEEDED нужно показать понятным текстом в мобильном приложении и веб-банке (задача команде клиентских приложений). |
| Открытые вопросы | Считать ли переводы между своими счетами клиента? (Вопрос к антифроду, ответ нужен до старта.) Нужно ли уведомление клиенту при достижении 80% лимита? (Вопрос к продукту, можно решить позже.) |
Заметьте, сколько в заполненном варианте решений, которые модель иначе приняла бы сама: часовой пояс, считать ли отменённые, где хранить счётчик, что писать в журнал. Каждое из них без спецификации стало бы замечанием на ревью или дефектом на проде.
Главное из блока: ИИ ускоряет сбор требований, но всё, что он написал о вашем бизнесе, проверяется у заказчика, а спецификация записывает то, чего код сказать не может. Переход на спецификации меняет сам процесс, одной сменой инструмента он не ограничивается. Дальше, в блоке 07, разбирается, что ИИ делает с самим кодом и с каких задач начинать.
Дальше блок 07 «Разработка»: Это первый из блоков про конкретные направления, поэтому здесь важно одно правило: задачи подходят для ИИ в разной степени.
Источники блока
- METR, исследование 2025 года
- Birgitta Böckeler на сайте Мартина Фаулера, обзор Kiro, Spec Kit и Tessl, октябрь 2025
- GitHub, Spec Kit
- OpenSpec, Fission-AI – формат требований и сценариев, структура папки изменения