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