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

Институт PMI описывает системный подход к процессу управления рисками, который описан в PMBOK. Процесс управления рисками делится на шесть основных процессов:

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

· Идентификация рисков

· Качественный анализ рисков

· Количественный анализ рисков

· Планирование реагирования на риски

· Мониторинг и управление рисками

Остановимся на 3х из них: Идентификация, Качественный анализ, Количественный анализ, т.к. эти процессы наиболее зависимы от предметной области и рассмотрим их более подробно в контексте программной инженерии.

Идентификация рисков

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

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

· Всевозможные оценки сроков, времени и стоимости создания модулей и компонентов будущего проекта.

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

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

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

Существует несколько методик идентификации рисков. Основные из них - это:

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

Улучшение такой методики является метод Delphi. Метод заключается в следующем:

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

2. Подготавливается и распространяется перечень вопросов, относящихся к рискам.

3. Проводится опрос экспертов

4. Результаты опроса и статистические данные по результатам распространяются среди экспертов

5. Процесс повторяется, пока эксперты не достигнут консенсуса.

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

На выходе процесса идентификации рисков управляющий проектом должен получить следующие данные:

· Источники рисков. Типичные примеры:

o Изменения в требованиях к продукту во время его разработки

o Ошибки проектирования (архитектуры) будущего ПО

o Плохо определенные или нераспределенные роли в команде разработчиков

o Неточные или вообще отсутствующие оценки сроков и стоимости реализации проекта

o Недостаточный профессионализм команды, исполняющей проект

· Возможные события при проявлении рисков, как например: незаконченность какого-то модуля ПО к сроку, несоответствие разработанного модуля требованиям и т.д.

· Потери в случае наступления рискового события, выраженные во времени и (или) денежном эквиваленте. Например: переписывание модуля, несоответствующего требованиям, займет n человеко-часов и n*(средняя ЗП программиста) рублей.

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