Несомненно, тема рисков – одна из самых сложных и интересных в проектном управлении. А тема рисков в Agile-проектах интересная вдвойне. Именно поэтому в этом году два своих доклада на конференциях (Agile Days 2013 и Форум PMI 2013) я посвятил особенностям управления рисками в Аджайл проектах. Если на первой конференции я рассказывал больше о практических инструментах (см.презентацию), на второй я остановился на принципиальных различиях в подходах к работе с рискам (см.презентацию). Поскольку темы вызвали большой интерес, но не все смогли послушать доклады – я решил скомпилировать оба доклада в небольшую статью.
Проектный риск – (В соответствии с определением PMBOK) – это неопределенное событие или условие, которое в случае возникновения имеет позитивное или негативное воздействие, по меньшей мере, на одну из целей проекта, например, сроки, стоимость, содержание или качество.
Любой проект связан с неопределенностью, рисками и возможностями. Простите за штамп – но согласно исследованию Standish Group – 66% проектов находятся на грани рисков (т.е. под угрозой сроки, бюджет, качество – другими словами Успех проекта), а 60% из них будут провальные.
Один из основных процессов – Управление рисками проекта – имеет в традиционном подходе довольно строгую последовательность действий, присутствующих на всех стадиях его жизненного цикла:
Однако, не смотря на всю строгость, с рисками в проектах на практике – просто беда. Попробую порассуждать почему.
Во-первых, как правило менеджеры проектов (далее ПМ) тратят много времени в начале проекта на попытки предсказать и идентифицировать ВСЕ возможные риски. И потом смело про них забывают. И “хорошо проработанная” матрица рисков становится предметом истории.
Во-вторых, “предсказания” ПМ-а – остаются только предсказаниями ПМ-а. Спросите команду – а знает ли она про риски? Для нее это скучно, академично и никак не интегрировано в жизненный цикл проекта.
Что в результате? А в результате – негативные воздействия, разные в частности, но во многом общие для большинства ИТ-проектов:
Это в классическом подходе. А что же Agile? Как известно многие скептики считают, что Agile проекты недокументированные, не планируются, полны хаоса и анархии. И уж конечно, там нет места Управления Рисками. В Agile нет менеджера проектов, который отвечает за управление рисками, а раз нет, то нет и рисков. И часто, начиная мега-проект ХYZ в своей организации, мы говорим – он такой ВАЖНЫЙ, что на нем применять Agile слишком рискованно.
Несмотря на огромное количество мифов, гибкие подходы к управлению проектами содержат набор принципов и инструментов для уменьшения негативных воздействий, про которые мы говорили выше.
Прежде всего я хотел бы остановиться на основных принципах, отличающих гибкие подходы к управлению рисками от традиционных:
Далее рассмотрим – как эти принципы работают и чем они отличаются от классической модели управления рисками.
Итак, обо всем по порядку. Как известно (опять благодарность Standish Group) – 45% реализованных требований в ИТ-проектах никогда не используются. Это как строить дом, в левое крыло которого никто и никогда заходить не будет. Зачем нам такой дом? Более того, работа надо требованиями, которые несут низкую Ценность, влияет на мотивацию и моральный климат в команде. А доставка Ценности откладывается (иногда навсегда).
В Agile приоритезация – это ключевой принцип, позволяющий ранжировать требования таким образом, чтобы в проекте мы начали реализовывать наиболее ЦЕННЫЕ – первыми. Как приоритезация влияет на риски:
Увеличение прозрачности и открытости в проекте позволяет уменьшить воздействия рисков, направленных на Качество и Ценность продукта. Проще говоря – без прозрачности мы не можем эффективно управлять рисками и реагировать на любые изменения в проекте.
Прозрачность – это о том как сделать очевидным, наглядным причины, почему мы делаем это работу и зачем мы ее делаем. Она затрагивает все аспекты проекта – для менеджера это одно, для разработчика это другое – но важно поддерживать на всех уровнях.
Что является примерами таких инструментов:
Сделайте ваши проекты открытыми!
Не секрет, что многие проекты страдают регулярным переключением сотрудников между задачами. Мы любим использовать эксперта Петю на 25 % в одном проекте на 35 % и остаток времени в третьем. И на самом деле – Петя работает 20 %, а остальное время тратит на переключение из проекта в проект.
Во многих Agile фреймворках мы управляем количеством незавершенной работы:
Ограничение одновременно выполняемых задач приводит к сокращению незавершенной работы – это еще один из принципов минимизации рисков. В этом случае мы воздействуем на группу рисков, влияющих на Качество и Срок проекта.
Основа уменьшения чувствительности наших проектов к изменениям – уменьшение размера поставляемых партий (размеров релизов). В ИТ проектах принято считать – что весь проект это единое, которое может поставляться только единым моментом.
В Agile проектах мы стараемся непрерывно работать над уменьшением поставляемой партии. В рамках ежедневной работы или в рамках всего проекта – уменьшение размера пакета остается первостепенной задачей.
Уменьшение размера поставляемой части позволяет нам управлять Ресурсами проекта:
Работая инкрементально, мы уменьшаем количество переработок, получаем быстрее обратную связь от пользователей и клиентов. Это позволяет нам корректировать и уменьшать количество ошибок. А главное – минимизировать последствия рисков, связанных с Качеством, Ценностью продукта и Сроками проекта.
Продолжение следует…
Добый день!У вас Ошибка в контенте. Абзац: Низкое качество (а в классике это переменная, к сожалению) — корневая причина провала многих проектов. Это разрушает продуктивность команд. Команды начинают жить с одной мыслью — только не трогать старый код. Дефекты копятся и копятся — и нет вариантов, как выйти из "ЭТО" ситуации. Может "ЭТОЙ"?