Waterfall открывают, когда проект нельзя безопасно вести через постоянную пересборку по ходу. Требования относительно стабильны, этапы выражены явно, цена позднего изменения высока, а управление держится на последовательности: сначала собрать, потом согласовать, потом реализовать, потом принять.
Что это за подход
Waterfall полезен как последовательная delivery-модель с более жёсткой стадийностью и большей ценой изменения по мере движения проекта. Для PM он особенно уместен там, где важно заранее прорабатывать рамку, зависимости, контрольные точки и готовность до перехода на следующий этап.
Когда он нужен
- требования достаточно стабильны;
- важна высокая предсказуемость этапов;
- проект зависит от формальных согласований и переходов;
- поздние изменения дороги или опасны.
Когда он не нужен
- высокая неопределённость требований;
- продуктовый или экспериментальный контур с быстрым learn-and-adjust циклом;
- среда, где ценность появляется итеративно, а не в финале большого этапа.
Что из него реально применимо для PM
- сильный upfront-фокус на требованиях и плане;
- явные критерии переходов между этапами;
- более формальный контроль зависимостей и готовности;
- понятная логика статуса для сред, где важна стадийность.
Какие артефакты, ритуалы и правила важны
- project brief и рамка проекта;
- план этапов и контрольные точки;
- формализованные требования и change request;
- критерии готовности и приёмки.
Какие ошибки чаще всего делают при внедрении
- выбирают Waterfall там, где требования заведомо будут плыть;
- скрывают реальную неопределённость под видом «сначала всё опишем»;
- слишком поздно поднимают проблемы, потому что модель выглядит линейной;
- считают, что план по этапам автоматически означает управляемость.
Чем можно заменить или упростить
- Agile, если среда требует адаптивности;
- Stage-gate, если нужна логика переходов без полного waterfall-мышления;
- hybrid-модель с более жёстким discovery и более гибким delivery.