Привет!🫂

Сегодня снова возвращаюсь к теме риск-менеджмента. 🗯🗯🗯 Почему? Немного истории: когда я была тестировщиком, а затем тест-лидом, я поняла, что наиболее эффективно организовывать процесс тестирования и планировать работу по тестированию, исходя из и основываясь на рисках. Далее, по мере приближения к проектному управлению, у меня укрепилось убеждение, что управление проектом и есть управление рисками, будь то работа с людьми или процессами. Мы работаем с людьми таким образом, чтобы создать наиболее благоприятную атмосферу, чтобы помочь команде стать самоорганизованной. Это необходимо, чтобы снизить риски провала проекта по причине увольнений или же из-за проблем в рабочей группе. Мы выстраиваем процессы таким образом, чтобы в кротчайшие сроки поставлять наиболее качественный продукт, иначе есть риск потерять деньги/заказчика и т.д. То есть, всё крутится вокруг управления рисками. И каково же моё разочарование, когда я вижу, что почти 100% менеджеров НЕ управляют рисками, у них даже нет списка рисков, нет планов, нет оценок и понимания что важнее решить, и как решать. Это, с моей точки зрения, похоже больше на попытки слепого кутёнка найти мать, которая где-то далеко на улице, в ветренную и дождливую погоду, нежели на управление проектом. Мне непонятно почему так происходит, ведь управление рисками- это не что-то заоблачно сложное, но это то, что реально помогает видеть всю картину целиком и на самом деле управлять, а не плыть по течению, пытаясь выплыть на берег.

📖 Есть много подходов к управлению рисками. Я лично в своём опыте испробовала около 5 различных подходов, и остановилась на близком к тому, что описан в РМВОК (версии 6), но с небольшими изменениями. Процесс управления рисками состоит из следующих этапов, согласно РМВОК (и не только): обнаружение и идентификация рисков → качественный анализ рисков → количественный анализ рисков → планирование реагирования на риски → осуществление реагирования на риски → мониторинг рисков. На этапе обнаружения и идентификации рисков мы составляем список тех рисков, которые видим на текущий момент (или дополняем новыми список существующих рисков). 🗯 Исходя из моего опыта, я выделяю 2 вида рисков: фактологические и не фактологические. К фактологическим я отношу те риски, которые могут произойти по причине наличия какого-то факта. К не фактологическим- те, которые, как мне кажется, могут произойти, но не основаны на фактах. В случае фактологического риска необходимо разделять факт и риск, так как несколько фактов могут приводить к одному риску, или, наоборот, один и тот же факт может приводить к разным рискам.

Например: - факты 1, 2 и 3: 1) отсутствие приоритетов в бэклоге; 2) спринты не имеют цели, то есть команда берет задачи на свое усмотрение; 3) большой объём задач в бэклоге (явно превышающий возможности команды по имплементации к заданному сроку). Риск: поставка будет провалена, так как часть необходимых задач не будет выполнена, но при этом будут выполнены другие (низкоприоритетные задачи). Как результат (уже за рамками проекта), возможно, особенно если заказчик новый, мы рискуем потерять заказчика навсегда, потерять репутацию и т.д. - факт 4: команда последние 3-4 месяца работает с овертаймами по будням и в выходные. Риски, которые тут могут быть: 1) люди начнут увольняться, и мы не сможем найти им замену, как результат, сорвем сроки. 2) люди не начнут увольняться, но качество их работы будет страдать все больше и больше. В итоге мы сдадим некачественный продукт, хоть и в срок. Вероятности у этих рисков разные, как и уровни влияния.

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

Продолжение в комментарии ⤵

21.12.2022

#теория