Как хорошему разработчику не стать плохим менеджером - страница 2

Совсем другая ситуация, когда проект провален из-за низкой квалификации разработчиков или, ещё хуже, когда проект провален, и никто не понимает, почему. В этой ситуации провал проекта – это просто потраченные деньги. Ни один заказчик такого не потерпит.

Периодически слышу от разных людей сожаление, что они используют водопадную модель разработки: “Мы бы и рады использовать Agile, но заказчик против”, “У нас водопад, мы к нему привыкли”, “Мы готовимся перейти на гибкие методологии, но пока у нас водопад”. Такие разговоры меня удивляют, так как встретить сейчас чистую водопадную модель разработки практически нереально.

Чтобы выяснить, почему так, давайте вспомним, что такое водопад как методология разработки, и как связаны разные этапы разработки:

Все этапы идут один за другим. Следующий этап начинается после полного окончания предыдущего этапа. Это очень-очень старая модель. Её название пошло из статьи Уинстона Уокера Ройса, опубликованной в 1970м году. Юмор заключается в том, что в той статье Ройс говорил об устарелости и ограниченности этой модели и о необходимости перехода на итеративные модели. То есть “водопад” – это то, как разрабатывали программы в 60-е годы.

Нам сейчас даже трудно представить, как это было, но давайте попробуем. Вот у какой-то компании есть нужда в какой-то программе. Она оплачивает анализ требований какому-нибудь проектному институту. В результате получает вагон требований (буквально железнодорожный вагон документации), который принимается и подписывается. Эта документация потом направляется в другой проектный институт, который уже делает дизайн, описывает, какое оборудование и какие программы нужны для реализации задачи. Опять, весь результат оформляется, принимается и подписывается. Для реализации документация направляется по нескольким другим компаниям, которые разрабатывают аппаратно-программные комплексы. На общую задачу им плевать, они работают по документации и производят не только код, но и кучу другой документации. На этапе интеграции ещё одна компания объединяет все эти разработанные куски в единое целое и только тогда начинается внедрение (отдельной компанией или департаментом).

Что делать, если заказчик на этапе интеграции захотел изменить требования, добавить отчёт? Ничего не сделаешь. В принципе отсутствовала такая опция в те далёкие времена. Можно было дождаться полной имплементации и начать новый проект по реализации этого отчёта. Либо прекратить все работы и начать всё снова. Нельзя попросить институт, который писал требования, их изменить. Потому что это физически вагон бумаги, который уже ушёл от них. И по той документации уже что-то сделано и компании не будут ничего переделывать, так как у них в контракте описана работа по изначальной версии задания и всё. Даже просто разорвать эти контракты и остановить работы часто было невозможно, так как в контрактах такая возможность могла отсутствовать. Компаниям приходилось оплачивать продолжение работ по контракту, даже когда нужда в программе отпадала. Так, например, происходило после распада СССР, когда экономическая ситуация изменилась кардинально и многие системы стали не нужны, но проекты остановить было невозможно.

Уже в 70-е годы прошлого века было понятно, что эта модель очень ограничена. Вся индустрия развивалась так, чтобы можно было в программы вносить правки, чтобы код следовал быстрым изменениям на рынке.