Управление изменениями в «водопадных» проектах

В ходе реализации проекта почти всегда что‑то меняется. Либо проясняется исходное видение, либо изменения связаны с переосмыслением изначальных предпосылок. Внесение в уже запущенный проект изменений в любом случае требует некого бизнес‑процесса.

Откуда вообще берутся изменения в «водопадных» проектах и почему это может быть проблемой?

«Водопадная» модель разработки в принципе не предназначена для реализации проектов в стиле «ввяжемся в бой, а там война план покажет». Водопадная методология «заточена» под хорошо прогнозируемые проекты с понятными изначально ожиданиями, а на проектах с высокой долей неопределенности она часто даёт сбои.

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

Основные проблемы — это необходимость возвращаться к предшествующим этапам в рамках новых задач, а также пересматривать грядущие этапы на предмет их соответствия новым задачам.

Можно привести аналогию из строительства: вначале принимается решение строить двухэтажный дом с мансардой, а затем, когда первый этаж уже построен, выясняется, что этажа надо минимум три, а крыша должна быть плоской и с площадкой для вертолёта. Данные изменения повлекут за собой необходимость укрепления фундамента, добавят работ по строительству дополнительного этажа, а также изменят состав работ по строительству крыши. Разумеется, что это повлияет на сроки и бюджет. В разработке ПО ситуация похожая: существенные изменения задач проекта вызывают необходимость переделки уже выполненных ранее работ и перепланирования грядущих.

Методики работы с изменениями

Если изменения глобальны, то тут потребуется остановка выполнения работ, переосмысление проекта, прохождение всех предшествующих этапов по всем изменениям и перепланирование будущих.

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

Если изменения не очень значительны и носят характер дополнений, то подойдёт запуск мини‑проекта по пересогласованию текущих задач и выполнению новых. Способ подходит, если изменения не очень критичны и следование прежнему плану не приведёт к выполнению заведомо ненужных работ.

В этом случае проект продолжает выполняться по прежнему плану (или незначительно измененному), а новые задачи прорабатываются (а часто и реализуются) параллельно с прежними. Превышение бюджета тут тоже крайне вероятно, но в сроки проект имеет все шансы уложиться.

Мелкие изменения, которые выходят за рамки проекта, чаще всего рациональнее выполнять уже после завершения основных работ. Непрерывный поток «небольших» изменений часто просто парализует выполнение работ, так как производственные ресурсы уходят на обработку входящей информации. Или изменения приводят к проблемам, если фаза анализа пропускается и полученные изменения сразу идут «в работу».

Еще можно имитировать «водопад» в рамках итеративной разработки — тут поможет чёткий общий план работ (roadmap), который, по сути, является ТЗ «водопадного» проекта, но может вполне успешно использоваться в рамках фактической итеративной разработки. При этом надо понимать, что такой подход не очень рационален, так как он в конечном счёте может иметь все минусы и той, и другой методологии.

Резюме

В принципе, вносить кардинальные изменения в «водопадный» проект стоит лишь в том случае, когда следование изначальному плану приведёт совсем не туда, куда надо. И тут нужна готовность к временной остановке проекта и переосмыслению изначальных договоренностей. Вообще изменений при работе по «водопаду» лучше избегать и страховаться от их появления — на сбор требований, на их анализ и на проектирование стоит выделять существенные ресурсы (как временные, так и материальные).

Если же цели и задачи проекта не могут быть достаточно чётко определены на старте, то лучше смотреть в сторону итеративной разработки, так как водопадная модель в этом случае не подходит и реализация проекта в её рамках ни к чему хорошему приведёт.