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

Неизменно было только одно – основную ценность представляет код. Код – это истина в последней инстанции. Требования, архитектура, тест-кейсы — не более чем черновики, наброски, которые могут быть уничтожены сразу после начала «настоящей работы» – написания кода.

Но что, если я скажу, что сейчас происходит тихая контрреволюция? Индустрия устала от неопределенности. Когда код — единственная истина, система превращается в «черный ящик». Понять, как она работает фактически, можно только прочитав тысячи строк кода.

 Код идеально отвечает на вопрос «как?», но в нем нет ответа на вопросы «зачем?», «для кого?», «почему?».  Без знания ответов на эти вопросы, любая доработка —  это гадание на кофейной гуще.

В этой статье проследим эволюцию: от Водопада к Agile, от Agile к гибридам и Everything as Code.

• Водопад: эпоха «толстых ТЗ»

• Agile: эпоха «общения»

• Гибриды: осознание

  • Everything as Code: документация становится кодом

  • Requirements as Code 

• Заключение

Водопад: эпоха «толстых ТЗ»

Водопад появился на заре IT-индустрии, когда автоматизация даже простого бизнес-процесса давала ощутимый выигрыш. Изучение и описание процессов «как есть» и «как должно быть» занимало месяцы. Технические задания содержали сотни страниц требований описанных на высоком уровне абстракции.

Это создавало ловушку. Абстрактные формулировки с одной стороны давали разработчикам свободу технической реализации. С другой — открывали простор для множественных трактовок. Заказчик говорил «что» нужно сделать. Аналитик переводил это на язык, понятный разработчикам. Разработчики решали «как» это сделать. Участники каждого этапа процесса говорили на своем языке и смысл требований искажался при каждом переходе на следующий этап.

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

Решение виделось очевидным: убрать ТЗ, которое все понимают по-разному.

Agile: эпоха «общения»

На смену водопаду пришел Agile. Он призывал нас больше общаться и думать не о том, «что» и «как» делать, а «для кого?» и «зачем?». Заказчик и разработчик перестали быть противниками стоящими по разные стороны баррикады — они стали участниками одной команды, рука об руку идущими к общей цели.

Гибкие методологии дали аналитикам возможность изучать рынок и пользователей вместо того, чтобы вычитывать километровые ТЗ. Разработчикам они даровали свободу: теперь они решали не только «как», но и «что», имея право менять сроки и стоимость в процессе работы над кодом.

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

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

Гибриды: осознание

Спустя десятилетия индустрия поняла: крайности — зло. Водопад мертв, но и Agile в чистом виде работает только в маленьких стартапах.

Мы научились понимать пользователей без многомесячных опросов — данные теперь собирают и анализируют системы.  Теперь мы знаем чего хотят пользователи, заказчики находятся в одной лодке с разработчиками,  созданы огромные системы по автоматизации всего что только можно. Но возникла новая проблема: разработчики разучились понимать друг друга.

Системы стали чудовищно сложными. Микросервисы, event-driven архитектура, десятки интеграций. Устно согласовать формат каждого сообщения между двадцатью сервисами невозможно. Нужна формальная спецификация. Но это уже не спецификация требований на высоких уровнях абстракции. Это описание конкретного архитектурного решения (границ контекстов, моделей данных, API-контрактов, технологического стека и т. д.) — техническая документация для команд.

Детальное описание архитектурного решения позволяет распараллелить работу. Фронт, бэк, тестировщики и технические писатели могут стартовать одновременно, не дожидаясь, пока кто-то закончит свою часть. Это и есть настоящая agile-скорость, достигнутая не отказом от документации, а ее точностью.

Гибриды — это мини-водопады внутри итерации. Спецификация живет итеративно: описали кусок под конкретную функцию, реализовали, пошли дальше.

В Agile  первенство отдавалось коду — «пиши сразу, потом исправим». В гибридах код пишут после того, как технические специалисты обдумали реализацию, распределили задачи и зафиксировали договоренности. Сначала — архитектура, потом — код.

Everything as Code: документация становится кодом

 Преимущества подхода «сначала думай, потом делай» очевидны всем. Но его массовому применению мешала одна проблема: для детального описания архитектурного решения  нужны технические навыки. По-хорошему, этим должны заниматься разработчики или архитекторы. Но разработчики не любят читать документацию, а уж тем более писать её. Они любят писать код. Это и стало причиной широкого распространения подхода Everything as Code.

Everything as Code — подход, при котором все артефакты проекта хранятся как текстовые файлы в системе контроля версий (Git). Требования, архитектура, тесты, конфигурации, инфраструктура — всё становится кодом.

По сути, Doc as Code (документация как код), Architecture as Code (архитектура как код) и Requirements as Code (требования как код) — это способ сказать разработчикам: «Вам не нужно читать скучные ТЗ. Вы будете работать с тем, что вам привычно — с кодом, с Git, с репозиториями».

Ключевые принципы Everything as Code:

• Близость к коду — документация находится рядом с кодом, к которому относится.

• Версионирование — вся документация хранится в системе контроля версий вместе с кодом.

• Текстовые форматы — все описывается в текстовых файлах, даже диаграммы.

• Автоматизация — тестирование, сборка и публикация документации происходят автоматически.

• Совместная работа — ревью документации по тому же принципу, что и ревью кода.

Преимущества подхода

• Актуальность. Документация обновляется в том же коммите, что и код. Она не успевает устареть.

• Качество. Ревью и автотесты работают не только на код, но и на документацию.

• Прозрачность. Вся история изменений и ответственные видны в системе контроля версий.

• Скорость. Ручные операции уходят в прошлое. Автоматическая публикация документации происходит мгновенно.

