Управление рисками проекта

Содержание

Слайд 2

ПЛАНИРОВАНИЕ ПРОЕКТА ВОПРОСЫ: 1. Основные понятия 2. Планирование управления рисками 3.

ПЛАНИРОВАНИЕ ПРОЕКТА

ВОПРОСЫ:
1. Основные понятия
2. Планирование управления рисками
3.

Идентификация рисков
4. Качественный анализ рисков
5. Количественный анализ рисков
6. Планирование реагирования на риски
7. Главные риски программных проектов и способы реагирования
8. Управление проектом, направленное на снижение рисков
9. Мониторинг и контроль рисков
10. Выводы
11. Контрольные вопросы
Слайд 3

Основные понятия Том Демарко в своей книге [1] пишет: «Проект без

Основные понятия

Том Демарко в своей книге [1] пишет:
«Проект без риска

— удел неудачников. Риски и выгода всегда ходят рука об руку».
Мы уже говорили о том, что, в силу специфики отрасли, программная инженерия остается и, в ближайшем будущем, будет оставаться производством с высоким уровнем рисков.
Если задуматься, то все, что мы делаем, управляя проектом разработки ПО, направлено на борьбу с рисками не уложиться в срок, перерасходовать ресурсы, разработать не тот продукт, который требуется.
Слайд 4

Основные понятия Риск это проблема, которая еще не возникла, а проблема

Основные понятия

Риск это проблема, которая еще не возникла, а проблема —

это риск, который материализовался. Риск характеризуется следующими характеристиками [2] (рис. 8.1):
Причина или источник. Явление, обстоятель-ство обусловливающее наступление риска.
Симптомы риска, указание на то, что событие риска произошло или вот-вот произойдет. Первопричина нам может быть не наблюдаема, например, заразились гриппом. Мы наблюдаем некоторые симптомы — поднялась температура.
Слайд 5

Основные понятия Рис. 8.1. Пример характеристик риска

Основные понятия

Рис. 8.1. Пример характеристик риска

Слайд 6

Основные понятия Последствия риска. Проблема или возможность, которая может реализоваться в

Основные понятия

Последствия риска. Проблема или возможность, которая может реализоваться в проекте

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

Основные понятия Риск это всегда вероятность и последствия. Например, всегда есть

Основные понятия

Риск это всегда вероятность и последствия.
Например, всегда есть вероятность

того, что метеорит упадет на офис центра программных разработок, и это будет иметь катастрофические последствия для проекта.
Однако вероятность наступления этого события настолько мала, что мы в большинстве проектов принимаем это риск и не пытаемся им управлять.
Слайд 8

Основные понятия Майк Ньюэлл, вице-президент компании PSM Consulting, рассказывал, как он

Основные понятия

Майк Ньюэлл, вице-президент компании PSM Consulting, рассказывал, как он объясняет

аудитории на своих лекциях, что такое риск.
Он предлагает сыграть в кости на таких условиях, если на кубике выпадает шестерка, то выигрывает он. Если — любое другое число, то выигрывает слушатель.
Ставка по 1 доллару. Обычно, большая часть аудитории соглашается сыграть на таких условиях. Майк поднимает ставки: $10, $100, $1000.
Постепенно количество желающих поиграть становится все меньше и меньше.
При ставке $1000, как правило, желающих рисковать не остается.
Слайд 9

Основные понятия Принято [3] выделять две категории рисков: «Известные неизвестные». Это

Основные понятия

Принято [3] выделять две категории рисков:
«Известные неизвестные». Это те

риски, которые можно идентифицировать и подвергнуть анализу. В отношении таких рисков можно спланировать ответные действия.
«Неизвестные неизвестные». Риски, которые невозможно идентифицировать и, следовательно, спланировать ответные действия.
Слайд 10

Основные понятия Неизвестные риски это непредвиденные обстоятельства. Единственное, что мы можем

Основные понятия

Неизвестные риски это непредвиденные обстоятельства.
Единственное, что мы можем в

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

Основные понятия Девиз разработчиков ПО из Microsoft [2]: «Мы не боремся

Основные понятия

Девиз разработчиков ПО из Microsoft [2]: «Мы не боремся с

рисками — мы ими управляем».
Цели управления рисками проекта — снижение вероятности возникновения и/или значимости воздействия неблагоприятных для проекта событий.
Адекватное управление рисками в компании — признак зрелости производственных процессов.
Отказываться от управления проектными рисками это все равно, что в кинотеатре не иметь огнетушителей и плана эвакуации на случай пожара.
Слайд 12

