стадиях его реализации получили название гейтов (gates, ворота – не путать с milestones/вехами, которые не связаны с решениями о прекращении всего проекта в целом и служат лишь для контроля скорости его прохождения. Ворота могут быть закрыты, а вот вехи просто отмечаем глазами на обочине). Вообще-то решений в гейтах обычно не два типа (go – no go), а три (доработать результат стадии и повторить гейт; переходить к следующей стадии; остановить проект):
Но данная концепция/модель жизненного цикла оказалась для проектов с существенной долей работ с новыми для разработчиков типами систем полной утопией, она более-менее выполнялась лишь в проектах, где можно было накопить огромный опыт сборки/изготовления многочисленных очень похожих систем «из вещества» (там небольшая вариативность), например, гражданское (жилищное) блочное строительство.
Во всех остальных случаях (и особенно ярко это проявлялось в айтишных проектах) после выполнения работ по любой из практик «водопадного жизненного цикла» (в те времена типично было, например, указание на инженерию требований в ходе стадии работ «формирование требований» – понятно, что разработанные требования говорили «какая должна быть система, чтобы быть успешной», и дальше ожидалось, что можно просто спроектировать и изготовить такую систему для гарантированной успешности) после всех гейтов с их проверкой независимыми экспертами, после всех ожиданий, когда все рабочие продукты соберут по их состоянию готовности на конец стадии (скажем, если речь идёт о требованиях – то это будут абсолютно все требования, и если не готово даже какое-то второстепенное требование, то его будут ждать), всё равно при попытке работы с этими результатами предыдущих стадий находятся ошибки и недоработки и приходится выполнять новые работы, выполняющие практики работ предыдущих стадий жизненного цикла. Требования постоянно оказывались не «долженствованием», а «мы чуток ошиблись, гипотеза не подтвердилась», «мы тут не уточнили, давайте сформулируем по-другому». Пробы и ошибки всё равно были, новые и новые переделки/reworks не позволяли хоть как-то соотносить запланированные стадии жизненного цикла и реально ведущиеся работы. «Водопад» был только на бумаге в учебниках инженеров и в мечтах менеджеров.
«Водопад» оказался утопией, типа менеджерского философского камня или эликсира бессмертия: очень привлекательно, но абсолютно нереалистично, нереализуемо. Проблема в том, что следование этой утопии в планировании и отслеживании планов во многих организациях происходит до сих пор! В договорах, планах и отчётах до сих пор можно найти именно «водопад», а то, что в жизни всё совсем не так, никак не влияет на эти документы, поэтому они не отражают реальную жизнь. Эта ситуация известна как проблема «а чо такова?», то есть проблема непринятия всерьёз логичных рассуждений, игнорирование важности соответствия жизни и описаний жизни. Это всё равно как знать, что суеверия – плод фантазии, но всё-таки следовать им. «Водопад» оказывается