Что делать, если заказчик на этапе интеграции захотел изменить требования, добавить отчёт? Ничего не сделаешь. В принципе отсутствовала такая опция в те далёкие времена. Можно было дождаться полной имплементации и начать новый проект по реализации этого отчёта. Либо прекратить все работы и начать всё снова. Нельзя попросить институт, который писал требования, их изменить. Потому что это физически вагон бумаги, который уже ушёл от них. И по той документации уже что-то сделано и компании не будут ничего переделывать, так как у них в контракте описана работа по изначальной версии задания и всё. Даже просто разорвать эти контракты и остановить работы часто было невозможно, так как в контрактах такая возможность могла отсутствовать. Компаниям приходилось оплачивать продолжение работ по контракту, даже когда нужда в программе отпадала. Так, например, происходило после распада СССР, когда экономическая ситуация изменилась кардинально и многие системы стали не нужны, но проекты остановить было невозможно.
Уже в 70-е годы прошлого века было понятно, что эта модель очень ограничена. Вся индустрия развивалась так, чтобы можно было в программы вносить правки, чтобы код следовал быстрым изменениям на рынке.
Вы можете представить ситуацию, что заказчик приносит в середине проекта деньги и просит изменить какую-то страницу приложения, а вы отказываетесь, заявляя, что будете делать всё, как раньше договаривались? Вряд ли. Возможно, вы попросите больше денег, чем договаривались изначально, сдвинете сроки, перепишете большой кусок системы, но вы точно не начнёте всё сначала, как этого требует водопадная модель разработки.
Близкая к водопадной модель иногда встречается на совсем небольших проектах и проектах по интеграции существующего, а не разработке нового ПО. Но там просто изменений от заказчика не поступает и решения типовые, поэтому нужда в итерациях отсутствует.
В обычном же проекте в настоящее время классического водопада нет. Да, возможно, не используется Scrum. Да, возможно, вообще никто не может сказать, что именно это за методология, и она нигде не описана. Но это не водопад.
Почему это вообще важно? Потому что методология разработки оказывает очень большое влияние на всё. Если вы считаете, что работаете по одной методологии, а на самом деле работаете по другой, то вы будете принимать неправильные решения.
На практике это выглядит просто и привычно. Вы думаете, что вы применяете водопадную модель. Значит, вы можете легко делать Fixed Price3 проекты. Нужно только собрать требования и можно сказать, в какой бюджет вы впишетесь.
Fixed price проекты могут быть очень выгодными, поэтому вы начинаете их делать. И оказывается, что вы превышаете бюджет проекта в разы. Сперва вы подозреваете, что вы неправильно оцениваете проекты, и вы начинаете совершенствовать свой процесс оценки (параллельно теряя деньги на проваленных проектах). Потом вы видите, что требования описываются недостаточно детально, и вы начинаете совершенствовать аналитику и мучать заказчика дополнительными раундами уточнения требований (снова теряя деньги на проваленных проектах). Потом вы видите, что эти прекрасно описанные требования всё равно меняются заказчиком на более поздних этапах. Вы начинаете это ему запрещать, а заказчик возмущается, так как его бизнес уже изменился за то время, пока вы писали свою аналитику. В результате вы понимаете, что для применения чистого “водопада”, вам нужно жёстко отфильтровывать заказчиков и их проекты. После разработки и применения этих фильтров вы понимаете, что на рынке нет достаточно заказчиков, которые готовы с вами работать по “водопаду”. Но вы не переживаете, так как ваша компания вряд ли дойдёт до этого этапа. Скорее всего, денежные потери будут неприлично высоки уже на этапе попыток совершенствования оценок. Вы либо прогорите, либо измените свои подходы к проектам.
Поэтому, если вам кажется, что вы работаете по водопадной модели разработки, пожалуйста, удостоверьтесь, что вам это не кажется.
Виды проектного менеджмента
Роль менеджера гораздо слабее определена, чем роль разработчика. В разных компаниях разные менеджеры занимаются очень разными видами деятельности. Но так же, как backend-разработчик отличается от frontend-разработчика, разные руководители проектов отличаются друг от друга по набору знаний и умений.
3
Fixed Price – модель работы, когда заказчик заранее договаривается о конкретной сумме за проект. Любые превышения бюджета идут за счёт компании-исполнителя. Этот термин используется в противоположность проектам Time&Material, когда заказчик оплачивает время работы разработчика на своём проекте, сколько бы этого времени не понадобилось.