Планирование управления рисками Управление рисками это определенная деятельность, которая выполняется в

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

Управление рисками это определенная деятельность, которая выполняется в проекте

от его начала до завершения.
Как и любая другая работа в проекте управление рисками требует времени и затрат ресурсов.
Поэтому эта работа обязательно должна планироваться.
Планирование управления рисками — это процесс определения подходов и планирования операций по управлению рисками проекта.
Слайд 13

Планирование управления рисками Тщательное и подробное планирование управления рисками позволяет: выделить

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

Тщательное и подробное планирование управления рисками позволяет:
выделить достаточное количество

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

Планирование управления рисками Планирование управления рисками должно быть завершено на ранней

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

Планирование управления рисками должно быть завершено на ранней стадии

планирования проекта, поскольку оно крайне важно для успешного выполнения других процессов.
В соответствии с [3] исходными данными для планирования управления рисками служат:
Отношение к риску и толерантность к риску организаций и лиц, участвующих в проекте, оказывает влияние на план управления проектом. Оно должно быть зафиксировано в изложении основных принципов и подходов к управлению рисками.
Слайд 15

Планирование управления рисками Стандарты организации. Организации могут иметь заранее разработанные подходы

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

Стандарты организации. Организации могут иметь заранее разработанные подходы к

управлению рисками, например категории рисков, общие определение понятий и терминов, стандартные шаблоны, схемы распределения ролей и ответственности, а также определенные уровни полномочий для принятия решений.
Слайд 16

Планирование управления рисками Описание содержания проекта подробно описывает результаты поставки проекта

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

Описание содержания проекта подробно описывает результаты поставки проекта и

работы, необходимые для создания этих результатов поставки.
План управления проектом, формальный документ, в котором указано, как будет исполняться проект и как будет происходить мониторинг и управление проектом.
Слайд 17

Планирование управления рисками План управления рисками обычно включает в себя следующие

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

План управления рисками обычно включает в себя следующие элементы:


Определение подходов, инструментов и источников данных, которые могут использоваться для управления рисками в данном проекте.
Распределение ролей и ответственности. Список позиций выполнения, поддержки и управления рисками для каждого вида операций, включенных в план управления рисками, назначение сотрудников на эти позиции и разъяснение их ответственности.
Слайд 18

Планирование управления рисками Выделение ресурсов и оценка стоимости мероприятий, необходимых для

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

Выделение ресурсов и оценка стоимости мероприятий, необходимых для управления

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

Планирование управления рисками Категории рисков. Структура, на основании которой производится систематическая

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

Категории рисков. Структура, на основании которой производится систематическая и

всесторонняя идентификация рисков с нужной степенью детализации. Такую структуру можно разработать с помощью составления иерархической структуры рисков (рис. 8.2).
Общие подходы для определения уровней вероятности, шкалы воздействия и близости наступления рисков на проект.
Слайд 20

Планирование управления рисками Рис. 8.2. Пример иерархической структуры рисков проекта

Планирование управления рисками
Рис. 8.2. Пример иерархической структуры рисков проекта

Слайд 21

Планирование управления рисками Шкала оценки воздействия отражает значимость риска (табл. 8.1)

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

Шкала оценки воздействия отражает значимость риска (табл. 8.1) в

случае его возникновения.
Шкала оценки воздействия может различаться в зависимости:
от потенциально затронутой риском цели,
типа и размера проекта,
принятыми в организации стратегиями и его финансовым состоянием,
а также от чувствительности организации к конкретному виду воздействий.
Слайд 22

Планирование управления рисками Хотя риск может воздействовать и на сроки проекта,

Планирование управления рисками
Хотя риск может воздействовать и на сроки проекта, и

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

Планирование управления рисками Похожая шкала может быть применена для оценки вероятности наступления риска

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

Похожая шкала может быть применена для оценки вероятности наступления

риска
Слайд 24

Планирование управления рисками Еще одной важной характеристикой риска является близость его

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

Еще одной важной характеристикой риска является близость его наступления.


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

Идентификация рисков Идентификация рисков — это выявление рисков, способных повлиять на

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

Идентификация рисков — это выявление рисков, способных повлиять на проект,

и документальное оформление их характеристик.
Это итеративный процесс, который периодически повторяется на всем протяжении проекта, поскольку в рамках его жизненного цикла могут обнаруживаться новые риски.
Исходные данные для выявления и описания характеристик рисков могут браться из разных источников.
Слайд 26

