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

Оригинал статьи здесь.

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

Проектный риск – (В соответствии с определением 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 проектах мы стараемся непрерывно работать над уменьшением поставляемой партии. В рамках ежедневной работы или в рамках всего проекта — уменьшение размера пакета остается первостепенной задачей.

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

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

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