Материал подготовлен в рамках курса «Системный аналитик. Базовый уровень».
Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech, а также преподаю на курсах разработки и архитектуры в OTUS. В этой статье расскажу о том, как на самом деле устроен процесс создания ПО и почему выбор методологии разработки до сих пор вызывает жаркие споры даже в очень дорогих и успешных командах.
Когда я провожу собеседования, то почти всегда слышу в ответе про Agile, Scrum и «гибкость». Но когда задаёшь уточняющий вопрос: «А что именно делает ваш Waterfall негибким, и в какой момент Scrum становится опасным для продукта?», — повисает пауза.
Кажется, что вопрос методологии — это что‑то из школьной программы: все знают, все проходили. Но на практике большинство команд либо скатываются в хаос, маскируя его под Agile, либо закапывают продукт в документации, называя это Waterfall.
Сегодня разберём две фундаментальные модели разработки ПО без агитации за одну из сторон. Посмотрим, как устроен реальный, а не «книжный» процесс, и какие лучшие практики используют сильные команды, чтобы доставлять бизнес‑ценность, а не просто двигать стикеры по доске.
Процесс, которого нет, или почему без методологии сложно
Однажды мы запускали внутренний сервис для онбординга сотрудников в FinTech‑компании. Задача была простой: форма заявки на доступы, маршрут согласования, уведомления. Команда из трёх разработчиков села писать код «как обычно». Без внятного плана Requirements, без прозрачных этапов, без синхронизации с безопасниками.
Через месяц мы получили сервис, который делал всё, кроме того, что просил заказчик. Парадокс? Нет. Просто никто не понял, как интерпретировать фразу «автоматическое согласование». Разработчик сделал жёсткий BPMN‑движок, а бизнесу нужен был простой email‑флоу. Мы переписывали 70% кода. И именно тогда у меня окончательно сформировалось понимание: процесс — это не бюрократия, это договорённость о том, как именно мы договариваемся.
Waterfall — не динозавр, а каркас для сложного
Когда говорят «Waterfall», у многих перед глазами встаёт картинка: огромный документ на 300 страниц, который никто не читает, и год разработки без единого релиза.
Да, такая модель действительно существует, и называется она каскадной именно потому, что каждый этап жёстко следует за предыдущим. Сначала — полный сбор требований, затем — архитектура, потом кодирование, тестирование и только в конце — сдача заказчику. Вот как это выглядит в классическом, хрестоматийном виде (рис. 1):
Эта схема показывает классический Waterfall — каскадную модель, где работа движется строго сверху вниз. Каждый этап (анализ требований, проектирование, разработка, тестирование, внедрение) должен быть полностью завершён до перехода к следующему. Главный вывод: такая модель даёт предсказуемость и детальную документацию, но крайне негибка к изменениям — возврат на предыдущий этап требует значительных затрат и времени.
Но настоящая проблема не в том, что это «старая» модель. Она идеально работает там, где цена ошибки непомерно высока. Например, в FinTech‑разработке платежных шлюзов. Один из моих проектов был связан с интеграцией в систему быстрых платежей (СБП). Там требования фиксируются на уровне ЦБ: никаких «давайте попробуем и по ходу уточним». Если сообщение не соответствует спецификации формата ISO 20022, деньги просто не дойдут. Ты обязан сначала спроектировать всё до байта и только потом писать код. Waterfall там — это не архаизм, а вынужденная мера защиты от финансовых потерь.
Практика, которую я смело рекомендую, звучит так:
Waterfall — отличный выбор, когда требования стабильны и однозначны на старте. В банковском middleware, в авионике, в промышленных контроллерах он даёт больше пользы, чем вреда. Но применять его в потребительских продуктах, где рынок меняется каждые два месяца, — значит гарантированно сделать не то, что нужно пользователю.
Agile, который не работает на автомате
На другом полюсе — Agile. Про него написано так много, что кажется, будто достаточно взять Scrum Guide, расчертить доску в Jira и проводить дейли‑митинги, и всё станет хорошо.
Не станет.
Самое губительное заблуждение, которое я регулярно вижу, — это превращение Agile в ритуал. Команда раз в две недели делает «спринт», но при этом архитектура продолжает разваливаться, а спринт‑ревью превращается в презентацию для галочки. Главная ценность Agile не в скорости, а в петлях обратной связи. Вот схема, которая отражает суть генеративного цикла разработки:
Эта схема показывает суть генеративного цикла Agile. В отличие от линейного Waterfall, работа строится не на жёстком плане, а на проверке гипотез: идея из бэклога превращается в работающий фрагмент продукта за короткий спринт, демонстрируется пользователю, а его обратная связь немедленно влияет на то, что команда будет делать дальше. Главный вывод: процесс зациклен на постоянной валидации ценности — мы не просто выполняем задачи, а непрерывно уточняем, туда ли мы движемся, и адаптируемся к реальным потребностям, а не к первоначальным предположениям.
Здесь важно смещение акцента. Мы не просто «делаем задачи по очереди». Мы валидируем гипотезы. Лучшие практики команд, работающих в этом направлении, строятся на трёх китах:
Первый — Contract‑First разработка. Даже в Agile сильные бэкенд‑команды перед кодированием фиксируют API‑контракты в виде Swagger‑спецификации. Я видел, как это спасло проект в рознице: фронтендеры и бэкендеры работали параллельно, ориентируясь на утверждённый контракт. Это не противоречит Agile, это убирает хаос на этапе стыковки.
Второй — Trunk‑based Development. Практика, когда разработчики сливают код в одну главную ветку как минимум раз в день, а не сидят в долгоживущих feature‑ветках. Это сложно, это требует мощного CI/CD, но это даёт настоящее сокращение time‑to‑market, а не иллюзию спринта.
Третий — Event Storming на старте. Вместо того чтобы системный аналитик писал унылый документ, вся команда (включая продакта и разработчиков) за пару часов буквально «собирает» процесс из событий, команд и агрегатов на стикерах в Miro. Это не замена классическому анализу, а один из лучших способов быстро выявить узкие места.
Как сильные команды выбирают свой путь
На самом деле холивар «Waterfall vs Agile» давно устарел. Лучшие команды, с которыми я работал последние годы, смешивают подходы. Они используют Waterfall‑подход (этап Analysis & Design) для проектирования архитектуры и базы данных, но при этом реализацию фич ведут короткими итерациями, выкатывая MVP за 2–4 недели.
Так, в одном проекте по созданию системы KYC (Know Your Customer) мы потратили полтора месяца только на разбор регуляторики, схем хранения ПДн и проектирование контрактов с внешними сервисами. Это был чистый «водопад» в рамках большого релиза. А дальше — начался Scrum с еженедельными демо для комплаенса. И это не противоречило друг другу, потому что команда понимала: правила игры заданы до начала кодинга, а вот UX и сценарии обработки ошибок — это то, что будет меняться.
Что в итоге?
Разработка ПО устроена проще, чем кажется, но сложнее, чем пишут в учебниках. Не существует серебряной пули. Waterfall даёт стабильность и предсказуемость там, где требования заморожены, а цена ошибки критична. Agile даёт скорость и адаптивность, но требует зрелости команды и готовности к постоянной синхронизации. Провалы случаются не из‑за «неправильной» методологии, а из‑за отсутствия настоящего анализа: когда никто не задаёт вопросы «а что, если?» и не проверяет гипотезы до того, как написан код.
Именно способности выстраивать процессы под задачу, а не натягивать шаблоны на реальность, мы уделяем много внимания на курсе OTUS «Системный аналитик. Базовый уровень».
На занятиях разбирают, как работать с требованиями, моделировать процессы, взаимодействовать с заказчиками и командой разработки, а также выбирать подходы, которые помогают доводить продукт до понятного результата.
Если хотите развиваться в системном анализе или смежных направлениях, посмотрите также каталог курсов по аналитике и анализу: там собраны программы для тех, кто хочет глубже разбираться в требованиях, данных, бизнес-процессах и проектировании IT-решений.