Идентификация рисков В первую очередь это база знаний организации. Информация о

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

В первую очередь это база знаний организации.
Информация о выполнении

прежних проектов может быть доступна в архивах предыдущих проектов.
Следует помнить, что проблемы завершенных и выполняемых проектов, это, как правило, риски в новых проектах.
Слайд 27

Идентификация рисков Другим источником данных о рисках проекта может служить разнообразная

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

Другим источником данных о рисках проекта может служить разнообразная информация

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

Идентификация рисков Каждый проект задумывается и разрабатывается на основании ряда гипотез,

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

Каждый проект задумывается и разрабатывается на основании ряда гипотез, сценариев

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

Идентификация рисков Для сбора информации о рисках могут применяться различные подходы.

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

Для сбора информации о рисках могут применяться различные подходы.
Среди

этих подходов наиболее распространены:
Опрос экспертов
Мозговой штурм
Метод Дельфи
Карточки Кроуфорда
Слайд 30

Идентификация рисков Цель опроса экспертов — идентифицировать и оценить риски путем

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

Цель опроса экспертов — идентифицировать и оценить риски путем интервью

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

Идентификация рисков Перед опросом эксперт должен получить всю необходимую вводную информацию.

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

Перед опросом эксперт должен получить всю необходимую вводную информацию.
Деятельность

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

Идентификация рисков К участию в мозговом штурме привлекаются квалифицированные специалисты, которым

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

К участию в мозговом штурме привлекаются квалифицированные специалисты, которым дают

«домашнее задание» — подготовить свои суждения по определенной категории рисков.
Затем проводится общее собрание, на котором специалисты по очереди высказывают свои мнения о рисках.
Важно: споры и замечания не допускаются.
Все риски записываются, группируются по типам и характеристикам, каждому риску дается определение.
Цель — составить первичный перечень возможных рисков для последующего отбора и анализа.
Слайд 33

Идентификация рисков Метод Дельфи во многом похож на метод мозгового штурма.

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

Метод Дельфи во многом похож на метод мозгового штурма. Однако

есть важные отличия.
Во-первых, при применении этого метода эксперты участвуют в опросе анонимно. Поэтому результат характеризуется меньшей субъективностью, меньшей предвзятостью и меньшим влиянием отдельных экспертов.
Во-вторых, опрос экспертов проводится в несколько этапов.
На каждом этапе модератор рассылает анкеты, собирает и обрабатывает ответы. Результаты опроса рассылаются экспертам снова для уточнения их мнений и оценок.
Такой подход позволяет достичь некоего общего мнения специалистов о рисках.
Слайд 34

Идентификация рисков Для быстрого выявления рисков можно воспользоваться еще одной из

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

Для быстрого выявления рисков можно воспользоваться еще одной из методик

социометрии, которая является известной как "Карточки Кроуфорда" [5] .
Суть этой методики в следующем. Собирается группа экспертов 7-10 человек.
Каждому участнику мини-исследования раздается по десять карточек (для этого вполне подойдет обычная бумага для записок).
Слайд 35

Идентификация рисков Ведущий задает вопрос: "Какой риск является наиболее важным в

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

Ведущий задает вопрос: "Какой риск является наиболее важным в этом

проекте?"
Все респонденты должны записать наиболее, по их мнению, важный риск в данном проекте.
При этом никакого обмена мнениями не должно быть.
Ведущий делает небольшую паузу, после чего вопрос повторяется. Участник не может повторять в ответе один и тот же риск.
Слайд 36

Идентификация рисков После того как вопрос прозвучит десять раз, в распоряжении

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

После того как вопрос прозвучит десять раз, в распоряжении ведущего

появятся от 70 до 100 карточек с ответами.
Если группа подобрана хорошо (в том смысле, что в нее входят люди с различными точками зрения), вероятность того, что участники эксперимента укажут большинство значимых для проекта рисков, весьма высока.
Остается составить список названных рисков и раздать его участникам для внесения изменений и дополнений.
Слайд 37

Идентификация рисков В качестве источника информации при выявлении рисков могут служить

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

В качестве источника информации при выявлении рисков могут служить различные

доступные контрольные списки рисков проектов разработки ПО, которые следует проанализировать на применимость к данному конкретному проекту.
Например, Барии Боэм [6] приводит список 10 наиболее распространенных рисков программного проекта:
Слайд 38

