От промптов к спекам с AI-агентами

Внедрение SDD в команде с продактом и аналитиком

В предыдущих подмодулях вы прошли весь цикл в одиночку: спека, clarify-цикл, tasks.md, реализация, приёмка. Теперь тот же цикл — в команде, где есть продакт или аналитик со своим взглядом на то, что должна делать фича.

Почему спека кажется бюрократией — и что с этим делать

Первая реакция, когда показываешь коллеге шаблон из шести разделов: «Зачем это писать, если можно объяснить на звонке?» Честный вопрос.

Устное объяснение быстро работает здесь и сейчас. Через три дня разработчик помнит одно, продакт — другое, а агент не помнит вообще ничего. Спека решает именно это: не «задокументировать для порядка», а создать источник правды, который агент читает при каждом запуске.

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

Кто владеет «что» и кто — «как»

В подмодуле 2 мы разделили спеку на «что» (требования) и «как» (дизайн). В команде это разделение становится разделением ответственности.

Продакт / аналитик — владелец разделов «Цель», «Не-цели» и «Требования». Они знают бизнес-контекст, понимают, чего хочет пользователь, и видят, что явно выходит за скоуп. Агент не должен угадывать бизнес-логику — её пишет человек, знающий её изнутри.

Разработчик — владелец «Дизайна», «Граничных случаев» и «Критериев готовности». Он видит технические ограничения стека, понимает, какие edge-кейсы опасны, и знает, как именно проверить, что пункт выполнен.

Разделение не жёсткое. Критерии готовности часто пишутся вместе: продакт знает «что считается успехом», разработчик — «как это проверить». Граничные случаи иногда диктует продакт («а что, если пользователь сделает вот так...»). Но владение однозначное: продакт не трогает «Дизайн», разработчик не меняет «Цель» без обсуждения.

Спека как общий артефакт: в репозитории, как код

Спеки живут в /specs — там, где мы их завели в первом подмодуле. Не в Confluence, не в Notion и не в Jira-описании задачи. Причина проста: агент читает файлы из репозитория. Когда спека в /specs, её можно положить в контекст одной командой — и она всегда синхронизирована с кодом.

Для команды это означает ещё одно: спеку можно ревьюить как код.

Продакт открывает pull request с файлом specs/checkout-flow.md — только разделы «Цель», «Не-цели» и «Требования». Разработчик ревьюит его в обычном PR-интерфейсе, добавляет «Дизайн» и «Граничные случаи» туда же. Clarify-цикл с агентом (как в подмодуле 3) запускается до мерджа. После согласования — мердж.

Это снимает типичную проблему: «мы это обсуждали, но где записано?» Записано в PR-комментариях и в финальном файле в репозитории.

Минимальный командный процесс:

1. Продакт создаёт specs/feature-name.md — Цель, Не-цели, Требования
2. Открывает PR, тегает разработчика
3. Разработчик дополняет Дизайн, Граничные случаи, Критерии готовности
4. Вместе запускают clarify-цикл с агентом — один шарит экран
5. После двух раундов вопросов — merge
6. Разработчик создаёт tasks.md, берёт задачи в работу
7. Приёмка — по критериям готовности из спеки

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

Не начинайте с «у нас теперь новый процесс». Начните с одной фичи.

Выберите задачу, которая достаточно велика, чтобы недопонимание болело, — но не критичную для продакшена. Напишите спеку сами по шаблону из подмодуля 2. Покажите продакту: «Посмотри, правильно ли я понял требования» — и попросите его поправить раздел «Требования». Никакого SDD, никакого процесса. Просто «хочу убедиться, что понял задачу верно».

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

Второй распространённый страх — «это займёт слишком много времени». На практике спека к небольшой фиче пишется за 20–30 минут — ровно столько, сколько уходит на типичную «синхронизацию» в Zoom. Разница в том, что в конце звонка ничего не зафиксировано, а в конце спеки — зафиксировано всё.

Шаблон для команды

Шаблон из подмодуля 2 подходит как основа. Для командной работы добавьте три строки в начало:

# [Название фичи]

**Владелец требований:** @имя-продакта  
**Владелец дизайна:** @имя-разработчика  
**Статус:** черновик | на ревью | согласовано | в работе | готово

## Цель
...

Статус — самый полезный добавок. Когда спек становится больше пяти, «на ревью» или «согласовано» экономит время: не нужно открывать файл, чтобы понять, можно ли уже ставить задачу в tasks.md.

Что не работает

Несколько паттернов, которые кажутся разумными, но ломаются на практике.

Спека как жёсткий блокер. «Разработчик не берёт задачу без финальной спеки» создаёт очереди. Разработчик может начать «Дизайн» параллельно, пока продакт дорабатывает «Требования». Clarify-цикл — когда оба черновика готовы, не раньше.

Спека вне репозитория. Confluence или Notion удобны для людей, но агент туда не смотрит. Дублировать в двух местах — плохо: они неизбежно расходятся. Один источник правды — /specs.

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

Итог курса: что забрать

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

Три вещи, которые работают сразу:

1. CLAUDE.md как постоянный контекст — один раз написать, агент читает при каждом запуске автоматически.

2. Clarify-цикл до кода — правки в тексте дешевле, чем правки в коде.

3. Критерии готовности как договорённость — когда они есть, «готово» означает одно и то же для всех в команде.

Команда подключается без революции: продакт владеет «что», разработчик — «как», спека живёт в репозитории и ревьюится как PR. AI-агент из персонального инструмента становится общим фасилитатором уточнений, когда clarify-цикл запускают вместе — один шарит экран, второй отвечает на вопросы агента.

Начните с одной фичи. Не с процесса.