Работая над 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 — то не стоит. Поэтому наша стратегия в данном случае — принятие. Основной сценарий — пока ничего не делать и принимать меры только в случае, если разработчик действительно заболеет.

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

Василий Вишняков
Генеральный директор интернет-агентства Bquadro

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

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

Константин Нефедов
Управляющий партнер digital-агентства «ДАЛЕЕ»

Безусловно, процесс управления рисками происходит в каждом проекте. В каждом проекте у нас за этот процесс отвечает прожект-менеджер.

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

Алексей Титов
Коммерческий директор, компания «Garpix»

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

В целом, как уже правильно сказал автор статьи, в digital–среде, условно говоря, есть два риска. Риск не уложиться в сроки и риск не уложиться в бюджет. Но при этом все оставляют за скобками риск того, что твоя команда вообще не сможет выполнить проект в плане работы.

В нашей компании действует своя система управления рисками. Когда к нам обращается клиент, у нас всегда есть двойной фильтр на работу с ним.

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

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

Из этого вытекает следующее. Мы, как сотрудники отдела продаж, получаем информацию следующего характера. 1. Мы точно знаем, как решить технологическую проблему клиента. 2. Мы видим, можно ли с ним сработаться, выясняем, говорим ли мы с ним на одном языке, оперируем ли одними понятиями.

Если эти два фактора сходятся, мы не видим предпосылок для возникновения сложностей. Если эти два риска пройдены, проект переходит в стадию подписания договора и дальнейшего развития.

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

Кирилл Чистобородов
Генеральный директор MINISOL

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

Для уменьшения рисков мы на этапе прототипирования и написания ТЗ:

1. Делим работу на этапы.

2. Прописываем зону ответственности и дедлайны для каждого этапа как для исполнителя, так и для заказчика.

3. Доносим эту информацию до ответственных лиц.

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