Идентификация рисков Дефицит специалистов. Нереалистичные сроки и бюджет. Реализация несоответствующей функциональности.

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

Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского

интерфейса.
"Золотая сервировка", перфекционизм, ненужная оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Слайд 39

Идентификация рисков Нехватка информации о внешних компонентах, определяющих окружение системы или

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

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

в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
"Разрыв" в квалификации специалистов разных областей знаний.
Слайд 40

Идентификация рисков Демарко и Листер [1] приводят свой список из пяти

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

Демарко и Листер [1] приводят свой список из пяти наиболее

важных источников рисков любого проекта разработки ПО:
Изъяны календарного планирования
Текучесть кадров
Раздувание требований
Нарушение спецификаций
Низкая производительность
Слайд 41

Идентификация рисков Не существует исчерпывающих контрольных списков рисков программного проекта, поэтому

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

Не существует исчерпывающих контрольных списков рисков программного проекта, поэтому необходимо

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

Идентификация рисков Если вернуться к примеру проекта создания «Автоматизированной системы продажи

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

Если вернуться к примеру проекта создания «Автоматизированной системы продажи документации»,

который мы рассматривали в предыдущих лекциях,
то список главных выявленных рисков может выглядеть следующим образом:
Слайд 43

Идентификация рисков За процессом идентификации рисков следует процесс их качественного анализа.

Идентификация рисков
За процессом идентификации рисков следует процесс их качественного анализа.

Слайд 44

Качественный анализ рисков Качественный анализ рисков включает в себя расстановку рангов

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

Качественный анализ рисков включает в себя расстановку рангов

для идентифицированных рисков.
При анализе вероятности и влияния предполагается, что никаких мер по предупреждению рисков не производится.
Качественный анализ рисков включает:
Определение вероятности реализации рисков.
Определение тяжести последствий реализации рисков.
Определения ранга риска по матрице «вероятность — последствия».
Определение близости наступления риска.
Оценка качества использованной информации.
Слайд 45

Качественный анализ рисков Для качественной оценки вероятности реализации риска и определения

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

Для качественной оценки вероятности реализации риска и определения

тяжести последствий его реализации применяется, как правило, общепринятые в организации шкалы, примеры которых мы приводили ранее.
Для определения ранга риска используется матрица вероятностей и последствий (рис. 8.3).
Ранг риска определяется произведением веса вероятности и значимости последствий.
Слайд 46

Качественный анализ рисков Рис. 8.3. Ранг риска и матрица вероятностей и последствий

Качественный анализ рисков
Рис. 8.3. Ранг риска и матрица вероятностей и

последствий
Слайд 47

Качественный анализ рисков Могут, конечно, существовать и более сложные шкалы для

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

Могут, конечно, существовать и более сложные шкалы для

оценок вероятностей, значимости последствий и ранга рисков.
Встречались шкалы, которые содержали до 10 градаций.
Но, на наш взгляд, наиболее прагматичный подход — это использовать трехуровневое ранжирование.
Слайд 48

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

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

Слайд 49

Качественный анализ рисков Для оценки рисков необходима точная и адекватная информация.

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

Для оценки рисков необходима точная и адекватная информация.


Использование неточной информации ведет к ошибкам в оценке.
Неверная оценка риска также является риском.
Критерии оценки качества используемой при анализе информации выглядят так:
Степень понимания риска.
Доступность и полнота информации о риске.
Надежность, целостность и достоверность источников данных.
Слайд 50

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

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

Слайд 51

Качественный анализ рисков Результаты качественного анализа используются в ходе последующего количественного

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

Результаты качественного анализа используются в ходе
последующего количественного

анализа рисков
и планирования реагирования на риски.
Слайд 52

Количественный анализ рисков Количественный анализ производится в отношении тех рисков, которые

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

Количественный анализ производится в отношении тех рисков, которые в

процессе качественного анализа были квалифицированы как имеющие высокий и средний ранг.
Для количественного анализа рисков могут быть использованы следующие методы:
Анализ чувствительности.
Анализ дерева решений.
Моделирование и имитация.
Слайд 53

Количественный анализ рисков Анализ чувствительности помогает определить, какие риски обладают наибольшим

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

Анализ чувствительности помогает определить, какие риски обладают наибольшим потенциальным

