Управление рисками проекта - задача, которая чаще всего возлагается на менеджера проекта либо владельца продукта (Product Owner, PO). Однако в силу своей высокой включенности в процесс разработки и полноценного владения предметной областью аналитик может прогнозировать возможные риски и управлять ими совместно с менеджером.
Естественно, специфика профессии накладывает свой отпечаток, в результате чего риски аналитик может прогнозировать в основном те, что связаны с разработкой функциональности по заявленным заказчиками бизнес-требованиям.
Знающий предметную область и реализованную функциональность, а также полный скоп требований аналитик может спрогнозировать негативные последствия реализации задачи как для всего проекта в целом, так и для отдельных уже существующих функций продукта.
По какому же пути может пойти аналитик, поставивший перед собой цель предотвратить наиболее вероятные риски в проекта?
Определить угрозы
На первом этапе важно в принципе определить перечень событий, которые негативным образом могут сказаться на реализации проекта.
По результатам реализации данного этапа должен быть сформирован список рисков с указанием вероятных причин и прогнозируемых последствий их возникновения. Собрать такой перечень можно как с участием команды либо PO, так и самостоятельно.
Так, командный мозговой штурм позволит сгенерировать и зафиксировать различные идеи, а затем совместно выбрать наиболее подходящие из них.
В результате размышлений на тему “А что, если…” аналитик сможет самостоятельно мысленно воссоздать критические с его точки зрения ситуации для продукта и продумать последствия, которые они могут за собой повлечь.
За получением информации о дополнительных возможных рисках проекта можно обратиться к опытным экспертам, работающим в составе команды, которые, возможно, сталкивались с аналогичными ситуациями в прошлом либо имеют более четкое общее представление о продукте.
Подобного эффекта можно достичь также в ситуации, когда негативный опыт получал сам аналитик, который и может извлечь из ситуации прошлого полезные выводы.
В процессе определения угроз аналитик может отследить как риски проекта в целом, так и риски, связанные непосредственно с аналитикой. Это могут быть, например:
- Риски недоопределенности требований. Предотвратить наступление рисков этой группы аналитик может самостоятельно. Это, например, ситуации, когда при сборе требований не было учтено мнение всех заинтересованных сторон, последствиями чего может стать задержка разработки, повторная разработка или отказ в приемке готового решения. Если готовое решение зависит от требований действующего законодательства, риском может стать изменение соответствующих нормативных актов. В первом случае аналитик должен особенно внимательно относиться к формированию полного перечня заинтересованных лиц; во втором - отслеживать изменения законодательства по тематике своего продукта.
- Коммуникационные риски. Это самая большая группа рисков, связанная с проблемами взаимодействия между членами команды, заказчиком и исполнителем, производителем продукта и пользователями и другими участниками процесса реализации требований. Трудности взаимодействия с заказчиком могут приводить к увеличению сроков согласования документов, ошибкам в определении требований, конфликту интересов разных пользователей, слабой мотивации пользователя на работу в продукте и т.д. Затрудненная коммуникация внутри команды разработки может привести к непониманию общей цели проекта, проблемам в передаче информации между членами команды, увеличению сроков разработки и другим проблемам.
- Риски планирования. В процессе планирования работ по проекту могут возникнуть ошибки, связанные с неверной оценкой потребности в аналитическом ресурсе; небольшим бюджетом, заложенным на аналитическую работу; неверной расстановкой приоритетов проекта; частым изменением требований к продукту; изменением целевой аудитории продукта; изменением направления развития бизнеса и т.д.
- Кадровые риски. В эту группу входят все проблемы с аналитическим ресурсом, которые могут возникнуть в рамках проекта - отсутствие аналитиков нужной квалификации, болезнь, отпуск либо увольнение сотрудников, снижение трудовой мотивации и др.
- Технические риски. Это ограничения, налагаемые платформой решения и иные технические сложности, возникающие в процессе реализации требования.
Составить матрицу рисков
Целью этого этапа является классификация и анализ определенных на предыдущем этапе угроз и расположение их в соответствующей иерархической матрице в зависимости от вероятности их возникновения и уровня ущерба, который повлечет за собой наступивший риск.
Для каждого риска из ранее собранного списка необходимо по пятибалльной шкале оценить вероятность его возникновения и уровень возможного ущерба.
Чаще всего оценка производится “на глазок” и зависит от субъективного представления аналитика либо менеджера о значимости риска.
Мы предлагаем вам рассмотреть несколько другую концепцию определения рисков для продуктов.
Так, для оценки вероятности возникновения риска попробуйте ответить на следующие вопросы:
- Как часто возникали подобные риски в проекте ранее? Возникали ли ранее в проекте ситуации, которые могли повлечь за собой подобный риск? Какие дополнительные факторы способствовали возникновению этого риска на тот момент? Благодаря каким условиям проекта риск тогда не проявился?
- С какой периодичностью риски в проекте возникают в принципе? Чем они обычно бывают вызваны?
- Существуют ли способы нивелирования данного риска? Какие из них уже работали исторически?
- Как нам поможет предотвратить этот риск то, что мы прогнозируем вероятность его возникновения?
- Сколько актуальных для проекта факторов могут вызвать этот риск?
- Существуют ли в регламенте работы по проекту механизмы, которые снизят вероятность наступления этого риска?
- В какой срок прогнозируется наступление этого риска?
Для того, чтобы определить уровень ущерба, который повлечет за собой этот риск, рекомендуется определить:
- На какие процессы влияет наступление данного риска? Эти процессы обеспечиваются основной или дополнительной функциональностью продукта?
- Для какого количества пользователей продукта будет действовать данный риск?
- Какой ущерб (финансовый, репутационный, управленческий и т.д.) для вашей организации влечет за собой данный риск?
- Насколько критично данный риск влияет на сроки выполнения проекта? На реализацию проекта в целом?
- Как быстро получится устранить последствия наступления риска?
После того, как для каждого риска вы ответите на вопросы относительно вероятности возникновения риска и уровня наносимого им ущерба, проранжируйте риски по шкале от 1 до 5 для двух этих показателей и расположите риски на матрице.
Попадание риска в “бордовую” зону означает, что риск является критичным и действие, которое приводит к его возникновению, осуществлять нельзя.
Если риск находится в “оранжевой” зоне, он является высоким, и соответствующее ему действие можно осуществлять только после проведения комплекса мероприятий по его снижению.
Риск “желтой” зоны средний, запланированное действие можно осуществлять, но только после одобрения менеджера проекта либо PO и под постоянным контролем.
В “зеленой” зоне будут расположены приемлемые риски, и соответствующие им действия можно будет осуществлять с соблюдением мер безопасности.
Проработать стратегию борьбы
На этом этапе необходимо продумать стратегию борьбы с рисками, попавшими в перечень критичных, и составить план работы по каждому из них.
Можно выбрать одну из стандартных стратегий борьбы с риском либо разработать собственную для уникальных случаев.
Стратегия избегания (Avoid) подразумевает принятие мер по предупреждению риска, максимального снижения вероятности его возникновения.
Стратегия переноса ответственности (Transfer) предполагает, что ответственность за возникновение риска будет перенесена на третью сторону.
Стратегия принятия (Accept) позволяет ничего не делать для предотвращения наступления риска и действует в случае, когда мероприятия по предотвращению риска “стоят” дороже, чем бездействие.
Стратегия смягчения (Mitigate) предусматривает принятие ответственности за риск на себя и борьбу с ним. Для применения данной стратегии необходимо разработать основной (снижающий вероятность либо последствия наступления риска) и отходной (применяемый в случае, если меры по борьбе с риском не принесли результатов, и риск стал проблемой) планы.
Контролировать соблюдение планов
После того, как выполнены все вышеуказанные действия, менеджер проекта либо PO должен начать работу по управлению выявленными рисками, реализовывать выработанные стратегии и планы. На этом этапе роль аналитика минимальна и заключается скорее в анализе и экспертизе процесса проработки рисков и фиксации удачных и неудачных решений.
Итого
Прогнозирование рисков и планирование работы с ними - одно из важных направлений деятельности аналитика, которое позволяет стабилизировать разработку продукта и, как следствие, - сроки поставки конечного решения пользователю.
Периодичность прогнозирования рисков аналитик и менеджер могут определить самостоятельно в зависимости от специфики проекта, однако мы рекомендуем проводить анализ рисков для каждой запланированной крупной функциональности продукта.
Текст: Татьяна Величкина
Редактор: Ирина Ткаченко
Фото: найдены на просторах Сети
