Кейс: enterprise без отдельных системных аналитиков
Enterprise-команда 25+ инженеров. Внедрили Use Case спецификацию-как-код и AI-скиллы для генерации артефактов и review. Отдел системного анализа расформирован — функция распределена между разработчиками и AI-скиллами.
Контекст
Enterprise-команда, 25+ инженеров. Несколько Java/Spring сервисов, типичная для крупного бизнеса воронка задач:
Бизнес → Системный аналитик → Разработчик → QA → Прод
Отдел системного анализа — 3–4 SA, выделенный team-lead. Каждая фича начинала путь со спеки в Word или Confluence, проходила согласование, передавалась в разработку.
Проблема
Системный анализ стал узким местом. Симптомы:
- Спеки приходили в команду через 2–3 недели после постановки задачи бизнесом, и сразу после согласования начинали устаревать
- Разработчик читал спеку месячной давности, видел, что часть требований изменилась, делал «по своему пониманию»
- Спека и код расходились через месяц после релиза, при следующей доработке спеку приходилось писать заново
- Ни один SA не мог заболеть/уволиться, не парализовав часть бэклога
В сумме команда теряла недели на хэнд-офф и расхождение спеки и кода.
Что внедрили
1. Use Case спецификацию как код в репозитории
Спека на 16 разделов в формате markdown лежит в том же репо, что и код сервиса, в docs/spec/. Изменение спеки и связанного кода — в одном PR. Если спека и код расходятся — это баг, который ловится в обзоре, а не «доработаем потом».
2. AI-скиллы для генерации артефактов из спеки
Для каждой статьи методологии — Claude Code skill, который читает спеку и генерирует:
- API-контракт (OpenAPI) из раздела «Commands»
- Доменные классы (entity, value object) из раздела «Domain Model»
- UseCase + Handler + контроллер из раздела «Use Cases»
Разработчик пишет спеку, нажимает скилл — получает скелет кода. Дальше — реализация бизнес-логики.
3. AI-скиллы для review
ucp-pattern-review, ucp-api-review, ucp-ddd-tactical-review, ucp-java-style-review — каждая PR проходит через них автоматически. Замечания цитируют правила методологии (R-7, JS-2.5, BR-C5).
Результат
- Отдел системного анализа расформирован. Функция распределена: бизнес-постановка → разработчик ведёт спеку сам в формате 16 разделов, AI-скиллы помогают с генерацией и проверкой
- Cycle time от идеи до прода сократился на недели — нет хэнд-оффов
- Спека и код всегда совпадают — иначе PR не пройдёт обзор
- Новый разработчик въезжает за неделю по спеке, не нужны «хранители знаний»
- Бизнес сам читает спеку — она написана структурированно, а не «как Word-документ»
Что было риском, но не сломалось
Когда обсуждали закрытие отдела SA, главное опасение бизнеса: «разработчики не умеют разговаривать с продуктом». На практике оказалось, что формат 16 разделов даёт чёткую структуру для разговора — разработчик не выдумывает с чего начать, а заполняет шаблон. Бизнес читает заполненный шаблон легче, чем свободный Word-документ — потому что заголовки разделов уже знакомы.