влиянием на проект.
В процессе анализа устанавливается, в какой степени неопределенность каждого элемента проекта отражается на исследуемой цели проекта, если остальные неопределенные элементы принимают базовые значения.
Результаты представляются, как правило, в виде диаграммы «торнадо».
Рис. 8.4 представляет пример такой диаграммы, которая отражает влияние на проектные трудозатраты различных факторов профессионализма разработчиков ПО
Слайд 54

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

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

Слайд 55

Количественный анализ рисков Анализ последствий возможных решений проводится на основе изучения

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

Анализ последствий возможных решений проводится на основе изучения диаграммы

дерева решений, которая описывает рассматриваемую ситуацию с учетом каждой из имеющихся возможностей выбора и возможного сценария.
Рис. 8.5 представляет пример диаграммы дерева решений на дугах которой проставлены вероятности и затраты при развитии событий по тому или иному сценарию.
Критерием для принятия решения служит математическое ожидание потерь от его принятия.
Слайд 56

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

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

Слайд 57

Количественный анализ рисков При моделировании рисков проекта используется модель для определения

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

При моделировании рисков проекта используется модель для определения последствий

от воздействия подробно описанных неопределенностей на результаты проекта в целом.
Моделирование обычно проводится с помощью метода Монте-Карло.
Слайд 58

Количественный анализ рисков Интересный пример подобной модели — система Riskology от

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

Интересный пример подобной модели — система Riskology от Демарко

и Листера, который иллюстрирует применение метода Монте-Карло для получения информации о том, какой запас времени будет необходим для того, чтобы преодолеть влияние всех неуправляемых рисков проекта, приведен в источнике [8].
Модель позволяет учесть пять основных (рис. 8.6) и пять дополнительных рисков проекта.
Слайд 59

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

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

Слайд 60

Количественный анализ рисков Характеристики предопределенных в системе Riskology рисков пользователь может

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

Характеристики предопределенных в системе Riskology рисков пользователь может изменить,

задав значения минимальной, максимальной и наиболее вероятной задержки сроков сдачи проекта из-за влияния данного риска.
Можно включить в модель дополнительные собственные риски.
Результат моделирования по методу Монте-Карло будет представлен в виде гистограммы распределения срока завершения оцениваемого проекта (рис. 8.7).
Слайд 61

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

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

Слайд 62

Количественный анализ рисков На диаграмме также приведено количество случаев, примерно 80

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

На диаграмме также приведено количество случаев, примерно 80 из

500 прогонов, в которых проект, согласно результатам моделирования, был отменен до своего завершения.
Слайд 63

Планирование реагирования на риски Планирование реагирования на риски — это процесс

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

Планирование реагирования на риски — это процесс разработки

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

Планирование реагирования на риски Согласно [3] возможны четыре метода реагирования на

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

Согласно [3] возможны четыре метода реагирования на риски:


Уклонение от риска (risk avoidance).
Передача риска (risk transference).
Снижение рисков (risk mitigation).
Принятие риска (risk acceptance).
Слайд 65

Планирование реагирования на риски Уклонение от риска предполагает изменение плана управления

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

Уклонение от риска предполагает изменение плана управления проектом

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

Планирование реагирования на риски Например, уклониться от риска можно, если отказаться

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

Например, уклониться от риска можно,
если отказаться от

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

Планирование реагирования на риски Передача риска подразумевает переложение негативных последствий угрозы

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

Передача риска подразумевает переложение негативных последствий угрозы с

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

Планирование реагирования на риски Например, заказ на стороне разработки рискованного компонента

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

Например, заказ на стороне разработки рискованного компонента по

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

Планирование реагирования на риски Снижение рисков предполагает понижение вероятности и/или последствий

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

Снижение рисков предполагает понижение вероятности и/или последствий негативного

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

Планирование реагирования на риски Или регулярная ревизия поставок заказчиком может снизить

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

Или регулярная ревизия поставок заказчиком может снизить вероятность

риска его неудовлетворенности конечным результатом.
Если в проектной команде высока вероятность увольнения сотрудников, то введение на начальной стадии в проект дополнительных (избыточных) людских ресурсов снижает потери при увольнении членов команды, поскольку не будет затрат на «въезд» в проектный контекст новых участников.
Слайд 71

Планирование реагирования на риски И, наконец, принятие риска означает, что команда

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

И, наконец, принятие риска означает, что команда проекта

осознанно приняла решение не изменять план управления проектом в связи с риском или не нашла подходящей стратегии реагирования.
Мы вынуждены принимать все «неизвестные риски».
Принятие это то, что всегда происходит, когда мы вообще не управляем рисками.
Если же мы управляем рисками, то мы можем страховать риски, закладывая резерв в оценки срока завершения и/или трудозатрат.
Слайд 72

