Spec-Driven Development: что происходит, когда бизнес перестаёт ждать инженеров

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

Spec-Driven Development — попытка сломать модель, а не залатать её.

Где на самом деле ломается традиционная разработка

Классический процесс создания ПО — игра в испорченный телефон. Бизнес формулирует идею. Аналитик её интерпретирует. Архитектор переводит в техническую спецификацию. Разработчик читает эту спецификацию сквозь призму собственных представлений. Тестировщики проверяют то, что построено, а не то, что имелось в виду. На каждом этапе передачи смысл искажается, и в итоге продукт воплощает нечто близкое к первоначальному замыслу, но не сам замысел.

Дело не в таланте. Дело в архитектуре процесса. Между замыслом и результатом слишком много толкователей.

Вторая уязвимость — стоимость изменений. Исследования в области управления требованиями неизменно показывают: исправление ошибки, допущенной на этапе требований, обходится в 5–10 раз дороже, если она уже попала в работающий код. Бизнес это знает — и избегает менять требования. Инженеры это знают — и сопротивляются изменению объёма работ. В итоге обе стороны работают с устаревшей картиной реальности, лишь бы не платить за переделку.

Что на самом деле меняет SDD

Центральная идея обманчиво проста: спецификация становится главным управляющим артефактом всего проекта, а ИИ-агенты выполняют техническую реализацию.

Бизнес описывает, что должна делать система — простым языком, без технического жаргона. ИИ-агент определяет, как это реализовать. Инженер контролирует качество и корректность перевода. Код становится производным от спецификации, а не наоборот.

Принципиально меняются три вещи.

Скорость. Рабочий прототип новой функции — за дни, а не недели. Одновременная проверка нескольких гипотез. Быстрая проверка бизнес-идей без запуска полноценного спринта. Bain & Company сообщают, что инструменты ИИ уже сокращают циклы разработки на 20–30%. SDD идёт дальше: автоматизирует не только генерацию кода, но и перевод требований на технический язык — самый медленный и дорогой этап всего процесса.

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

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

Прозрачность. Спецификация — не технический документ, а бизнес-документ. Заинтересованные лица без технической подготовки могут её читать, проверять и менять. Бизнес видит, что именно будет построено, ещё до начала разработки. Любое отклонение от бизнес-логики выявляется ещё на уровне спецификации, а не после выпуска. Вся история изменений требований сохраняется по версиям и открыта для просмотра.

Что это меняет для команды

SDD не упраздняет инженеров. Он меняет то, за что их ценят. Глубокое знание стека значит меньше. Архитектурное мышление и способность формализовать требования — больше. Один инженер, оркестрирующий ИИ-агентов, теперь справляется с объёмом работ, для которого раньше требовалась команда из трёх-четырёх специалистов.

McKinsey фиксирует рост производительности на 20–45% в организациях, системно внедривших ИИ в свои процессы разработки. SDD усиливает этот эффект, автоматизируя полный цикл — от требований до кода.

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

Где SDD работает лучше всего

SDD даёт максимальный эффект в определённых ситуациях. Стартапы с высокой неопределённостью требований и частой сменой курса — стоимость экспериментов падает почти до нуля. Конкурентные рынки с короткими циклами выпуска — скорость вывода новых функций напрямую влияет на долю рынка. Регулируемые отрасли — нормативные требования встраиваются в спецификацию и автоматически проверяются при каждом изменении. Модернизация унаследованных систем — спецификация существующей системы пишется один раз и становится основой для управляемой миграции.

Честная оговорка

SDD не спасает от плохо сформулированных требований — он их обнажает. Если бизнес не может чётко описать, что должна делать система, ни один ИИ-агент этот пробел не восполнит. Качество спецификации становится критическим узким местом. Это новая компетенция, которую нужно развивать — и на стороне бизнеса, и на стороне инженеров.

Но именно в этом смысл сдвига. SDD не автоматизирует мышление. Он убирает всё, что стоит между мышлением и результатом.