РискивAgile-проектах.Часть1

Несомненно, тема рисков – одна из самых сложных и интересных в проектном управлении. А тема рисков в  Agile-проектах интересная вдвойне.  Именно поэтому в этом году два своих доклада на конференциях (Agile Days 2013 и Форум PMI 2013) я посвятил особенностям управления рисками в Аджайл проектах. Если на первой конференции я рассказывал больше о практических инструментах (см.презентацию), на второй я остановился на принципиальных различиях в подходах к работе с рискам (см.презентацию). Поскольку темы вызвали большой интерес,  но не все смогли послушать доклады – я решил скомпилировать оба доклада в небольшую статью.

Риски? Никогда не слышал

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

Любой проект связан с неопределенностью, рисками и возможностями. Простите за штамп – но согласно исследованию Standish Group – 66% проектов находятся на грани рисков (т.е. под угрозой сроки, бюджет, качество – другими словами Успех проекта), а 60% из них будут провальные.

Один из основных процессов – Управление рисками проекта – имеет в традиционном подходе довольно строгую последовательность действий, присутствующих на всех стадиях его жизненного цикла:

• Планирование
• Идентификация
• Анализ
• Реакция
• Мониторинг и контроль

Однако, не смотря на всю строгость, с рисками в проектах на практике – просто беда. Попробую порассуждать почему.

Во-первых, как правило менеджеры проектов (далее ПМ) тратят много времени в начале проекта на попытки предсказать и идентифицировать ВСЕ возможные риски. И потом смело про них забывают. И “хорошо проработанная” матрица рисков становится предметом истории.

Во-вторых, “предсказания” ПМ-а – остаются только предсказаниями ПМ-а. Спросите команду – а знает ли она про риски? Для нее это скучно, академично и никак не интегрировано в жизненный цикл проекта.

Что в результате? А в результате – негативные воздействия, разные в частности, но во многом общие для большинства ИТ-проектов:

• Низкое качество (а в классике это переменная, к сожалению) – корневая причина провала многих проектов. Это разрушает продуктивность команд. Команды начинают жить с одной мыслью – только не трогать старый код. Дефекты копятся и копятся – и нет вариантов, как выйти из это ситуации.
• Рост бюджета – проект уже выбрал все доступные ресурсы, но все еще не закончен. И проекты становятся очень дорогие.
• Отложенная поставка – не успеваем реализовать проект в рамках предполагаемого времени. Многие проекты – очень чувствительны к срокам, и нарушение автоматически ведет к потери прибыли, места на рынке и даже штрафам.
• Разработка продуктов в рамках согласованных сроков-ресурсов-качества, которые к моменту готовности становятся никому не нужны.

Это в классическом подходе. А что же Agile? Как известно многие скептики считают, что Agile проекты недокументированные, не планируются, полны хаоса и анархии. И уж конечно, там нет места Управления Рисками. В Agile нет менеджера проектов, который отвечает за управление рисками, а раз нет, то нет и рисков. И часто, начиная мега-проект ХYZ в своей организации, мы говорим – он такой ВАЖНЫЙ, что на нем применять Agile слишком рискованно.

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

Часть 1. Почему в Agile рисков “нет”

Прежде всего я хотел бы остановиться на основных принципах, отличающих гибкие подходы к управлению рисками от традиционных:

• Приоритезация – умение фокусироваться на наиболее Ценных требованиях для клиентов
• Открытость и прозрачность
• Ограничение незавершенной работы – необходимость минимизировать количество одновременно выполняемых задач.
• Управление размером “пакетов”  – основа реагирования на изменении в наших проектах

Далее рассмотрим – как эти принципы  работают и чем они отличаются от классической модели управления рисками.

Как приоритезация помогает работать с рисками

Итак, обо всем по порядку.  Как известно (опять благодарность Standish Group) – 45% реализованных требований в ИТ-проектах никогда не используются. Это как строить дом, в левое крыло которого никто и никогда заходить не будет. Зачем нам такой дом? Более того, работа надо требованиями, которые несут низкую Ценность, влияет на мотивацию и моральный климат в команде. А доставка Ценности откладывается (иногда навсегда).

В Agile приоритезация  – это ключевой принцип, позволяющий ранжировать требования таким образом, чтобы в проекте мы начали реализовывать наиболее ЦЕННЫЕ – первыми. Как приоритезация влияет на риски:

• Приоритезируя требования – мы фокусируемся на самых важных в данный момент для клиента.
• Для коммерческих продуктов мы можем реализовать минимальную ценную часть продукта (MVP) для проверки рынка. Это позволит нам быстрее сделать корректировку курса или направления движения (т.н. Pivot) или вообще перестать работать в этой нише.
• Реализуя MVP мы можем передать это в руки заказчику, получить обратную связь (что используется для переоценки остальных требований).
• Согласно правилу Парето 80% ценности продукта содержится в 20 % требований. Если мы реализуем 20%, то повышается вероятность доставить что-то Ценное, при этом не увеличивая  бюджет.
• Регулярная переоценка позволяет в каждом цикле корректировать “направление” проекта.

“Отсутствие прозрачности приводит к недоверию и глубокому чувству незащищенности” Далай Лама

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

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

Что является примерами таких инструментов:

• информационные радиаторы команды
• канбан-скрам-доски
• визуализация митингов, мероприятий (от планирования до демо и ретроспектив)

Сделайте ваши проекты открытыми!

Многозадачность: почему проекты опаздывают

Не секрет, что многие проекты страдают регулярным переключением сотрудников между задачами. Мы любим использовать эксперта Петю на 25 % в одном проекте на 35 % и остаток времени в третьем. И на самом деле – Петя  работает 20 %,  а остальное время тратит на переключение из проекта в проект.

Во многих Agile фреймворках мы управляем количеством незавершенной работы:

• Количество работы ограничено временным интервалом (спринты) в Scrum
• WIP в Канбане
• Команда не берет работы больше, чем может сделать за это время
• А участники команды работают вместе – чтобы  очередное требование было  реализовано, протестировано, готово к перемещению , и только потом берутся за другое.

Ограничение одновременно выполняемых задач приводит к сокращению незавершенной работы – это еще один из принципов минимизации рисков. В этом случае мы воздействуем на группу рисков, влияющих на Качество и Срок проекта.

Почему размер имеет значение

Основа уменьшения чувствительности наших проектов к изменениям – уменьшение размера поставляемых партий (размеров релизов). В ИТ проектах принято считать – что весь проект это единое, которое может поставляться только единым моментом.

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

Уменьшение размера поставляемой части позволяет нам управлять Ресурсами проекта:

• Быть более продуктивными
• Уменьшить вариативность работы
• Более чаще инспектировать готовое

Работая инкрементально, мы уменьшаем количество переработок, получаем быстрее обратную связь от пользователей и клиентов. Это позволяет нам корректировать и уменьшать количество ошибок.  А главное – минимизировать последствия рисков, связанных с Качеством, Ценностью продукта и Сроками проекта.
Продолжение следует…