Планирование реагирования на риски Проактивное отношение к принятым рискам может состоять

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

Проактивное отношение к принятым рискам может состоять в

разработке плана реагирования на риски.
Этот план может быть введен в действие только при заранее определенных условиях, если есть уверенность и достаточное количество признаков того, что данный план будет успешно выполнен.
Слайд 73

Планирование реагирования на риски Важно помнить о вторичных рисках (Secondary Risks),

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

Важно помнить о вторичных рисках (Secondary Risks),
возникающих

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

Главные риски и реагирование на них Из установившейся практики список из

Главные риски и реагирование на них

Из установившейся практики список из пяти

главных причин провала программных проектов выглядит следующим образом:
Требования заказчика отсутствуют / не полны / подвержены частым изменениям.
Отсутствие необходимых ресурсов и опыта.
Отсутствие рабочего взаимодействия с заказчиком.
Неполнота планирования. «Забытые работы».
Ошибки в оценках трудоемкостей и сроков работ.
Слайд 75

Главные риски и реагирование на них По-прежнему, приходится сталкиваться с программными

Главные риски и реагирование на них

По-прежнему, приходится сталкиваться с программными проектами,

в которых отсутствуют какие-либо определенные цели и требования.
Цитата из жизни: «Была бы разработана хорошая программа, а какой процесс автоматизировать с ее помощью, мы найдем».
К этому можно добавить только одно: «Когда человек не знает, к какой пристани он держит путь, для него никакой ветер не будет попутным» (Сенека Луций Аней, философ, 65-3 до н.э.)
Слайд 76

Главные риски и реагирование на них К часто упускаемым требованиям можно

Главные риски и реагирование на них

К часто упускаемым требованиям можно отнести:


Функциональные
Программы установки, настройки, конфигурации.
Миграция данных.
Интерфейсы с внешними системами.
Справочная система.
Общесистемные
Производительность.
Надежность.
Открытость.
Масштабируемость.
Безопасность.
Кросплатформенность.
Эргономичность.
Слайд 77

Главные риски и реагирование на них Как правило, эти требования «всплывают»

Главные риски и реагирование на них

Как правило, эти требования «всплывают» при

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

Главные риски и реагирование на них Если вероятность изменений требований проекта

Главные риски и реагирование на них

Если вероятность изменений требований проекта высока,

то возможны следующие подходы для реагирования на данный риск:
Переоценка проекта каждый раз, когда требования добавляются / изменяются (уклонение).
Итерационная разработка. Контракт с компенсацией затрат на основе «Time & Materials» (передача риска Заказчику).
Учет в оценках трудоемкости и сроков возможности роста требований, например, на 50% (резервирование риска).
Слайд 79

Главные риски и реагирование на них И еще, при сборе требований

Главные риски и реагирование на них

И еще, при сборе требований следует

соблюдать принцип минимализма Вольтера:
«Рассказ закончен не тогда, когда в него нечего добавить, а тогда, когда из него нечего больше выкинуть».
Для большинства программных продуктов применим принцип Парето:
80% ценности продукта
заключены лишь в 20% требований к нему.
Слайд 80

Главные риски и реагирование на них Если у нас в проекте

Главные риски и реагирование на них

Если у нас в проекте недостаточно

квалифицированных специалистов, то мы можем снизить последствия этого риска, применив следующие действия:
Привлечь экспертов-консультантов на начальных этапах.
Учитывать в оценках трудоемкости издержки на обучение сотрудников.
Уменьшать потери от текучести кадров, привлекая на начальном этапе избыточное число участников.
Учесть в оценках «время разгона» для новых сотрудников.
Слайд 81

Главные риски и реагирование на них Для установления открытых и доверительных

Главные риски и реагирование на них

Для установления открытых и доверительных отношений

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

Главные риски и реагирование на них При планировании работ по проекту

Главные риски и реагирование на них

При планировании работ по проекту часто

«забывают»:
Обучение.
Координация работ.
Уточнение требований.
Управление конфигурациями.
Разработка и поддержка скриптов автосборки.
Разработка автотестов.
Создание тестовых данных.
Обработка запросов на изменения.
Слайд 83

Главные риски и реагирование на них И еще. Не стоит надеяться,

Главные риски и реагирование на них

