Практика показывает, что во многих проектах, особенно работающих по методологии Agile, традиционный подход с полноценными выделенными шагами по идентификации, анализу, планированию, мониторингу и контролю рисков, не пользуется популярностью.
В сфере управления проектами в компании Orion Innovation я применял разные практики и сформулировал несколько выводов, которыми хотел бы поделиться.
Думаю, что многие пренебрегают процессом управления рисками, так как не понимают зачем уделять ему отдельное внимание и время. Кто-то может парировать, что вы просто не умеете готовить реестр рисков и на его обновление требуется совсем немного усилий, «минут 10». Так может быть и есть в небольшой сплоченной команде, в которой все друг друга хорошо понимают. Однако нужен ли формальный реестр рисков для такой команды? В большинстве же случаев эта активность, выполняемая по запросу сверху, превращается в нудный и затянутый процесс, в котором непросто увидеть пользу.
Обычно такой процесс выстраивается вокруг risk register, регламентирующего правила работы с рисками. Насколько нужен такой артефакт в его классическом виде и нельзя ли его упростить?
В первую очередь, реестр рисков выполняет функции актуализации и контроля статуса рисков. Актуализация рисков необходима для того, чтобы все участники и заинтересованные лица имели одинаковое представление о списке потенциальных проектных проблем. При этом важно, чтобы он был сформирован в порядке приоритета или рейтинга риска. Определение приоритета обычно происходит путем заполнения таких атрибутов как вероятность (probability/likelihood) & влияние (impact) в реестре рисков, после чего список упорядочивается для того, чтобы выявить самые важные.
Возможно ли адекватно оценить вероятность и влияние для технического риска? На мой взгляд, это проблема того же рода, как необходимость сделать точную оценку для какой-либо задачи. Если известно, как ее делать, то можно точно сказать сколько часов требуется на реализацию. А если нет, то это может быть и день, и два, и более. Поэтому значение этих атрибутов обычно лишь численное выражение ощущений участников проекта, некоторая экспертная оценка.
Имеет ли тогда смысл угадывать эти показатели и не лучше ли сразу формировать список рисков в порядке рейтинга?
При сравнении рисков друг с другом возможно ввести шкалу сравнения, которая облегчит определение рейтинга одного риска относительно другого. Например, для рисков связанных с внешними зависимостями:
если есть достоверная информация, то рейтинг риска меньше;
если есть информация и есть основания считать ее верной (но неподтвержденной), то риск меньше;
если есть информация, но нет оснований ей доверять, то риск больше.
Для рисков, связанных с реализацией технических задач:
если нужно сделать что-то известное (т. е. «мы уже делали это»), то рейтинг риска меньше;
если возможно обобщить и провести с чем-то аналогию (т. е. «это похоже на»), то рейтинг риска меньше;
если что-то неизвестное, то риск больше.
Возможны и другие варианты введения критерия для сравнения рисков.
А есть ли необходимость отдельно контролировать риски в Agile команде?
Как мне кажется, каждый состоявшийся программист или менеджер прекрасно понимают важность того, что на грабли лучше не наступать. При этом многие имеют представление о том, с какими потенциальными проблемами можно столкнуться во время выполнения той или иной задачи в рамках их поля деятельности. Поэтому отдельная функция контроля с помощью реестра рисков возможно избыточна.
Вместо этого действия по митигации рисков можно включить как задачу в бэклог. Например, если в проекте есть риск, связанный с интеграцией внешней библиотеки, то задачу по исследованию сложности интеграции можно включить в бэклог ближайшего спринта. Результаты исследования позволят уточнить и вероятность, и влияние такой задачи на результаты проекта.
Давайте попробуем рассмотреть на примере, как это может работать. Таблица ниже показывает, как можно приоритизировать риски на основе имеющейся информации.
Рейтинг (меньше - важнее) | Риск | Оценка информации |
1 | FW нового устройства может содержать ошибки и потребуется дополнительное время на совместную отладку и исправления. | Нет информации, сколько ошибок может быть в FW. |
2 | Возможно для тестирования релиза нам не хватит оборудования. | Есть часть необходимой информации, т.к. например известно сколько оборудования у нас есть. |
3 | Время на разработку нового функционала может потребоваться больше чем оценили, т.к. есть только скетчи UI/UX. | Есть часть необходимой информации в виде скетчей. |
4 | В результате нагрузочного тестирования может потребоваться оптимизация запросов к БД. | Если мы разрабатываем бэкэнд, то лучше понимаем последствия внесенных изменений. |
Для митигации этих рисков в бэклог можно добавить следующие задачи:
разработать тест-планы и провести тестирование на совместимость устройства с бекэндом, чтобы своевременно выявить возможные проблемы;
разработать симулятор или эмулятор;
разработать подробные макеты экранов интерфейса;
в такой формулировке риск получается в статусе мониторинга до завершения тестирования, а если с ним что-то нужно/можно сделать до этого, то это понятно и без формальных записей в реестре.
Дополнительным преимуществом такого подхода будет то, что функции контроля и обновления информации по рискам будут выполняться автоматически, по результатам спринта.
Выводы
Применение изложенных выше идей может позволить заменить классический реестр рисков простым списком рисков. Во многих проектах, где мне приходилось работать, такое упрощение происходило естественным путем. Было бы интересно узнать, насколько эти идеи соответствуют опыту других пользователей Хабра. Пишите в комментариях, приходилось ли вам упрощать ваш реестр рисков и как.
Отдельно хотел бы отметить, что данный пост посвящен только проектным рискам и не касается организационных рисков, управление которыми нуждается в отдельном анализе.