При анализе для каждого определенного риска подсчитывается вероятность его проявления и ущерб, который он может нанести. Не существует простых методов выполнения анализа рисков — в значительной мере он основан на мнении и опыте менеджера. Можно привести следующую шкалу вероятностей рисков и их последствий.
1. Вероятность риска считается очень низкой, если она имеет значение менее 10%; низкой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%.
2. Возможный ущерб от рисковых ситуаций можно подразделить на катастрофический, серьезный, терпимый и незначительный.
Результаты анализа рисков должны быть представлены в виде таблицы рисков, упорядоченных по степени возможного ущерба. В табл. 6 приведен упорядоченный список рисков, описанных в табл. 5; там же указаны вероятности этих рисков. Здесь вероятности рисков и степень ущерба от них указаны произвольно. На практике для их определения необходима подробная информация о проекте, технологии создания ПО, команде разработчиков и о самой организации.
|
|
Таблица 6 - Список рисков после проведения их анализа
Риск | Вероятность | Степень ущерба |
Финансовые затруднения в организации привели к уменьшению бюджета проекта | Низкая | Катастрофическая |
Невозможно подобрать работников с требующимся профессиональным уровнем | Высокая | Катастрофическая |
Ведущий разработчик заболел в самое критическое время | Средняя | Серьезная |
Программные компоненты, используемые повторно, имеют дефекты, ограничивающие их функциональные возможности | Средняя | Серьезная |
Изменения требований приводят к значительным повторным работам по проектированию системы | Средняя | Серьезная |
В организации, выполняющей разработку ПО, произошла реорганизация, в результате чего изменились приоритеты в управлении проектом | Высокая | Серьезная |
База данных, которая используется в программной системе, не обеспечивает обработку ожидаемого объема транзакций | Средняя | Серьезная |
Недооценки времени выполнения проекта | Высокая | Серьезная |
CASE-средства невозможно интегрировать с другими средствами поддержки проекта | Высокая | Терпимая |
Первоначальная нечеткая формулировка пользовательских требований привела к значительным изменениям системных требований, проявившихся на поздних стадиях разработки проекта | Средняя | Терпимая |
Невозможно организовать необходимое обучение персонала | Средняя | Терпимая |
Скорость выявления дефектов в системе ниже ранее спланированной | Средняя | Терпимая |
Размер системы значительно превышает первоначально рассчитанный | Высокая | Терпимая |
Программный код, генерируемый CASE-средствами, неэффективен | Средняя | Незначительная |
Конечно, как вероятность рисков, так и возможный ущерб от них должны пересматриваться при поступлении дополнительной информации об этих рисках и по мере реализации мероприятий по управлению ими. Поэтому подобные таблицы рисков должны переделываться на каждой итерации процесса управления рисками.
|
|
После проведения анализа рисков определяются наиболее значимые риски, которые затем отслеживаются на протяжении всего срока выполнения проекта. Определение этих значимых рисков зависит от их вероятностей и возможного ущерба. В общем случае всегда отслеживаются риски с катастрофическими последствиями, а также риски с серьезным ущербом, значение вероятности которых выше среднего.
В некоторых статьях рекомендуется определить и отслеживать "10 верхних" рисков, но это не всегда обоснованная рекомендация. Количество рисков, которые необходимо отслеживать, зависит от конкретного проекта. Это может быть пять рисков, а может — пятнадцать. Но, конечно, количество рисков, по которым проводится мониторинг, должно быть обозримым. Большое количество отслеживаемых рисков потребует огромного количества собираемой информации. Из списка рисков, представленных в табл. 6, для мониторинга следует отобрать те риски, которые могут привести к катастрофическим и серьезным последствиям для вашего проекта.
Планирование рисков
Планирование заключается в определении стратегии управления каждым значимым риском, отобранным для мониторинга после анализа рисков. Здесь также не существует общепринятых подходов для разработки таких стратегий — многое основывается на "чутье" и опыте менеджера проекта. В табл. 7 показаны возможные стратегии управления основными рисками, приведенными в табл. 6.
Таблица 7 - Стратегии управления рисками
Риск | Стратегия |
Финансовые проблемы организации | Подготовить краткий документ для руководства организации, показывающий важность данного проекта для достижения финансовых целей организации |
Проблемы неквалифицированного персонала | Предупредить заказчика о потенциальных трудностях и возможной задержке проекта, рассмотреть вопрос о покупке компонентов системы |
Болезни персонала | Реорганизовать работу команды разработчиков таким образом, чтобы обязанности и работа членов команды перекрывали друг друга, вследствие этого разработчики будут знать и понимать задачи, выполняемые другими сотрудниками |
Дефектные системные компоненты | Заменить потенциально дефектные системные компоненты покупными компонентами, гарантирующими качество работы |
Изменения требований | Попытаться определить требования, наиболее вероятно подверженные изменениям; в структуре системы не отображать детальную информацию |
Реорганизация компании-разработчика | Подготовить краткий документ для руководства компании, показывающий важность данного проекта для достижения финансовых целей компании |
Недостаточная производительность базы данных | Рассмотреть возможность покупки более производительной базы данных |
Недооценки времени выполнения проекта | Рассмотреть вопрос о покупке системных компонентов, исследовать возможность использования генератора программного кода |
Существует три категории стратегий управления рисками.
1. Стратегии предотвращения рисков. Согласно этим стратегиям следует проводить мероприятия, снижающие вероятность проявления рисков. Примером может служить стратегия исключения потенциально дефектных компонентов, описанная в табл. 7.
2. Минимизационные стратегии. Направлены на уменьшение возможного ущерба от рисков. Примером служит стратегия уменьшения ущерба от болезни членов команды разработчиков (см. табл. 7).
|
|
3. Планирование "аварийных" ситуаций. Согласно этим стратегиям необходимо иметь план мероприятий, которые следует выполнить в случае проявления рисковой ситуации. В табл. 7 это стратегия поведения при возникновении финансовых проблем у организации-разработчика.