И еще. Не стоит надеяться, что

участники проекта будут каждую неделю по 40 часов работать именно над вашим проектом. Есть множество причин, по которым они не смогут работать по проекту 100% своего времени.
К списку наиболее распространенных причин этого относятся:
Сопровождение действующих систем.
Повышение квалификации.
Участие в подготовке технико-коммерческих предложений.
Участие в презентациях.
Административная работа.
Отпуска, праздники, больничные.
Слайд 84

Главные риски и реагирование на них Рекомендация, планировать, что разработчики, которые

Главные риски и реагирование на них

Рекомендация,
планировать, что разработчики, которые назначены

в ваш проект на 100% будут реально работать над вашими задачами в среднем от 24 до 32 часов в неделю.
Слайд 85

Управление снижением рисков На стадии инициации проекта оценка его трудоемкости имеет

Управление снижением рисков

На стадии инициации проекта оценка его трудоемкости имеет погрешность

от -50% до +100% [4].
Это, если оценка хорошая!
А если плохая, то неопределенность, а, следовательно, и риски сорвать сроки и превысить плановую трудоемкость, могут быть в разы больше.
Если не прилагать специальных усилий этот «дамоклов меч» неопределенности будет висеть над проектом на всем его протяжении (рис. 8.8).
Слайд 86

Управление снижением рисков Рис. 8.8. Неопределенность не уменьшается, если управление не направлено на раннее разрешение рисков

Управление снижением рисков
Рис. 8.8. Неопределенность не уменьшается, если управление не направлено

на раннее разрешение рисков
Слайд 87

Управление снижением рисков Проектом следует управлять так, чтобы риски несвоевременной сдачи

Управление снижением рисков

Проектом следует управлять так, чтобы риски несвоевременной сдачи и

перерасхода ресурсов постоянно снижались.
Ранее мы уже говорили о том, что 80% ценности разработки обусловлена лишь 20% требований к продукту, без реализации которых продукт для заказчика становится просто ненужным.
Остальные требования, как правило, так называемые «украшательства», от части которых заказчик, как правило, может отказаться, чтобы получить проект в срок.
Поэтому следует в первую очередь реализовывать ключевые функциональные требования.
Слайд 88

Управление снижением рисков Но есть и еще архитектурные риски. Известно, что

Управление снижением рисков

Но есть и еще архитектурные риски.
Известно, что закон

Парето применим и к потреблению вычислительных ресурсов: 80% потребления ресурсов (время и память) приходится на 20% компонентов.
Поэтому, необходимо реализовывать архитектурно-значимые требования так же в первую очередь, создавая «представительный» прототип будущей системы, который «простреливает» весь стек, применяемых технологий.
Прототип позволит измерить и оценить общесистемные свойства будущего продукта: доступность, быстродействие, надежность, масштабируемость и проч. (рис. 8.9).
Слайд 89

Управление снижением рисков Рис. 8.9. Определение приоритетов требований на первые итерации проекта

Управление снижением рисков


Рис. 8.9. Определение приоритетов требований на первые итерации проекта


Слайд 90

Управление снижением рисков Ошибка — реализовывать сначала легкие требования, чтобы продемонстрировать

Управление снижением рисков

Ошибка — реализовывать сначала легкие требования, чтобы продемонстрировать быстрый

прогресс проекта.
Управление, нацеленное на снижение рисков, позволяет существенно снизить неопределенность на ранних стадиях проекта (рис. 8.10).
Слайд 91

Управление снижением рисков Рис. 8.10. Управление, нацеленное на снижение рисков, позволяет уменьшать неопределенность

Управление снижением рисков
Рис. 8.10. Управление, нацеленное на снижение рисков, позволяет уменьшать

неопределенность
Слайд 92

Управление снижением рисков Проработка ключевых функциональных требований и детальное планирование их

Управление снижением рисков

Проработка ключевых функциональных требований и детальное планирование их реализации

позволяет уменьшить разброс начальных оценок, примерно, в 2 раза: от -30% до +50%.
Детальное проектирование и разработка прототипа будущей системы позволит получить еще более точные оценки общей трудоемкости: от -10% до +15%.
Слайд 93

Управление снижением рисков Может оказаться так, что по результатам прототипирования, уточненные

Управление снижением рисков

Может оказаться так, что по результатам прототипирования, уточненные оценки

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

Управление снижением рисков Если с заказчиком не удается найти взаимоприемлемое решение

Управление снижением рисков

