Работая над digital-проектом, вы всегда рискуете. Как минимум — не уложиться в сроки и бюджет. Рано или поздно риск сработает, и у вас есть выбор, как жить с этой информацией: игнорировать и надеяться, что вам прилетит в меньшей степени, или взять риски под узду и начать управлять ими.

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

Хотя, напоминаем, риски существуют везде и всегда. Поэтому мы попробуем просто и понятно (насколько это возможно в рамках данной темы), рассказать вам о риск-менеджменте, и как его использовать в digital-проектах.

Начнем с того, что риск-менеджмент — это процесс из 5 этапов.

1. Поиск основных рисков.
   
2. Оценка их важности.
   
3. Поиск способов снижения риска.
   
4. Оценка стоимости этих мер.
   
5. Оценка целесообразности мер при данной степени риска.
   
   

Информация, полученная на каждом этапе, вносится в реестр рисков.

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

В составлении реестра рисков могут принимать участие руководитель проекта, команда, и, при необходимости, даже заказчик.

В результате вы получите таблицу со следующими полями:

• причина;
  
• описание риска;
  
• важность;
  
• вероятность;
  
• последствия;
  
• оценка потерь;
  
• стратегия;
  
• основной сценарий;
  
• запасной сценарий;
  
• ответственный (за управление риском);
  
• случился / не случился (заполняется постфактум).
  
  

В ней будет вся необходимая информация, чтобы управлять рисками. И сейчас мы расскажем, как ее получить.

Риски бывают более или менее ожидаемые и совсем неожиданные. По-научному — известные и неизвестные.

Известные риски (в некоторых источниках — контролируемые) бывают там, где есть информация: если вы уже работали в похожих условиях и знаете, где ружьё может выстрелить. Или слышали об этом. И понимаете, что делать с последствиями.

Пример: вы работаете над интернет-магазином, и по опыту знаете, что на этапе интеграции с 1С заказчика бывает много проблем и проволочек. Поэтому закладываете на них дополнительное время и дарите бутылку коньяка 1С-нику.

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

Пример: Туристические компании и зима 2015 года. Внезапно Крым стал нашим. Подскочили доллар и евро, перестали продаваться путевки за рубеж, а уже купленные стали сдавать. Туристическим компаниям эта ситуация принесла кучу проблем и убытков.

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

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

Когда вы осознаете масштаб возможных (и не очень) рисков, вам предстоит выбрать из них те, которыми имеет смысл управлять. Потому что пытаться подстелить соломку всюду — дорого, неэффективно, и вы все равно не предусмотрите ВСЁ. Чтобы выбрать наиболее перспективные риски, нужно оценить их важность.

Важность риска можно получить несколькими способами. Первый и самый простой — перемножить вероятность и последствия риска.

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

Когда вероятность и последствия оценены, руководитель перемножает их и получает показатель важности риска. Максимум получится 100 баллов.

Второй способ рекомендуется в PMBok 5 — это матрица вероятности и воздействия. Выглядит она так.

Здесь нет баллов и школьного умножения, и вообще процесс немного сложнее.

В матрице нужно определить не только вероятность возникновения риска по шкале от 1 (100% произойдет) до 0 (не случится никогда), но и тональность последствий — негативную или позитивную. И найти соответствующий показатель на нижней шкале.

После нужно определить уровень воздействия риска: очень низкий, низкий, средний, высокий или очень высокий. Найти соответствие на шкале слева. И после — найти ячейку на пересечении уровня воздействия и вероятности. В ней-то и будет показатель важности риска. Чтобы вы сразу понимали, хороший этот показатель или плохой, ячейки раскрашены в три цвета. Зеленый означает низкий уровень риска, желтый — средний уровень, и красный — высокий уровень.

Если важность одних рисков вы определяете по первому способу, других — по второму, не забывайте переводить показатели матрицы в 100-балльный формат :) Это нужно, чтобы потом без проблем отсортировать риски по важности.

Важность рисков определяется для того, чтобы понимать, на что реагировать в первую очередь.

Есть четыре стратегии работы для снижения рисков.

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

Передача риска. В случае передачи вы делите последствия риска (как плохие, так и хорошие) с другой стороной. Как вариант, с заказчиком или подрядчиком. Так можно поступить в случае, если повлиять на риск невозможно. Таким может стать, например, приостановка проекта из-за несвоевременной оплаты счетов.

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

Снижение риска. Цель этого способа — уменьшить вероятность возникновения рисков и смягчить их последствия. Начинать снижение рисков лучше на старте проекта. Потому что чем дальше, тем дороже и сложнее управлять риском.

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

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

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

В принятии можно действовать активно или пассивно. Пассивно — просто зафиксировать, что делать, когда угроза превратится в реальность. Активно — установить резерв на возможные потери: дополнительное время или деньги.

В реестре рисков в столбец «Стратегия» впишите способ снижения. Сделать это нужно для каждого риска. И, исходя из стратегии, придумайте и запишите основной и запасной сценарий действий на случай, если риск сработает.

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

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

На этапе, когда вы оценили важность риска, выбрали способ его снижения и расписали подробные сценарии, пора проанализировать все и понять, сколько это будет стоить.

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

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

И давайте разберем на примере. Вспомним наш реестр рисков.

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

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

Умножаем 5 и 7, чтобы получить важность. Получается 35 из 100 — даже меньше половины. По матрице вероятностей и воздействия мы в зеленой зоне.

В данной ситуации мы легко можем оценить риск в деньгах. Размер неустойки — 1% от суммы контракта в день, 1000 рублей. Итого в случае сработавшего риска мы теряем 5000 рублей.

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

Так стоит ли ради 5000 рублей заморачиваться и перед планированием отправлять разработчика на обследование в больницу? Мы для себя решили, что, так как важность риска небольшая — всего 35 — то не стоит. Поэтому наша стратегия в данном случае — принятие. Основной сценарий — пока ничего не делать и принимать меры только в случае, если разработчик действительно заболеет.

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