Пример 1. Анализ риска

Определение риска	Условия: Заказчик требует использования Z-технологии, с которой мы не знакомы Следствие: Кодирование может занять больше времени
Вероятность	Работы по кодированию могут занять до 25% больше времени (фактор продуктивности = 1.25). Вероятное значение трудоемкости кодирования: 1.25x20=25 человеко-дней Вероятное значение длительности кодирования: 1.25x4= 5 месяцев
Стратегия	Послать программистов на обучение Z-технологии. Стоимость обучения $2,200. Ожидаемое значение фактора продуктивности должно снизится до 1.1 Сделать одного из программистов экспертом. Выделить ему 1 день в неделю на изучение Z-технологии и выработку внутренних стандартов по ее использованию. Это должно снизить фактор продуктивности до 1.0. Всего затрат на работу эксперта - 5 рабочих дней.

Пример 2. Список рисков (Risk list, Risk Log)

Номер риска	Приоритет	Дата обнаружения	Ответственный	Описание	Стратегия (порядок разрешения)	Текущее состояние
7	1	5.1.2009	Разработчик	Система требует новых драйверов	Произвести бетта-тестирование на новых драйверах	На старых драйверах система не работает. Риск высокий. Назначено совещание.
2	2	7.2.2009	Менеджер	Заказчик требует использования Z-технологии	Провести обучение Выработать внутренние стандарты	Обучение завершено. Есть некоторые проблемы со сборкой системы. Риск средний.

Как видим форма очень похожа на традиционный баг-лист (Bug List).

Только статистика позволяет оценить значимость рисков

Проект обычно подвержен очень большому количеству рисков, запланировать мероприятия по борьбе со всеми практически невозможно. Что же делать?

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

Видно, что работает правило 80/20. Примерно 20% рисков создают 80% угрозы. Именно на них следует обращать основные усилия. В технологичных проектах обычно риски предотвращаются обучением, контролем и поддержанием качества (тестированием и др. методами).

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

Для софтверных проектов, есть особенность. Фактически любая команда выдающая продукты хорошего качества имеет систему регистрации дефектов и их отслеживания (Bug Tracking System). Можно не изобретать велосипед и все рисковые проблемы фиксировать там, для этого потребуется завести новые категории проблем ("неверное планирование", "недооценка сроков", "ошибка постановки задачи" и т.д.). В таком случае вы сможете пользоваться развитой отчетностью по проблемам из системы отслеживания дефектов, кроме того, вы сможете использовать и механизмы отслеживания проблемы, т.е. на проблему будет гарантированная реакция ответственного лица.