Первое, что необходимо сделать в управлении рисками проекта – запланировать их. В переводе на обыденный язык это означает, что мы признаем наличие рисков в проекте и намерены затратить некоторое количество времени и денег на управление рисками. Или сэкономить - если риск положительный, например, предполагаемое удешевление применяющихся в проекте электронных устройств.
Затем нам необходимо произвести идентификацию рисков. Для этого команда проекта и эксперты, которых удалось заполучить, собираются в одной комнате и, забыв про позитивное мышление, пытаются составить полный список того, что в данном проекте грозит нарушить наши планы. Затем позитивное мышление включается, ищутся и фиксируются благоприятные события, которые также могут произойти. Не надо пытаться найти все риски – вполне хватит полтора десятка отрицательных и пяти положительных, поскольку данный список будет изменяться и дополняться по ходу проекта. Можно также использовать и метод Дельфи, и карточки Кроуфорда, но обязательно должен быть мозговой штурм. Если есть информация о рисках подобных проектов, проводившихся ранее – она будет крайне полезна и сэкономит массу времени.
Далее мы производим сортировку рисков - группируем их по категориям, с учетом степени их значимости для проекта. Для этого можно использовать внешние источники для описания групп рисков. Так, например, в известной книге “Вальсируя с медведями” ДеМарко и Листера приводятся ТОР5 групп рисков для разработки ПО, сгруппированных по степени значимости.
Задавайте вопросы нашему консультанту, он ждет вас внизу экрана и всегда онлайн специально для Вас. Не стесняемся, мы работаем совершенно бесплатно!!!
Также оказываем консультации по телефону: 8 (800) 600-76-83, звонок по России бесплатный!
1. Внутренние изъяны календарного планирования.
2. Изменение требований.
3. Текучесть кадров.
4. Нечеткие спецификации.
5. Низкая производительность.
Обратите внимание, что риск, связанный с плохой работой персонала, стоит на последнем месте. Говоря иначе, основные риски состоят не в том, что исполнители работают медленно, а в том, что исполнители работают не над тем, над чем нужно.
Цель данного этапа состоит также и в том, чтобы отсеять риски, являющиеся малозначимыми для проекта. Например, землетрясение силой 8 баллов может уничтожить весь город, в котором ведется работа над проектом, но вероятность этого землетрясения – миллиардные доли процента, если речь идет о Москве. Также вероятно заболевание на неделю одного из тестеров, но нет смысла учитывать это на ранних этапах планирования – лучше объявить риск с названием “недоступность персонала” и включать туда все подобные риски.
При планировании рисков следует помнить, что это - не самоцель. Можно спланировать все возможные риски и потом тратить массу времени на их мониторинг, тогда как не будет хватать времени на остальное. Лучше установить для себя некоторый порог рисков по стоимости и регулярно отслеживать только те риски, которые выходят за это порог. Остальные, мелкие риски лучше писать в раздел "Прочее" и рассматривать этот раздел, скажем, раз в месяц.
На следующем этапе мы производим количественный анализ рисков. Собственно, это анализ влияния рисков на стоимость и сроки проектов. Полученные на данном этапе цифры используются в качестве предварительных, далее, на этапе планирования реагирования на риски, они могут быть изменены. Сейчас же мы просто оцениваем величину опасности или благоприятные возможности.
Далее идет этап планирования реагирования на риски.
Мы можем реагировать на риски одним из четырех способов:
1. Уклонение от риска – предпринимаем корректирующие действия, чтобы риск не наступил вообще. Например, настаиваем на исключении из ТЗ спорного пункта, возможность успешной реализации которого сейчас не можем даже оценить.
2. Ослабление риска - предпринимаем корректирующие действия, чтобы наступивший риск имел возможно меньшее влияние. Типичный пример – фраза в ТЗ: “уточняется на этапе технического проекта”.
3. Передача риска – мы передаем риск другой стороне. Это не только покупка страховки. Запись о форс-мажорных обстоятельствах в договоре – пример бесплатного перекладывания рисков большой величины на заказчика.
4. Принятие риска – мы считаем, что с риском поделать ничего нельзя, поэтому просто закладываем резервы в бюджет и график для покрытия данного риска.
Обратите внимание, что когда на риск проекта не обращают внимания на этапе идентификации, способ реагирования на него всегда будет “Принятие” – но в данном случае резервы в график и бюджет не закладываются. Именно поэтому важно идентифицировать все риски, а потом отбрасывать малозначимые и маловероятные.
Приходит отец домой, а его ребенок плачет. Отец спрашивает ребенка: - Почему ты плачешь? Отвечает ему ребенок: - Почему ты мне папа, а я не сын тебе? Кто же это плакал?
Статью подготовил директор по развитию предпринимательства и конкуренции ОАО "Акса" Корчагин Юлиан Андриянович. 
