Управление рисками

Содержание

1. Основные понятия……………………………………………….……...3
2. Основные проблемы……………………………………………….……5
3. Задачи управления рисками…………………………………….…........6
4. Выявление рисков……………………………………………….………8
5. Анализ и оценка приоритетности……………………………….……...9
1. Планирование ответных действий………………………….……..11
2. Мониторинг рисков…………………………………………….…..12
6. Некоторые практические рекомендации……………………………...13
7. Этапы освоения…………………………………………………………15

Список литературы…………………………………………………………17 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Управление  рисками 

1. Основные  понятия

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

     Введем  несколько формальных определений.

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

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

     Вероятность риска — вероятность, с которой данный риск превратится в проблему. Здесь также применима качественная шкала (пренебрежимая вероятность, малая и т. д. — вплоть до весьма вероятной). Но могут использоваться и численные значения (обычно выбирают некоторый набор типовых значений, например, 0,1; 0,3; 0,5; 0,7; 0,9). Следует отметить, что событие, которое должно обязательно произойти, не является риском, и действия, которые необходимо в связи с ним предпринять, определяются в рамках обычного планирования и управления, а не управления рисками.

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

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

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

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

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

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

2. Основные  проблемы

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

     Если  спросить у рядового разработчика или  руководителя, почему в их фирме  нет процесса управления рисками, можно  услышать массу самых разных ответов. Тут будет и самое простое: “У нас нет рисков”, и более  изощренные варианты: “Мы боремся  с проблемами по мере их возникновения”, “Наше дело — разработка программы, а не заполнение бюрократических  форм”, “Использование этого инструмента  не рискованно. Так нам сказал поставщик”. Реальные же причины нелюбви к  управлению рисками чаще всего кроятся  в следующем.

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

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

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

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

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

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

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

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

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

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

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

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

1. Назначение ответственного лица. Отвечать за процесс должен один человек, который собирает сведения о возможных рисках, организует их анализ и формирует регулярные отчеты. Чаще всего это не требует полной занятости — ответственный может выполнять и другие роли в проекте. Планирование и выполнение действий, направленных на снижение рисков, остается в ведении руководителя проекта. Выделение специального человека, в чьи обязанности входит выявление рисков, и введение дополнительных премий тем, кто выявил риск, помогает бороться с негативным отношением к управлению рисками в команде.
2. Определение тактики и методов, применяемых в конкретном проекте для выявления, анализа и снижения рисков. Это может быть метод исключения рискованных решений или разработка запасных планов. Здесь же устанавливаются поощрения для сотрудников, указавших на реализовавшиеся риски или предложивших наиболее эффективные меры по их устранению и т. п.
3. Определение бюджета, предназначенного для управления рисками. Бюджет существенно влияет на ассортимент средств, которыми можно воспользоваться для преодоления рисков.
4. Планирование основных действий по управлению рисками и их привязка к жизненному циклу проекта (согласование сроков мероприятий, направленных на управление рисками, с основными производственными процессами).

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

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

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

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

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

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

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

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

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

1. Исторический анализ. Сравнение данного проекта с аналогичными, выполненными ранее. Вчерашние проблемы часто остаются рисками в новых проектах.
2. Аналитический метод. Включает такие технологии, как моделирование, анализ по схеме "причина-результат", анализ таблиц истинности и т. д.
3. Совещания, посвященные выявлению и оценке рисков. Как правило, они проводятся с использованием мозгового штурма. Если число участников проекта невелико, они все приглашаются на совещание. В противном случае собирают только лидеров групп и ведущих разработчиков.
4. Индивидуальные интервью. Проводятся как с руководством проекта, так и с рядовыми участниками. По желанию интервьюируемых они могут остаться анонимными и не упоминаться как “источники” риска. Сотрудники могут даже присылать свои сообщения анонимно по электронной почте — анонимность позволяет избежать опасений, что “принесшего дурную весть накажут”.

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