Waterfall или Agile для проекта: выбрать нельзя сочетать

По большому счету методологии управления проектами делятся на две большие группы. У одних в основе классический каскадный подход Waterfall, у других — гибкий Agile. В этой статье рассмотрим, нужно ли противопоставлять методологии друг другу и как сочетать такие разные подходы в рамках одного проекта.

Особенности подходов

Waterfall свойственны регламентированность, последовательность, иерархичность, предсказуемость, исчерпывающая документация, в частности Product Requirements Document (PRD — требования к продукту), а также модели, схемы и конкретные бизнес-правила для проекта. Это обеспечивает ему четкие сроки и определенность бюджета.

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

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

Каскадная модель больше подходит типовым проектам со стандартными, регламентированными процессами и прогнозируемыми рисками, по которым есть проверенный план действий. Например, управление проектной деятельностью в медицине, строительстве, финансовом секторе.

Гибкие методологии подходят при создании новых продуктов, о которых еще не сформировано детального видения, какими они должны быть. Это не значит, что цель проекта не задана. Сформированы ключевые критерии, базовые требования, но при этом допускается возможности незапланированных вводных. Это подходит, например, для ИТ, сферы маркетинга и продаж.

Когда нужно комбо

Waterfall и Agile выглядят не просто разными подходами, а почти противоположными. На первый взгляд сложно представить, как их сочетать. Тем не менее проектная практика куда разнообразнее любых методологий. И очень многие проекты сложно однозначно отнести к одному из этих подходов.

Представим, банк планирует запуск нового сервиса. Такому проекту подходит каскад. Когда продукт будет разработан, нужно обеспечить клиентам доступ к нему в интернет-банке и мобильном приложении. Но в ТЗ заказчик не сможет четко указать, как именно это должно выглядеть в интерфейсах, продумать путь пользователя и механику. И конкретно для этой части работы отлично подойдет Agile. Он позволит команде проекта найти оптимальный вариант реализации с учетом требований заказчика. Если же пытаться уложить этот этап в принципы каскада, то есть риск на финише получить результат, который не только не устроит заказчика, но и будет неудобен для клиентов. Придется переделывать, а это время и деньги.

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

Таким образом, несмотря на противоположность Waterfall и Agile, в одном проекте они не просто не исключают друг друга, а могут эффективно сочетаться. Нет необходимости придерживаться одной методологии, если на каком-то этапе куда лучше сработает другая. Если от каждой взять то, что подходит конкретному проекту, работа будет продуктивнее и быстрее.

Инструменты управления

При любом подходе для эффективного управления проектом нужен удобный инструмент автоматизации. Наиболее востребованы два типа решений: таск-трекеры и информационные системы управления проектами (ИСУП). У каждого из них есть свои сильные и слабые стороны.

Таск-трекеры ориентированы на управление задачами. Для этих целей они подходят как в рамках каскада, так и гибких методологий. Но задачи — лишь один из аспектов проекта. Это результат большой работы по определению целей, планированию ресурсов и бюджетов, идентификации рисков. А в таск-трекерах все это остается «за бортом». В результате руководитель проекта сталкивается со сложностями по агрегации и анализу информации.

Классические ИСУП обладают более широкой функциональностью. Они включают возможности по контролю финансов, работы с документами, рисками, трудозатратами и, конечно, задачами. Эти системы обеспечивают единство и прозрачность информации для всех в команде, что делает их удобным инструментом для управления проектами с каскадным подходом. Но зачастую они не учитывают потребностей гибких методологий, а именно, особенности работы итерациями.

Таким образом, ни классические ИСУП, ни таск-трекеры не закрывают все потребности проектов, которые полностью или частично ведутся по Agile. Получается, что в таких случаях, нужно:

• либо использовать оба решения — неудобно, так как участникам команды нужно работать в двух системах, а руководителю собирать целостную картину по частям из разных источников;
• либо выбрать одно, которое обеспечивает более приоритетные требования команды, — неудобно, так как руководитель не может в едином инфополе мониторить ситуацию по некоторым важным аспектам проекта.

Комбинированный подход в системе автоматизации способен решить задачи проектов, которые используют Agile. Такие системы учитывают особенности и каскадных, и гибких методологий, в том числе содержат нужные инструменты.

Например, Naumen Project Ruler (NRP) позволяет спланировать каждый этап по каскаду, зафиксировать и наглядно показать структуру, взаимосвязь и последовательность задач. Чтобы держать под контролем другие аспекты проекта, в решении реализованы управление документами, рисками и бюджетом. Финансовый блок позволяет детализировать статьи расходов, отражает плановые и фактические показатели, рентабельность и маржинальность.

Что касается Agile, то NPR умеет работать со спринтами. Спринт не просто позволяет хронологически задавать периоды, а полностью отражает характеристики и роль этой важной сущности Agile. Спринт можно настраивать, указывать для него сроки, цели, добавлять задачи, планировать трудозатраты. Также этот объект позволяет учитывать другую ключевую особенность Agile — регулярное получение обратной связи от заказчика. NPR включает функциональность по организации спринт-ревью — встречам по итогам спринта. Они важны и для стейкхолдеров. Так они могут контролировать работу. Имеют большую ценность спринт-ревью и для самой команды проекта, потому что служат источником новых идей для бэклога.

Наконец, в основе любого проекта, который реализуется по любой методологии, лежат цели. И главный критерий для оценки результата: удалось ли их достичь. Именно вокруг них строится работа и планируются задачи. Поэтому важно на каждом этапе проекта сверяться с целями и анализировать, насколько то, что делается, приближает команду к ним. Особенно это актуально для проектов с гибким подходом, в которых легко отклониться от курса, подстраиваясь под новые вводные. NPR позволяет выстраивать каскад целей, декомпозировать и выстраивать под них проектную деятельность. В системе наглядно видно, какие проекты, программы или спринты на какую цель работают.

В заключение

Разные методологии вполне можно сочетать в рамках одного проекта. Необходимо, чтобы инструменты автоматизации не ограничивали возможности, а поддерживали комбинированный подход, позволяя использовать Waterfall и Agile, когда это целесообразно. Такая система создаст удобное рабочее пространство для каждого участника команды, позволит эффективнее реализовывать проекты и сделает бизнес более гибким и адаптивным.