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

Данная методика основана на рекомендациях PMBoK. Также при выкристаллизовывании методики учитывались знания и опыт, полученные мной на проектах в интересах Национального Центра Управления в Кризисных Ситуациях МЧС России. Методика апробировалась на проектах МЧС России, ГИБДД МВД, финансовых организаций и организаций-разработчиков программного обеспечения.

Недавно посмотрел фильм «Пол: Секретный материальчик», там был разговор про фисташки. Что-то я задумался сейчас и понял, что покупка фисташек это своего хороший тренинг по управлению проектами для новичков.

	Да, это же 50 лет гарантированной жизни!
	Нет, уж лучше как сейчас, мне повезёт!

Проголосовало 627 человек. Воздержалось 168 человек.

В Deadline, Том Демарко пишет о том, что для управления проектом, достаточно управлять его рисками. Действительно, всю работу ПМа можно свести к одному — борьба с рисками, которые могут помешать проекту завершиться в срок, в бюджет и с необходимым уровнем качества. Если, по какой-то причине, рисков в проекте нет, то нет и предмета работы ПМа.

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

“In the middle of difficulty lies opportunity”
Albert Einstein

В книге [1] (список источников указан внизу) приведены уровни зрелости компаний и организаций с точки зрения управления рисками. Выделяют 5 уровней или стадий:

• Problem stage — когда работа с рисками не ведется до тех пор, пока они не станут проблемами
• Mitigation stage — когда людям знакомо понятие «риск», однако никто не знает, как управлять рисками на регулярной основе (концепция управления рисками была им представлена, но пока в очень ограниченных объемах). Зачастую единственной стратегией борьбы с рисками является уменьшение вероятности его появления
• Prevention stage — когда управление рисками становится активностью команды в целом, в не только задачей менеджмента (проекта, отдела, компании); в процесс вовлекается все больше и больше заинтересованных людей, которые могут идентифицировать риски, однако их количественные оценка пока вызывают определенные трудности. Данная стадия является поворотной точкой от реактивного к проактивному методу управления рисками
• Anticipation stage — данная стадия характеризуется сбором и анализом метрик, для того чтобы предугадывать будущие проблемы и предсказывать определенные события, связанные с проектом. В процесс управления рисками вовлекается и заказчик (клиент), что дает возможность более аккуратно проводить количественную оценку рисков, а также верно расставлять приоритеты
• Opportunity stage — данная стадия представляет позитивное видение процесса управления рисками, когда в процесс вовлечены все заинтересованные стороны (менеджеры, проектная команда, представители заказчика). На данной стадии каждый риск трактуется (может трактоваться) еще как и некоторая возможность. Все осознают эти возможности и связанные с ними риски и могут выбирать различные пути движения дальше, находя компромиссы между уровнем риска и новыми возможностями

Понятно, что разные компании находятся на разных уровнях зрелости. На мой взгляд, моя компания сейчас находится где-нибудь между Anticipation и Opportunity уровнями зрелости, но мы продолжаем работать ;) А в какой стадии находится ваша компания?

Вводная информация по управлению рисками

К теме управления рисками я решил обратиться по нескольким причинам:

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

Однако стоит помнить следующее – управление рисками в любой сфере человеческой деятельности, на мой взгляд, это все-таки только прикладная дисциплина, которая предоставляет общие и практические рекомендации.

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

Определение риска

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

Risks are schedule delays and cost overruns waiting to happen (by Peter Kulik)
Risk is the possibility of suffering loss (SEI, Dorofee 96)

Также следует понимать основное отличие понятия риска от понятия проблемы:

• риск это некоторое событие, которое может случиться в будущем и может привести к определенным потерям (снижение качества продукта, перерасходование бюджета, задержка сроков либо полной неудачи проекта)
• проблема же – это событие, которое уже случилось. Риски превращаются в проблемы, если с ними не работать

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

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

Вчера Вы отправили клиенту по почте первый прототип с Вашими комментариями. А сегодня вас в ящике должно ждать письмо о том, что…