Внедрение в команде

Процессы не внедряются приказом

Худший способ внедрить SDD — объявить на ретро «теперь всё через спеки» и добавить пункт в Definition of Done. Через месяц спеки будут писаться после кода, задним числом, для галочки — и вы получите worst of both worlds: бюрократию без пользы.

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

Неделя 1–2: пилот

• Один репозиторий, один волонтёр. Не самый сложный сервис и не самый скептичный инженер. openspec init --tools qwen — и три-четыре реальные задачи через полный цикл (часть 4).
• Одна метрика, честная: сколько раз ревью спеки поймало то, что раньше поймали бы на ревью кода или на проде. У «Синтеза» на пилоте — четыре случая за две недели. Эти истории убеждают лучше презентаций.
• Скептиков не агитировать — позвать на ревью одной спеки. Пять строк сценария комментируются охотнее, чем пятьсот строк диффа.

Неделя 3–4: границы

• Поставить store, договориться о правиле размещения (часть 3): спека — где ревью кода, контракт — где его читают все.
• Записать это правило в сам store — как его первую спеку. Мета, но работает: соглашение о процессе тоже требование, и оно тоже дрейфует, если живёт в чьей-то голове.
• Подключить references в репозитории, которые трогают чужие контракты. Не во все сразу — по мере надобности.

Неделя 5–6: гейты

Когда цикл привычен, закрепить его механикой. PR-гейт в каждом репозитории со спеками:

# .github/workflows/specs.yml
name: specs
on: pull_request
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm install -g @fission-ai/openspec@latest
      - run: openspec validate --all

openspec validate проверяет структуру: у требований есть сценарии, формат дельт корректен. Он не проверяет, что код соответствует спеке, — это работа ревьюера и тестов из tasks.md. Гейт дешёвый и не флакает — идеальный кандидат в обязательные.

Конвенция ревью с этого момента: сначала спека, потом код. Если PR меняет поведение, а дельты в openspec/changes/ нет — это вопрос в ревью, не автоматический реджект: у хотфиксов и рефакторингов свои права.

Типовые ошибки — все проверены на себе

Чем это не waterfall — контрольный ответ

К возражению из части 1, теперь с опытом на руках. Waterfall — это фазовые ворота: аналитик написал, разработчик исполнил, возвращаться нельзя, документ мёртв. SDD-цикл — это короткая петля: спека размером с изменение, автор спеки и кода — одна пара «инженер + агент», возврат к артефактам — норма (update as you learn), а после archive спека продолжает жить как описание системы. Общее у них только слово «спецификация».

Что осталось за кадром

• Дисциплина контекста. Чистая сессия агента перед apply; артефакты вместо памяти диалога. Модели меняются — артефакты остаются.
• Headless-режим (qwen -p) — для автоматизаций вокруг процесса: черновик дельты из тикета, сводка активных changes в канал команды.
• Stores — beta. Следите за релизами OpenSpec; форматы могут меняться. Стратегия деградации из части 3 (store = просто git-репо со спеками) — ваша страховка.

Кейс «Синтез», эпилог. Через два месяца Даша заметила побочный эффект, которого не планировал никто: онбординг. Новый инженер в первый день читает openspec/specs/ двух сервисов и store — и задаёт вопросы уровня «почему рефанд-окно 30 дней, а не 14», а не «где у вас что лежит». Спеки оказались документацией, которая не врёт, — потому что процесс обновляет её тем же движением, что и код.

---

Туториал закончен. Порядок действий на понедельник: npm install -g @fission-ai/openspec@latest, один пилотный репозиторий, openspec init --tools qwen, первая настоящая задача через /opsx-propose. Остальное — вопрос шести недель.