Риск, который ты не заметил, и митигация, о которой думаешь поздно (спойлер: никогда)
Сначала про главное. Риск - это не пугалка, которая всегда страшит. Это событие, которое может случиться (тут самая важная часть - может и не случиться) и если случится - повлияет на сроки, бюджет или содержание проекта. Может в плохую сторону, редко в хорошую. Но я обычно считаю только плохие, чтобы не расслабляться. (Сорри за субъективизм «плохого/хорошего»). Даже тут многие РМ совершают ошибку, они думают о рисках, когда те уже реализуются и появляется реальный сдвиг срока.
Откуда берутся риски? Из опыта или как говорят кандидаты на собесе - эмпирически. Из того, что я уже было в опыте: как разработчик заболел перед релизом. Не учли нагрузочное тестирование. Архитектор ушёл в другую компанию. Внешний поставщик не привёз лицензии. Короче, риски там, где все течет - рисков нет в вакууме.
Когда я понимаю, что риск есть? Когда появляется триггер. Это такой сигнал, который подсказывает: что-то идёт не по плану, хотя само событие ещё не случилось. Например, разработчик говорит: «Я, наверное, не успею, там сложнее, чем казалось». Не факт, что не успеет. Чаще, конечно, сам разработчик не приходит и обычно нужно уточнять самостоятельно «Если риск не успеть в срок/есть ли ощущение, что задача сложнее, чем планировалась?». Или в команде резко выросло количество багов на этапе, где их обычно мало. Или инициатива, которая в промежутке времени должна быть на середине пути по выполненным задам, сейчас только в самом начале. Триггеры - это симптомы, сигналы для РМ. Я их собираю и смотрю, куда клонит. При том, что у отдельной команды триггеры могут быть иными, тут главное «чувствовать» команду (ну и как минимум лида).
Теперь про митигацию. Красивое слово, означающее «я что-то предприняла, чтобы снизить вероятность риска или его последствия». Делать её надо не когда риск случился, а когда ты его только заподозрил (я называю это чуйкой, как только чуйка сработала).
Примеры:
📌Если на проекте 1 архитектор и даже если он уходить не собирается, это узкое место и риск, нужно страховаться сразу, передавать часть знаний другим ребятам из команды.
📌Или знаешь, что определенные смежники тормозят с задачами и задерживают весь проект. Нужно сразу поставить статус-встречи и трекать зависимости/проблемы/нехватку требований и ход работы.
📌Заподозрил, что разработка может сделать не то - разбить задачу на мелкие куски (этапы) и договорится о досрочных демо, чтобы быстрее понять, что это именно то, что нужно заказчику.
Когда я понимаю, что риск уже случился? Тогда, когда триггер превратился в событие. Разработчик сказал: «Всё, я точно не успеваю, надо сдвигать». Архитектор написал заявление. Разработчики уже сделали все не так, как необходимо. Это уже не риски, это проблемы. И митигация тут не нужна, нужен кризис-менеджмент (это уже другая история). План Б. Или план В. Или план Г, когда уже всё плохо.
Самое мое любимое: митигация - это не панацея. Она не убирает риск полностью. Она делает его менее опасным. С рисками нужно работать в начале проекта и на протяжении жизни проекта, после проекта на внедрении. Это динамический инструмент. И еще риски надо пересматривать. Минимум раз в две недели. Потому что вчера низкая вероятность сегодня стала высокой. А сегодняшнего риска вчера ещё не было. Если вы составили список рисков на старте и забыли - вы не управляете рисками. Огорчу вас, вы просто делаете вид.
И самое любимое, часто задаю этот вопрос на собеседовании. Были ли у тебя риски на проекте? Расскажи, самый запоминающийся?
