Методики идентификации рисков
Для идентификации рисков используют следующие методы:
1. Мозговой штурм - Целью мозгового штурма является создание подробного списка рисков проекта. Список рисков разрабатывается на собрании, в котором принимает участие 10-15 человек - члены команды проекта, часто совместно с участием экспертов из разных областей, не являющихся членами команды. Участники собрания называют риски, которые считают важными для проекта, при этом не допускается обсуждение выдвинутых рисков. Далее риски сортируют по категориям и уточняют.
2. Метод Дельфи -аналогичен методу мозгового штурма, но его участники не знают друг друга. Ведущий с помощью списка вопросов для получения идей, касающихся рисков проекта, собирает ответы экспертов. Далее ответы экспертов анализируются, распределяются по категориям и возвращаются экспертам для дальнейших комментариев. Консенсус и список рисков получается через несколько циклов этого процесса. В методе Дельфи исключается давление со стороны коллег и боязнь неловкого положения при высказывании идеи.
3. Метод номинальных групп- позволяет идентифицировать и расположить риски в порядке их важности. Данный метод предполагает формирование группы из 7-10 экспертов. Каждый участник индивидуально и без обсуждений перечисляет видимые им риски проекта. Далее происходит совместное обсуждение всех выделенных рисков и повторное индивидуальное составление списка рисков в порядке их важности.
4. Карточки Кроуфорда -Обычно собирается группа из 7-10 экспертов. Ведущий сообщает, что задаст группе 10 вопросов, на каждый из которых участник письменно, на отдельном листе бумаги, должен дать ответ. Вопрос о том, какой из рисков является наиболее важным для проекта, ведущий задает несколько раз. Каждый участник вынужден обдумать десять различных рисков проекта.
5. Опросы экспертов -с большим опытом работы над проектами.
6. Идентификация основной причины -Цель этого процесса: выявить наиболее существенные причины возникновения рисков проекта и сгруппировать риски по причинам, их вызывающим.
7. Анализ сильных и слабых сторон, возможностей и угроз(анализ SWOT) - Цель проведения анализа - оценить потенциал и окружение проекта. Потенциал проекта, выраженный в виде его сильных и слабых сторон, позволяет оценить разрыв между содержанием проекта и возможностями его выполнения. Оценка окружения проекта показывает, какие благоприятные возможности предоставляет и какими опасностями угрожает внешняя среда.
8. Анализ контрольных списков -Контрольные списки представляют собой перечни рисков, составленные на основе информации и знаний, которые были накоплены в ходе исполнения прежних аналогичных проектов.
9. Метод аналогии -Для идентификации рисков этот метод использует накопленные знания и планы по управлению рисками других аналогичных проектов.
10. Методы с использованием диаграмм -К методам отображения рисков в виде диаграмм относятся диаграммы причинно-следственных связей и блок-схемы процессов, которые позволяют проследить последовательность событий, происходящих в данном процессе.
Таблица 5.6. Сравнение методов идентификации рисков | ||
Метод идентификации | Преимущества | Недостатки |
Мозговой штурм | Способствует взаимодействию членов группы. Быстрый. Недорогой | Может проявиться преобладание одной личности. Можно сосредоточиваться только в конкретных областях. Требует сильного ведущего. Для оценки необходимо контролировать склонности группы |
Метод Delphi | Нет доминирования одной личности. Может проводиться дистанционно, через электронную почту. Исключается проблема ранней оценки. Требует участия каждого члена группы | Занимает много времени. Высокая загрузка ведущего |
Метод номинальных групп | Уменьшается эффект доминирующей личности. Обеспечивает взаимодействие участников. Дает упорядоченный список рисков | Требует много времени. Высокая загрузка ведущего |
Карточки Кроуфорда | Быстрый. Легко реализуется. Должен участвовать каждый член группы. Вырабатывается большое количество идей. Можно проводить с группами больше обычного размера. Уменьшает эффект доминирующей личности | Меньшее взаимодействие между участниками |
Опрос экспертов | Используется прошлый опыт | Эксперт может быть предвзятым. Требует много времени |
Контрольные списки | Конкретный и упорядоченный. Легко использовать | Предвзятость. Может не содержать конкретных элементов для данного проекта |
Метод аналогии | Использует прошлый опыт для исключения проблем в будущем. Подобные проекты содержат много сходных черт | Требует много времени. Легко получить результаты, не подходящие для данного случая. Аналогия может быть некорректной |
Методы с использованием диаграмм | Ясное представление участвующих процессов. Легкость построения. Для них имеется много компьютерных инструментов | Иногда вводит в заблуждение. Может занимать много времени |
Сравнение методов идентификации рисков проекта [11] представлено в табл. 5.6.
Идентифицированные риски документируются в так называемых реестрах рисков.
Примеры шаблонов реестра рисков [11] приведены в таблицах 5.7и 5.8.
Таблица 5.7. Шаблон реестра рисков | ||||||||||
ИДЕНТИФИКАЦИЯ РИСКА | ||||||||||
№ | Датавозникновенияриска | Датарегистрациириска | Наименование и описание риска | Инициатор | Причины | Последствия | Владелец риска | Дата окончания действия риска | ||
. | ||||||||||
. | ||||||||||
Таблица 5.8. Пример заполнения реестра рисков (упрощенный) | ||||||||||
Первопричина | Условие | Последствие | ||||||||
Необеспеченность кадрами | Могут быть объединены проектные роли. Несовместимые роли: менеджер по качеству и разработчик, тестировщик и разработчик | Совмещение ролей может затруднить контроль и оценку результатов, что снизит качество программного продукта | ||||||||
Изменения в технологии | Разработчикам придется осваивать новые технологии и использовать их впервые | Увеличится время на разработку программного продукта. Возможно снижение качества________ | ||||||||
Организация работы | Участники проекта территориально удалены | Обмен информацией внутри группы затрудняется. Время на достижение целей проекта увеличивается_____ | ||||||||
В более сложных проектах, где есть необходимость обеспечить высокое качество результата при большом количестве работ, принято использовать расширенные реестры рисков и в них сразу указывать экспертную оценку воздействия риска на проект (см.табл. 5.9).
Таблица 5.9. Пример заполнения расширенного журнала рисков | ||||||
Тип риска | Описание риска | Проактивные мероприятия | Реактивные мероприятия | Вероятность | Последствия | Фактор риска |
Технологический | Заказчик может задержать выпуск продукта из-за постоянных изменений и дополнений требований к продукту | 1. Разделить требования на "абсолютно необходимые" и "хорошо бы было иметь", до запуска системы выполнять только абсолютно необходимые требования 2. Убедиться в том, что руководство заказчика понимает и поддерживает подход, что заявки на изменения будут выполняться после завершения основных работ везде, где это возможно | 1. Обсудить изменение сроков ввода системы в эксплуатацию из-за накопившегося объема изменений для обеспечения необходимого уровня качества финального продукта | |||
Финансовый | Заказчик настаивает на бесплатном исправлении всех ошибок (в данном случае речь идет только о тех пунктах, которые мы также можем признать ошибками), что может привести к серьезным финансовым потерям | 1. Включить в план работ бюджет и время программистов на исправление ошибок по результатам тестирования. 2. Разъяснять ключевым представителям заказчика, что выявление и исправление ошибок является частью технологии разработки ПО | 1. В случае невозможности достижения договоренности поднять вопрос на уровень управляющего комитета |