Согласно PMBOK (Project Management Body of Knowledge – своду знаний по управлению проектами) риск – это неопределенное событие или условие, которое может повлиять как положительно, так и отрицательно на результаты и цели проекта.
Поэтому работа с рисками нужна, чтобы повысить вероятность возникновения и степень воздействия благоприятных событий и снизить вероятность возникновения и степень воздействия неблагоприятных событий.
Согласитесь, неопределенных событий в работе аналитика хватает, поэтому давайте рассмотрим, что рекомендуется с ними и их последствиями делать.

Как с рисками работать

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

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

Кратко рассмотрим эти активности по порядку.

Для поиска возможных рисков, можно использовать комбинацию из нескольких методов:

• Мозговой штурм – известный метод, заключающийся в генерации разнообразных идей и их последующей фиксации, а затем выборе наиболее подходящих из имеющегося списка, подключая критическое мышление в противовес креативному мышлению, используемому в фазе генерации идей.
• Анализ «что если» – результаты размышлений «а что, если во время сбора требований мы упустим что-то важное», «а что, если заказчик откажется с нами общаться по проекту», «а что, если заказчик не примет сделанную нами систему, т.к. это не то, что он на самом деле хотел» и т.д.
• Мнение и опыт экспертов, где под экспертами понимаются как опытные члены команды, так и опытные коллеги вне проекта, а также приглашенные эксперты. К мнению экспертов можно также отнести реестры рисков из заслуживающих доверия источников сети Internet (например, Taxonomy-based risk identification или MSF risk management discipline).
• Ваш личный прошлый опыт – наверняка, у каждого аналитика есть события из прошлого опыта. Зная о них теперь, вы бы действовали совершенно по-другому. Например, зная о том, к чему может привести слабая вовлеченность заказчика или пользователей, в следующем проекте вы постараетесь не допустить повторения такой ситуации, а значит, и ее последствий.
• И другие, подходящие для вашего случая методы.

Результатом такой активности должен быть реестр рисков, то есть их упорядоченный список с оценкой вероятности наступления и оценкой степени воздействия, если риск сработает. Для особо формальных случаев бывает нужна количественная оценка этих величин, но для большинства проектов можно обойтись качественной (например, «высокий», «средний», «низкий»).

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

При этом реестр будет особенно полезен, если его не просто единожды составить, но и периодически пересматривать и актуализировать, в случае необходимости.

Существует несколько основных стратегий работы с негативными рисками:

• Избежать риска (Avoid) – принять превентивные меры, чтобы максимально снизить вероятность наступления риска, чтобы избежать его последствий;
• —Снизить последствия в случае срабатывания риска (Mitigate) – допустить, что риск может сработать, однако продумать и принять меры по минимизации его последствий;
• —Передать его третьей стороне (Transfer), примером такой стратегии могут быть заказные разработка или тестирование;
• —Принять последствия риска в случае его возникновения (Accept) – эта стратегия актуальна, если вероятность срабатывания риска мала и последствия от его срабатывания незначительны. То есть не предпринимать никаких действий получается выгоднее и удобнее.

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

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

Примеры рисков

В качестве примеров возможных рисков, связанных с анализом для IT проектов можно назвать следующие:

1. Требования собраны не в полном объеме, без учета всех заинтересованных сторон.
2. Непонимание или недостаточное понимание бизнес-целей проекта.
3. Затрудненная коммуникация аналитика по вопросам требований с заказчиком (в том числе и по вопросам согласования документов, слабая вовлеченность заказчика или пользователей).
4. Затрудненная коммуникация аналитика с командой (например, вследствие ее распределенности).
5. Проблемы с оценкой трудозатрат на анализ в проекте (неверная оценка, урезание бюджета на анализ и т.д.).
6. Неверные приоритеты проекта, «золотое напыление».
7. Постоянное расширение границ проекта, изменяющиеся во время проекта требования или их приоритеты.
8. Проблемы с аналитиками на проекте (нет квалифицированных аналитиков для работы на проекте, аналитики покидают проект по личным и рабочим причинам и т.д.).
9. Конфликты между разными заинтересованными сторонами по вопросам требований, их приоритетов и иным связанным вопросам.
10. Изменение рынка (целевой аудитории) для продукта, изменение бизнес целей во время разработки проекта.
11. Изменение регулирующих постановлений, законодательных актов, относящихся к проекту.
12. Сопротивление, саботаж конечных пользователей по вопросам требований и использования результатов проекта.
13. Технические сложности и ограничения, накладываемые на реализацию требований.

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

Риски в «гибкой» разработке ПО

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

Однако это не означает, что в гибкой разработке управлению рисками совсем нет места. Такие активности должны присутствовать, пусть и в немного адаптированном виде. Например, активности по поиску рисков можно включить в нулевой спринт. При этом, конечно, подразумевается сильная вовлеченность команды, а также заказчика и пользователей. Пересматривать и актуализировать реестр рисков нужно каждый спринт, не тратя при этом много времени. Список рисков должен быть доступен для всей команды и визуализирован, например, на доске с задачами. На ретроспективах также рекомендуется обсуждать вопросы, касающиеся рисков, отвечая на вопросы вида: «что бы вы сделали с таким же риском в следующий раз?», «действия команды помогли предотвратить риск/снизить его последствия?», «нужно ли актуализировать реестр сейчас?» и т.д.

При этом считается, что надо делать ровно столько, сколько необходимо и не тратить время и усилия на формальные процедуры и документы (т.е. соблюдать принципы KISS и YAGNI).

Вместо заключения

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

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

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

Об авторе

Тарасюк Надежда, активный участник сообщества analyst.by, ведущий специалист в области бизнес-анализа (7+ лет опыта в IT с фокусом на бизнес-анализ).