Управление рисками... А мне оно надо 🤬

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

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

О том, как управлять влиянием этих рисков- мы и поговорим сегодня.

На самом деле, не открою какой-то космос – техника очень хорошо описана в BABOK (10.38 - Risk Analysis and Management). Но на практике вижу, что не только менеджеры, но даже аналитики (для которых это стандарт - как учебник) не используют технику. Многие ошибочно считают управление рисками чем-то скучным, рутинным, бесполезным, формальным. Хотя на деле это очень эффективный и вовсе не сложный инструмент.

Кейс

Представьте, что подрядчику нужно заменить целую пачку связанных между собой продуктов, (например, Office, Attlassian..) – давайте для простоты называть их платформой. И эту платформу нужно интегрировать в бизнес и корпоративную архитектуру заказчика.

Здесь можно выделить 3 ключевые группы стейкхолдеров:

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

Особенности кейса и его проблема:

• нет ответственного за конечное видение продукта - наблюдается коллективная безответственность по всем вопросам;
• но так как заказчику нужно ощущение контроля - вместо фокуса на результате заказчик "контролирует" подрядчика в процессе, т.е. занимается микроменеджментом: проверяет, соблюдаются ли сроки, сколько фич и когда будет поставлено, уложились ли в бюджет и пр.

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

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

Далее мы с вами пойдем по шагам. На входе - кейс, описанный выше. На выходе у нас получится четкий лог рисков с планом дальнейших действий.

Шаг 1. Собираем вводные

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

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

Шаг 2. Создаем первичный лог рисков

Затем эти риски группируем по принципу схожести, удаляем дубликаты – и все это заносим в таблицу. Эту работу вполне можно сделать силами одного миддл- или даже джун-аналитика.

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

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

• угроза (условие) - то есть при каком условии риск "сыграет";
• последствие - то есть что в таком случае произойдет, какими будут последствия.

В нашем примере ситуация получается следующая: 

Первичны лог рисков: угроза и последствия

А далее, представьте, что у нас не 4 риска, а все 20-30. И описаны они, как правило, чуть более подробно (это здесь я упростила, чтоб легче было понимать суть работы).

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

Шаг 3. Оцениваем вероятность возникновения

Давайте начнем с оценки вероятности. То есть задаем себе вопрос: какова вероятность, что угроза (условие) реализуется? (заметьте, мы сейчас не оцениваем силу последствий)

• Очень часто вероятность оценивают по ее степени: низкая, средняя, высокая, критичная. Но здесь у команды должно быть одинаковое понимание, что значит «высокая», или что значит «критичная» и где между ними граница. 
• Чуть проще оценивать вероятность в процентах или в баллах: например, 70% или 7 из 10.
• Бывает, что нам проще договориться об оценочной шкале значений, типа: точно нет, скорее нет, равновероятно, скорее да, точно да.

Возможные шкалы для оценки вероятности риска

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

Оценка влияния риска

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

Например, в нашем кейсе ситуация может выглядеть так:

• Архитектор говорит, что риск 1 (об отсутствии понимания целевой архитектуры всей платформы) приоритетнее, потому что он коренным образом влияет всю архитектуру
• Продакт считает, что риск 2 (о неверно определенных приоритетах по mvp) важнее, потому что это пользователь не сможет пользоваться продуктом, что повлечет за собою сложности с дальнейшим финансированием
• Дизайнер считает, что риск 3 (об отсутствии единого UX) крайне важен, т.к. пользователям будет неудобно и мы получим негативную обратную связь
• Аналитик говорит, что если реализуется риск 4 (о непроработанности НФР под заказчика), то все старания насмарку: мы получим такой урон репутации, что вряд ли Заказчик еще захочет работать с нашими продуктами.

 ну и так далее.

Оценка важности (приоритета) риска

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

Вопрос в том, какие категории стоит выделить для оценки. Есть ли "готовые рекомендации"?

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

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

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

Измерение влияния риска

Здесь нет единого универсального ответа. Если мы действительно хотим сделать инструмент рабочим для быстрых и объективных оценок – придется однажды потратить время и договориться с командой о единой шкале измерения по каждой зоне влияния.

Влияние на СКОУП проекта

Например, в чем мы можем оценить влияние на скоуп проекта?

