Waterfall пример

Что такое Waterfall-модель и из каких фаз она состоит

Waterfall (каскадная, или водопадная, модель) — предсказательный подход к управлению проектами, разработанный в 1970-х годах. Проект делится на строго последовательные фазы, каждая из которых полностью завершается до старта следующей. Классическая цепочка выглядит так:

1. Требования — сбор, согласование и фиксация всего объёма требований; итогом служит утверждённое техническое задание или SRS (Software Requirements Specification).
2. Проектирование — архитектурные решения, схемы, прототипы; на выходе — проектная документация, которая становится контрактом между аналитиками и разработчиками.
3. Разработка / Реализация — создание продукта строго по утверждённому проекту; изменения требований на этом этапе формально запрещены или проходят через change request.
4. Тестирование — проверка соответствия результата требованиям; дефекты фиксируются и устраняются, но новые требования не принимаются.
5. Внедрение — передача продукта заказчику, развёртывание в боевой среде.
6. Поддержка — эксплуатация и сопровождение; любые существенные изменения инициируют новый проект или формальный change request.

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

Примеры Waterfall-проектов по отраслям

Строительство: многоэтажный жилой дом

Контекст. Застройщик возводит 18-этажный жилой комплекс. Требования зафиксированы в проектной документации, согласованной с госэкспертизой. Изменить планировку после заливки монолитного каркаса физически невозможно без сноса конструкций.

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

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

Производство: запуск новой продукции на линию

Контекст. Производитель бытовой техники выводит новую модель холодильника. Продукт должен соответствовать техническим регламентам ЕАЭС, пройти сертификацию и встать на конвейер в фиксированную дату.

Как работает Waterfall. Цепочка: маркетинговое ТЗ → инженерное проектирование → прототипирование и испытания → подготовка производства (оснастка, закупка компонентов) → пилотная партия → сертификация → серийный выпуск. Каждый этап зависит от предыдущего: сертификацию нельзя начать до завершения испытаний, а подготовку производства — до утверждения конструкторской документации.

Результат. Жёсткая последовательность обеспечивает трассируемость: каждое техническое решение задокументировано и может быть проверено регулятором. Scope creep исключён конструктивно — изменение компонента после запуска оснастки требует повторной сертификации и дополнительных затрат.

Регулируемая IT-разработка: банковская core-система

Контекст. Банк внедряет новую АБС (автоматизированную банковскую систему). Требования определены регулятором, внутренними политиками и договором с вендором. Система должна пройти аудит безопасности и получить разрешение на эксплуатацию.

Как работает Waterfall. Фазы: сбор и согласование требований (BRD, SRS) → системное проектирование → разработка и кастомизация → интеграционное тестирование → UAT → аудит безопасности → промышленная эксплуатация. Каждая фаза закрывается пакетом документов, который проверяется внутренним PMO и внешним аудитором. Изменения требований после подписания SRS проходят через change request board с оценкой влияния на сроки и бюджет.

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

Waterfall vs Agile vs гибрид: когда каскад оправдан

Сравнительные академические исследования фиксируют заметную разницу в вероятности успеха между подходами. В динамичных средах с меняющимися требованиями Agile-проекты демонстрируют более высокую вероятность успеха, чем чистый Waterfall, а доля провальных проектов у каскадной модели заметно выше. Исследования BI-проектов также указывают на то, что Agile-команды чаще фиксируют положительный ROI по сравнению с командами, работающими по Waterfall.

Тем не менее эти данные относятся к динамичным средам с меняющимися требованиями. В средах с фиксированными требованиями и высокой регуляторной нагрузкой картина иная:

• Waterfall даёт предсказуемость сроков и бюджета, полную трассируемость и соответствие регуляторным требованиям к документации.
• Agile выигрывает при частых изменениях требований, коротких циклах обратной связи и высокой неопределённости продукта.
• Гибридный подход — Waterfall для фаз с фиксированным scope (проектирование, сертификация) и Agile для итеративных блоков (разработка фич, UX) — по данным ряда исследований, позволяет улучшить ключевые показатели проекта по сравнению с чистыми подходами, особенно когда часть требований стабильна, а часть подвержена изменениям.

Вывод: выбор модели определяется не модой, а характеристиками конкретного проекта — стабильностью требований, регуляторной нагрузкой, размером команды и допустимым уровнем неопределённости.

Типичные ошибки при использовании Waterfall и как их избежать

Большинство провалов Waterfall-проектов связаны не с самой моделью, а с её неправильным применением. Три главных риска:

Неполные требования на старте

Если SRS или ТЗ содержат пробелы, они материализуются в дефекты на фазе тестирования или в scope creep на фазе разработки. Контрмера: quality gate на выходе из фазы требований — документ считается закрытым только после подписи всех стейкхолдеров и прохождения формальной инспекции (walkthrough или review).

Отсутствие обратной связи до финальной фазы

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

Scope creep без механизма change request

Команда начинает «по-тихому» добавлять функции или менять решения без фиксации изменений. Контрмера: change request board — любое отклонение от утверждённой документации оформляется как CR с оценкой влияния на сроки, бюджет и риски, и утверждается спонсором проекта.

Как оформить Waterfall-проект: артефакты и инструменты

Минимальный набор артефактов Waterfall-проекта привязан к конкретным фазам и служит gate-критерием перехода:

Диаграмма Ганта — центральный инструмент Waterfall: она показывает логику проекта, критический путь, зависимости между задачами и вехи как контрольные точки перехода между фазами. Без неё управление каскадным проектом превращается в ручное отслеживание статусов в таблицах.