SDD: спецификация как источник правды до начала разработки

SDD (Spec-Driven Development, Specification-Driven Development) — подход, при котором спецификация создаётся и согласуется до разработки, а затем становится «единым источником правды» для людей, команды и AI-инструментов. IBM определяет SDD как методологию, где детальная спецификация реализации согласуется до начала разработки; Martin Fowler описывает её как documentation-first подход, где спецификация становится источником истины для человека и AI, а код — последним шагом реализации.

Без проработки на старте риски растут экспоненциально: исправление архитектурных ошибок на поздних этапах стоит в 10–100 раз дороже. Проработка помогает заранее увидеть узкие места, расставить приоритеты и сбалансировать компромиссы (скорость vs надёжность, гибкость vs стоимость).

Почему это важно в AI-assisted development

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

AI ускоряет не только разработку, но и ошибки: чем быстрее генерируется код, тем важнее заранее задать ограничения, контекст и правила проверки.

Почему спецификация нужна даже для небольшого изменения

• Любое изменение влияет на систему: интерфейсы, данные, бизнес-процессы, SEO, интеграции, безопасность, поддержку и будущие доработки.
• Устные договорённости быстро расходятся: заказчик, аналитик, дизайнер, разработчик и AI-агент могут понимать одну фразу по-разному.
• Маленькая правка может создать большой регресс: без явных критериев проверки легко починить один сценарий и сломать соседний.
• Оценка без спецификации почти всегда приблизительна: если не описаны границы и критерии готовности, команда оценивает не проект, а набор предположений.

Что должна фиксировать спецификация

• Цель: зачем делаем изменение и какой бизнес-результат нужен.
• Объём работ: что входит, что не входит, какие есть ограничения.
• Пользовательские сценарии: кто, что и зачем делает.
• Функциональные требования: как должна работать система.
• Нефункциональные требования: скорость, безопасность, доступность, SEO, совместимость, поддерживаемость.
• Интеграции и данные: источники, форматы, права доступа, миграции, API.
• Риски и альтернативы: какие варианты рассмотрены и почему выбран текущий.
• Критерии приёмки: как проверяем, что задача выполнена правильно.
• История решений: что обсуждали, какие компромиссы приняли, какие вопросы остались открытыми.

Как мы формируем спецификацию: RFC, MECE, 3C

• RFC (Request for Comments) — решения не навязываются, а выносятся на обсуждение. Мы фиксируем не «единственно верный» путь, а набор вариантов с аргументами «за/против», открытыми вопросами и историей принятых решений.
• MECE (Mutually Exclusive, Collectively Exhaustive) — принцип декомпозиции McKinsey: варианты решений не пересекаются и при этом покрывают все значимые направления. Убирает дублирование усилий и не оставляет «белых пятен».
• 3C (Card, Conversation, Confirmation) — Agile-подход Рона Джеффриса для превращения расплывчатых пожеланий в чёткие пользовательские истории: Card — краткая запись требования, Conversation — обсуждение деталей со стейкхолдерами и командой, Confirmation — критерии приёмки.

На выходе — структурированный документ, где варианты решений выстроены по MECE, каждый оформлен как RFC-документ с описанием, обоснованием, рисками и открытыми вопросами, а каждая задача имеет зафиксированные договорённости и чёткие критерии приёмки.

Выгоды для заказчика

• Прозрачность: понятно, что именно будет сделано и почему.
• Предсказуемость бюджета и сроков: меньше скрытых допущений, точнее оценка.
• Меньше переделок: спорные моменты выявляются до разработки, а не после релиза.
• Контроль результата: есть критерии приёмки, по которым можно объективно проверить работу.
• Сохранение знаний: проект не зависит от памяти конкретного исполнителя.

Выгоды для команды

• Единый контекст: аналитик, дизайнер, разработчик, тестировщик и AI-агент работают от одного документа.
• Меньше конфликтов в реализации: архитектурные и продуктовые решения зафиксированы заранее.
• Быстрее онбординг: новый участник понимает логику проекта по спецификации.
• Лучше качество кода: требования, ограничения и тестовые сценарии известны до реализации.
• Проще поддержка: через месяц или год можно понять, почему система устроена именно так.

Практический вывод

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