Вероятность риска

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

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

Наиболее часто используются следующие стратегии борьбы с риском.

1. Избежать риска. Реорганизовать  проект таким образом, чтобы  он не зависел от данного  события. Например, при разработке  ПО можно исключить вызывающую  сомнение функциональность. К сожалению,  таким образом редко удается  полностью удовлетворить заказчика.

2. Переадресовать риск. Исполнитель  прибегает к своего рода страховке  -- если проявится риск, заказчик  берет на себя оплату дополнительных  работ. В случае реализации  такого риска руководство компании  обязуется привлечь к проекту еще некоторое количество сотрудников.

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

Список рисков -- упорядоченный  по приоритету список выявленных и  отслеживаемых рисков. Приоритет  определяется как произведение вероятности  на величину воздействия (в условных единицах).

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

Руководители  проектов тоже нередко побаиваются  управления рисками. Они считают, что  если заранее выявленный риск все-таки реализуется, это будет рассматриваться  как их ошибка. Хотя реально такая  ситуация обычно позволяет продемонстрировать, насколько удалось снизить потенциальные последствия риска с помощью превентивных мер.

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

Таким образом, внедрение управления рисками часто  требует существенного изменения всей корпоративной культуры. Ниже мы рассмотрим в числе прочего некоторые методы и приемы, позволяющие ускорить этот процесс.

 

3.2 Задачи управления рисками

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

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

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

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

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

Мониторинг рисков. Цель данной меры -- изменение приоритетов и планов преодоления рисков при изменении  их вероятности и последствий, а  также своевременное выявление  рисков, которые реализуются в  данный момент. По сути представляет собой повторение шагов выявления и анализа рисков.

Рассмотрим перечисленные задачи более детально.

Планирование управления рисками

В планировании управления рисками есть ряд главных  моментов.

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

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

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

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

Выявление рисков

Риски, с которыми приходится иметь дело в проектах разработки ПО, можно условно разбить  на несколько типов:

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

2. Программные риски,  связанные с приобретением или  использованием ПО третьих фирм (если это приобретение не находится  под должным контролем разработчиков  и руководителей проекта).

3. Риски на этапе сопровождения системы, в том числе связанные с размещением ПО у заказчика, поддержкой, обучением и т. п.

4. Стоимостные риски,  связанные с превышением затрат  или проблемами финансирования  проекта. 

5. Риски сроков, связанные  с необходимостью ускорить разработку из-за внешних причин.

6. Риски неудовлетворенности  заказчика. 

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

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

Аналитический метод. Включает такие технологии, как  моделирование, анализ по схеме "причина-результат", анализ таблиц истинности и т. д.

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

Индивидуальные  интервью. Проводятся как с руководством проекта, так и с рядовыми участниками. По желанию интервьюируемых они могут остаться анонимными и не упоминаться как “источники” риска. Сотрудники могут даже присылать свои сообщения анонимно по электронной почте -- анонимность позволяет избежать опасений, что “принесшего дурную весть накажут”.

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

Анализ и оценка приоритетности

Выявленные  риски следует проанализировать. Анализ включает оценку вероятности  риска и его возможных последствий в кратко- и долгосрочном плане.

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

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

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

Планирование ответных действий

Для каждого  из рисков, вошедших в список приоритетных, необходимо выбрать стратегию реагирования. Как уже говорилось, стратегия может быть направлена на то, чтобы “обойти” риск, застраховаться от него или смягчить его последствия. Иногда риск можно исключить полностью, отказавшись от одного-двух низкоприоритетных свойств системы. В других случаях можно попытаться использовать более зрелые или лучше известные разработчикам технологии.

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

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

Строго говоря, задача не в том, чтобы свести возможность проявления риска или его последствия к нулю. Если такое решение и достижимо, оно может потребовать слишком много ресурсов. Реальная цель -- снизить вероятность и последствия проявления риска до приемлемого уровня.

Для части рисков, обычно связанных с недостатком информации, можно явно указать действие, которое определит, проявится риск или нет. Например, чтобы понять, удастся ли интегрировать новую систему в уже существующую инфраструктуру, как правило, достаточно создать небольшой прототип новой системы. Он либо покажет, как должна осуществляться интеграция, либо заставит проявиться соответствующий риск. Типичный прием -- запланировать такие действия на возможно более ранние сроки. Это позволяет, с одной стороны, менее спешно и более осмысленно предпринимать ответные действия, с другой стороны -- раньше выявить новые риски, которые могут возникнуть после проявления уже известных.

Мониторинг рисков

К сожалению, управление рисками -- это не одноразовое мероприятие. Вероятность и последствия однажды выявленных рисков и оценка их приоритетности могут в дальнейшем измениться; могут появиться и новые риски. Например, по мере накопления сведений об определенных инструментах и методах у исполнителей растет уверенность, что работы могут быть выполнены в срок. Или, наоборот, опыт сборки и тестирования предварительных версий системы, возможно, заставляет усомниться в достаточной ее производительности. Это значит, что данные о рисках должны регулярно обновляться. Повторный анализ рисков желательно провести таким образом, чтобы свежие сведения можно было использовать при планировании очередной итерации проекта.

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

3.3 Некоторые практические рекомендации