Agile для управления проектами

Agile как подход был сформулирован с 2001 году в виде манифеста. И уже более 20 лет будоражит менеджеров компаний. В компаниях употребляется с негативным контекстом, примеры таких упоминаний: «У них там Аджайл, поэтому-то релизы сдвигаются, а люди бесконечно совещаются». Не буду развеивать все легенды и байки про эджайл подход. Хочу рассказать о применении Agile-подхода в проектном управлении.

Проект — это комплекс взаимосвязанных мероприятий с четко определенными целями, сроками и при ограниченных ресурсах.

Три ограничительных фактора — ресурсы, срок, поставленные задачи с четко определенными целями. Каждый фактор можно воспринимать с оговорками: насколько определены ресурсы? Как можно воспринимать диапазоны попадания в срок? Какой процент попадания в цель считается допустимым при завершении задачи? Но можно с уверенностью говорить о том, что если происходит выход за ограничения, проект или признается не выполненным или, что чаще происходит, возникает запрос на изменение границ проекта.

Существует разделение на следующие типы проектов: внутренние, открытые в рамках деятельности компании, и внешние, где заказчиком выступает другая организация. И если для внутренних проектов достаточно часто производится изменение границ проектов, то по внешним проектам компании могут столкнуться со штрафными санкциями.

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

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

К каким конфликтам это может привести:

Избыток менеджерских ролей: Владелец продукта, Менеджер проекта, Скрам-мастер — что ведет к конфликту зон ответственности и влияния.
Нестабильная команда разработки — команду формируют по проектному подходу в формате «половина землекопа» с последующей постоянной заменой. Это привет к снижению ответственности команды за результат, невозможности оценить скорость команды, и, как следствие, отказ от ретроспективного анализа и улучшения командной работы.
Фиксированный срок и объем работ — что приводит к перегрузу команды с последующим ее выгоранием, так как требования разрастаются, а в среде высокой неопределенности сроки обычно оцениваются оптимистично, даже если менеджер проектов умножает все оценки разработчиков на число Пи три раза.
Отсутствие должного уровня коммуникации с заказчиком на ранних этапах производства ценности. В условиях, когда заказчик уже согласовал техническое задание, достаточно проблематично встроить сбор обратной связи в процесс создания ценности. Это влечет за собой высокие риски неверных ожидания на финальной демонстрации продукта.

Все же ценности Agile можно применять и в проектном подходе, но с оговорками:

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

Заказчик совместно с командой может пересмотреть объем работ в пользу наибольшей ценности, таким образом оставаясь в рамках согласованного бюджета или же пересмотреть бюджет. Данные оговорки чаще всего применяются для проектов ориентированных на внутренних заказчиков. Для работы с внешними заказчиками такой подход подразумевает увеличение затрат на получение результата, что приводит или к отказу от использования Agile-подхода, или неизбежный конфликт с исполнителем.

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