• Первое, что приходит на ум - использовать обобщенные оценки, типа Нулевое - Низкое - Среднее - Высокое - Критичное. Но при таком подходе ждите холиваров – что значит это Низкое или Среднее?
• Также нехорошо получится и с процентами: что значит Влияние на 40%? - вообще бессмыслица какая-то);
• Можно попробовать измерить в количестве функций или фич, на которые влияет риск. Притом, это могут быть как абсолютные, так и относительные оценки - в зависимости от того, что реально важно вам для оценки рисков.. Например:
• Влияет на 5 фич (если важно понимать, сколько именно единиц скоупа подвергнутся влиянию)
• Влияет на 10% всех фич проекта (если нужно понимать в объем изменения относительно всего скоупа проекта)
• Аналогично можно изменять влияние на бизнес-процессы Заказчика. Подумайте, если скоп изменится на 2 бизнес-процесса или на 20% бизнес-процессов - это много или мало? Стоит ли взять относительные или абсолютные оценки?
• Иногда имеет смысл оценивать степень влияния на техническую реализацию. Например, насколько риск влияет на актуальность архитектуры для реализации НФР, придется ли менять стек или технологии, какой объем бэкенд изменений потребуется..
• Лично мне нравится метод «от противного»: смотрим, что случится с проектом или бизнесом клиента, если пренебречь последствиями от 100% воздействия риска: возможно, на общем успехе это вовсе не скажется. А может быть и наоборот - бизнес-предназначение продукта вообще станет недостижимым.

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

Варианты измерения влияния на скоуп проекта

Влияние на время реализации

Аналогично – можно использовать разные шкалы для оценки влияния на длительность или сроки.

• Можно измерять изменение общей длительности проекта – в некоторых абсолютных единицах (например, в днях, неделях, спринтах, кварталах) или в относительных (например, проект станет на 20% длиннее)
• Иногда в контексте времени имеет смысл определять изменение трудозатрат (человеко-дни, командо-спринты и пр.), которые потом уже можно преобразовать во время с учетом переменного количество ресурсов (добавили людей и сделали за то же время. Актуально только в том случае, если есть возможность расширять ресурсы)

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

Варианты измерения влияния на время реализации проекта

Влияние на качество продукта

Следующий вопрос: в чем измерим влияние риска на качество продукта?

Пару лет назад, на конференции Analyst Days публика нагенерила целую пачку идей, иногда очень даже веселых )) Давайте посмотрим с вами некоторые из них.

Результаты бреqнтшторма зрителей с конференции Analyst Days

• Первое, что приходит на ум: оценки и рекомендации пользователей, т.е. разные способы замера обратной связи
• Можно оценить влияние риска на качество проекта в эффективности пользовательских путей, или покрытии edge-cases и альтернативных сценариев
• Другая парадигма – прикидывать количество потенциальных дефектов на проме или пре-проме. Однако, напомню, что мы еще говорим проактивной оценке риска, а не измерении реальных показателей, поэтому этот вариант я бы не стала использовать
• конечно, когда мы говорим о качестве – как не подумать о реализции НФТ? Ведь они и есть прямые показатели качества. Какую бы классную функциональность не реализовали, если она не выдерживает нужной нагрузки, например, - какой от нее толк…

Варианты измерения влияния на качество конечного продукта

Влияние на репутацию подрядчика

А теперь подумайте, в чем можно измерить влияние на репутацию подрядчика?

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

Снова говорим о том, что можно использовать разные шкалы – в зависимости от того, что вам важно в репутации:

• Если важны бизнес-отношения с заказчиком или оценка топ-менеджмента – измеряем влияние на них;
• Если важно отношение конечного пользователя – измеряем его;
• Если важные какие-то официальные рейтинги или отзывы на внешних ресурсах – измеряем их;

Варианты измерения влияния на репутацию подрядчика

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

Шаг 4. Калибруем шкалы

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

• Определить те зоны влияния, которые имеют значение конкретно в вашем случае. Например: границы проекта, объем работ, качество реализации, длительность проекта, репутация подрядчика, бизнес клиента, стоимость проекта и тп. В таблице ниже - это заголовки столбцов.
• Определить единицы измерения для оценки по каждой зоне. Например:
• Влияние на границы проекта оцениваем относительно того, насколько функционал обеспечивает заложенную бизнес-ценность;
• Влияние на объем работ - в количестве командо-дней;
• Влияние на стоимость - в процентах;
• и так далее. Полный пример - в таблице. Главное - помним, что все оценки должны иметь реальный смысл для проекта, не быть гипотетически.
• Далее нам нужно определить значения этим шкалам и откалибровать их – то есть договориться, что понимаем под низким, средним, высоким или критичным влиянием на ту или иную зону. Это очень не тривиально, и обычно сопровождается горячими дискуссиями. Зато помогает всем договорится о единых правилах, и дальнейшие воркшопы по оценке рисков простыми и быстрыми.