Если с заказчиком не удается найти взаимоприемлемое решение при

первоначальной оценке проекта, то разумно попытаться договориться о выполнении проекта в 2 этапа с самостоятельным финансированием:
Исследование. Бизнес-анализ, уточнение требований, проектирование и прототипироание решения, уточнение суммарных оценок трудозатрат. Эта работа, как правило, требует 10 % общих трудозатрат и 20% времени всего проекта.
Непосредственно реализация. Если уточненные оценки трудозатрат окажутся приемлемыми для заказчика.
Слайд 95

Мониторинг и контроль рисков Управление рисками должно осуществляться на протяжении всего

Мониторинг и контроль рисков

Управление рисками должно осуществляться на протяжении всего проекта.


Не вести мониторинг рисков в ходе проекта — все равно, что не следить за уровнем топлива при поездке на автомобиле.
Мониторинг и управление рисками — это
процесс идентификации, анализа и планирования реагирования на новые риски,
отслеживания ранее идентифицированных рисков,
а также проверки и исполнения операций реагирования на риски
и оценка эффективности этих операций.
Слайд 96

Мониторинг и контроль рисков В процессе мониторинга и управления рисками используются

Мониторинг и контроль рисков

В процессе мониторинга и управления рисками используются различные

методики, например, анализ трендов и отклонений, для выполнения которых необходимы количественные данные об исполнении, собранные в процессе выполнения проекта.
Мониторинг и управления рисками включает в себя следующие задачи:
Пересмотр рисков.
Аудит рисков.
Анализ отклонений и трендов.
Слайд 97

Мониторинг и контроль рисков Пересмотр рисков должен проводиться регулярно, согласно расписанию.

Мониторинг и контроль рисков

Пересмотр рисков должен проводиться регулярно, согласно расписанию.
Управление

рисками проекта должно быть одним из пунктов повестки дня всех совещаний команды проекта.
Неплохо начинать каждый статус митинг с вопроса: «Ну и какие еще неприятности нас ожидают?»
Идентификация новых рисков, и пересмотр известных рисков происходит с использованием процессов, описанных ранее.
Слайд 98

Мониторинг и контроль рисков Аудит рисков предполагает изучение и предоставление в

Мониторинг и контроль рисков

Аудит рисков предполагает
изучение и предоставление в документальном

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

Выводы Отказываться от управления проектными рисками это все равно, что в

Выводы

Отказываться от управления проектными рисками это все равно, что в кинотеатре

не иметь огнетушителей и плана эвакуации на случай пожара.
Все, что мы делаем, управляя проектом разработки ПО, должно быть направлено на борьбу с рисками:
не уложиться в срок,
перерасходовать ресурсы,
разработать не тот продукт, который требуется.
Слайд 100

Выводы Цели управления рисками проекта — снижение вероятности возникновения и/или значимости воздействия неблагоприятных для проекта событий.

Выводы

Цели управления рисками проекта — снижение вероятности возникновения и/или значимости воздействия

неблагоприятных для проекта событий.
Слайд 101

Выводы Главные причины провала программных проектов: Требования заказчика отсутствуют / не

Выводы

Главные причины провала программных проектов:
Требования заказчика отсутствуют / не полны

/ подвержены частым изменениям.
Отсутствие необходимых ресурсов и опыта.
Отсутствие рабочего взаимодействия с заказчиком.
Неполнота планирования. «Забытые работы».
Ошибки в оценках трудоемкостей и сроков работ.
Слайд 102

Контрольные вопросы 1. Понятие риски проекта и его категории. 2. Какие

Контрольные вопросы

1. Понятие риски проекта и его категории.
2. Какие исходные данные

используются при планировании управления рисками?
3. Что включает план управления рисками?
4. Что отражают шкала оценки воздействия риска, шкала оценки вероятности наступления риска и шкала оценки близости риска?
5. Что такое идентификация риска?
6. Какие методы используются для сбора информации о рисках?
7. Назовите наиболее распространенные риски программного проекта.
Слайд 103

Контрольные вопросы 8. Что такое качественный анализ рисков? 9. Что такое

Контрольные вопросы

8. Что такое качественный анализ рисков?
9. Что такое количественный анализ

рисков?
10. Какие методы реагирования на риски существуют?
11. Главные риски программных проектов.
12. Какие существую способы реагирования на риски?
13. Как необходимо управлять проектом, чтобы снизить риски?
14. Что включает мониторинг и контроль рисков?