• Единое пространство для команд. Аналитики, разработчики, тестировщики, специалисты по безопасности работают в одном репозитории. Никаких разрозненных команд и разбросанных знаний.

Главное: документация перестает быть процессом, оторванным от разработки. Она становится её неотъемлемой частью.

При стихийном формировании гибридных процессов документацию начинали писать с помощью самого знакомого инструмента. Для аналитиков было привычно описывать требования в wiki системах (Confluence, Notion), тестировщики хранили описание API-контрактов в Postman, разработчики —  в Swagger, архитекторы рисовали диаграммы где придется. Everything as Code предполагает что все хранится в одном месте, убирая тем самым зоопарк из систем совместной работы.

Работа с инструментами, привычными разработчикам, — это одновременно и преимущество, и недостаток.

1. Порог входа для нетехнических ролей. Git — инструмент непростой. Можно обучить аналитиков и тестировщиков, но заказчика заставить комментировать требования через систему контроля версий не получится. Приходится разворачивать генераторы статических сайтов, чтобы превращать текстовые файлы в удобные порталы для чтения.

2. Молодость экосистемы. Everything as Code — направление относительно новое. Постоянно появляются новые языки разметки, инструменты для описания диаграмм как кода. Mermaid, PlantUML, Structurizr, AsciiDoc — все это должно заменить привычный Confluence и Google Docs. Но единого стандарта пока нет, и порог входа остается высоким.

3. Нужно учить новые инструменты. Чтобы описать API-контракт, нужно освоить OpenAPI/Swagger или AsyncAPI. Это синтаксис, это другой уровень детализации, чем просто «набросать схему в миро».

4. Требуется интеграция в CI/CD. Полноценная ценность подхода раскрывается только когда работа с документацией встроена в конвейеры. Автоматическая проверка, сборка и публикация документации одновременно с релизом — это требует времени и квалифицированного специалиста. Согласитесь: это сложнее, чем написать user story на стикере или создать страницу в Confluence.

Requirements as Code 

Requirements as Code (RaC) — это частный случай применения подхода Everything as Code для работы с требованиями. Наибольшую пользу он приносит при описании артефактов, находящихся на границе между требованиями и проектными решениями:

• функциональные требования в формате OpenAPI / AsyncAPI;

• критерии приемки в формате Gherkin;

• системные требования в формате YAML-конфигураций.

Для таких артефактов существуют общепринятые форматы. Они могут быть автоматически сконвертированы в код приложения и автотесты. Это зона, где машиночитаемость окупается мгновенно.

А вот в работе с бизнес и пользовательскими требованиями RaC может только усложнить жизнь. Эти типы требований сложно формализовать и они плохо поддаются проверке. То, что мы описали пользовательскую историю по определенному формату, еще не значит, что мы верно поняли потребность пользователей. Формализация не заменяет глубинного анализа.

Технически все виды требований можно описать в виде текстовых файлов и хранить в репозитории. Но вопрос не в технической возможности, а в целесообразности. RaC создан для машин, а бизнес-требования — для людей.

Где RaC пасует

1. Другие участники процесса. На ранних итерациях ключевую роль играют представители бизнеса, пользователей, бизнес и продуктовые аналитики. Это люди, не привыкшие работать с кодом и Git. Вынуждать их осваивать пул-реквесты и синтаксис разметки — значит создавать барьер, который может не окупиться потенциальной пользой.

2. Анализ важнее документации. Аналитик описывает требования не только ради конечного документа. Моделирование-бизнес процессов и сценариев использования — это способ мышления. Глядя на бизнес-процессы в разных разрезах, аналитик находит узкие места и точки роста. Описывая пользовательские сценарии, аналитик выявляет упущенные требования и оценивает риски, связанные с альтернативными сценариями. Если инструмент мешает этим процессам, он бесполезен, даже если генерирует идеальный машиночитаемый код.

3. Визуализация имеет значение. Инструменты Everything as Code создавались разработчиками для разработчиков. «Красота» никогда не была для них приоритетом. Но при работе с бизнесом и лицами, принимающими решения, визуализация критична. Понятная диаграмма часто важнее формальной точности.

RaC — отличный инструмент для системных требований, контрактов и тестов. Но бизнес-требования и потребности пользователей лучше оставить людям. Пытаться загнать в псевдокод цели компании, боли пользователей и стратегию продукта — значит подменить содержание формой. У каждого инструмента должна быть своя зона ответственности.

Заключение

Гибридные модели управления разработкой формировались стихийно. На разных проектах используются разные инструменты. Это и сила, и слабость гибридов: они не накладывают ограничений, но и не дают готовых решений.

То же самое с Everything as Code. Трудности, с которыми сталкиваются команды, — не приговор, а точки роста:

• Инструменты будут дорабатываться, становясь удобнее для нетехнических ролей.

• Удачные шаблоны структуры знаний станут общеупотребимыми, снижая порог входа.

• Появятся понятные пайплайны интеграции RaC в процессы бизнес-анализа.

Но неизменным остается одно: получить преимущества от гибридного процесса можно только подойдя к его настройке с умом. Слепое копирование практик или фанатичное следование идеологии «всё в код» без учета реальных ролей и контекста приведет к обратному эффекту.

Спецификации возвращаются, но в новом обличье — машиночитаемые, живые, интегрированные в процесс разработки. Они нужны не для того, чтобы защититься от заказчика, а для того, чтобы десятки команд могли понимать друг друга и работать параллельно.

Машины уже умеют читать спецификации, описанные по принципам Requirements as Code. Следующий шаг — они научатся их писать и использовать как промпты для AI-агентов, пишущих код. И тогда мы, возможно, станем свидетелями нового витка эволюции, где грань между требованием, кодом и тестом окончательно сотрется.

Но это уже совсем другая история…