Калибровка шкал по всем зонам влияния риска

Практическая сложность в том, что эти результате эти шкалы должны быть сопоставимы: низкое влияние на границы проекта должно быть сопоставимо с низким влиянием на качество, с низким влиянием на длительность и так далее - чтоб не было оговорок типа "да, и на границы и на время влияние низкое, но влияние на время - важнее…"

Ну и далее нам же нужно как-то эти риски сравнивать. А как сравнивать понятия (ведь с таблице выше мы оперировали именно понятиями).

Я предлагаю для этого перевести качественные значения в количественные. То есть - в цифры. Градация цифровых шкал может быть разной:

• кто-то использует подряд натуральные числа 1, 2, 3, 4..
• кому-то больше нравится ряд фибоначчи, где каждое последующее число это сумма предыдыщих: 1, 1, 2, 3, 5, 8

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

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

Но в любом случае, инструмент будет для вас реально рабочим только если бы хорошо его откалибруете. Иначе это будет активность ради активности, и она опять превратится в формальность.

Шаг 5. Оцениваем риски

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

• Внести все риски в таблицу и разложить их на угрозы и последствия;
• Обозначить столбцы оценки вероятности и зон влияния, а также ограничить выбор значений для рисков;
• Прописать формулы для подсчета итогового влияния и уровня (об этом чуть ниже);

В итоге, мы получаем что-то похожее вот на такую таблицу:

Оценка рисков в цифре

• Вы видите слева описание риска: т.е. угрозу и последствия;
• В самой левой колонке с цифрами – оценки вероятности возникновения риска;
• Далее заголовки, не выделенные рамками – это зоны влияния риска;
• Сумма баллов по каждой строке подсчитана в столце «Влияние».

По столбцу "Влияние" мы видим, что на данном примере потенциально самое большое влияние окажет второй риск (про MVP), а самое малое – первый и четвертый – про архитектуру и НФТ. Однако, это еще не говорит нам о том, что второй риск важнее первого и четвертого. Как раз наоборот.

У этих рисков – разная вероятность появления. А итоговый уровень риска – это произведение вероятности на степень влияния. И в итоге в правой колонке мы видим, какие риски имеют наивысший уровень.

Таким образом, мы выстроили наши риски в порядке их реальных приоритетов.

Помните, что в реальном проекте у вас будет не 4, а несколько десятков рисков. Вы врядли сможете работать со всеми (я имею ввиду не оценить все, а предусмотреть план Б для каждого риска в таблице). И вполне разумно в первую очередь заниматься теми рисками, которые имеют наивысший уровень. Благо, теперь нам не нужно спорить, какой риск важнее. У нас есть числовые показатели. 

Шаг 6. Определить стратегии

И после выявления этих наиболее приоритетных рисков - нужно определить стратегию работы с каждым риском. Стратегий всего 5:

• Уклониться
• Делегировать
• Снизить
• Принять
• Увеличить

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

Шаг 7. Определить план действий 

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

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

А вот после, когда все планы определены - прописываем конкретные шаги и назначаем ответственного как за каждый риск целиком, так и за каждый конкретный шаг.

Стратегии работы с рисками

Например, для риска по приоритетам MVP, мы можем определиться со следующим:

• Выбираем стратегию «снизить», для этого сделает пилотный запуск на фокус-группе на раннем этапе и заранее заложим ресурсы на изменение приоритетов скоупа mvp после фидбека.
• Чтоб это реализовать, определяет конкретные шаги:
• Аналитику нужно подготовить критерии для формирования фокус-группы, и самостоятельно эту фокус-группу собрать. Сделать это до даты X;
• Дизайнеру нужно до даты Y подготовить пользовательские сценарии;
• Тех-лид должен развернуть пилотную версию и дать к ней доступ фокус-группе. Это сделать не позднее даты Z.

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

Шаг 8. Регулярно обновлять лог рисков

К сожалению или к счастью, но мир не стоит на месте. И риски проекта меняются постоянно: какие-то вы порешаете, но обязательно появятся новые. По рискам будут меняться вероятность и влияние, а значит, и приоритеты.

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

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

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

Заключение

В качестве заключения - напомню вам основные шаги работы с рисками:

• Шаг 1. Собирает вводные
• Шаг 2. Создаем первичный лог рисков
• Шаг 3. Оцениваем вероятность возникновения
• Шаг 4. Калибруем шкалы
• Шаг 5. Оцениваем риски
• Шаг 6. Определяем стратегии
• Шаг 7. Определяем план действий
• Шаг 8. Регулярно обновляем лог рисков

Всем желаю интересной и продуктивной работы с рисками!