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

На основании чего осуществляется приоритезация рисков

  • автор:

Анализ и приоритезация рисков Введение

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

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

Анализ и приоритезация рисков

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

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

Исходные данные

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

Процесс анализа рисков

Существует много количественных и качественных методик проведения приоритезации рисков. Одна из них, простая и удобная в использовании, заключается в выработке проектной группой коллективных оценок двух общепризнанных параметров каждого из рисков – вероятности (probability) и угрозы (impact). Произведение этих двух величин дает единую метрику риска, называемую ожидаемой величиной (exposure).

Вероятность риска

Вероятность риска – это мера возможности того, что последствие риска, описанное в его формулировке, действительно наступит. Вероятность риска должна быть больше нуля, так как иначе он из себя ничего не представляет. Также вероятность риска должна быть меньше 100%, иначе он не содержит неопределенности и представляет собой уже известную проблему. Оценка вероятности и ее применение – достаточно сложная задача. Однако имеющиеся на уровне предприятия или индустрии базы данных о рисках способны помочь получить такие оценки исходя из опыта значительного количества схожих проектов. В большинстве ситуаций проектные группы могут представить собственный опыт и/или имеющиеся в индустрии опытные данные в виде простых и понятных формулировок, которые затем могут быть превращены в числовые значения. Это может быть простейшая градация “низко-средне-высоко”, отображаемая в отдельно взятые численные значения (17%, 50%, 84%), либо же сложные оценки таких выражений как “почти невозможно”, “маловероятно”, “возможно”, “почти наверняка” и т.д. Следующая таблица демонстрирует трехуровневое разделение вероятности

Что такое риски проекта и как ими управлять

Не бывает технологических проектов без рисков. Чем сложнее продукт мы реализуем, чем больше процессов запускаем, тем сильнее рискуем. Обычно дело в неопределенности: заказчик до конца не знает, что хочет → менеджер выбирает некорректные инструменты решения задачи → команда некорректно оценивает бюджет → разработчики допускают ошибки в архитектуре системы. Цепочка событий, которую трудно предсказать.

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

Что нужно знать про проектные риски

Риски проекта — это вероятное негативное событие в проектном управлении, наступление которого препятствует достижению проектной цели. Например, цели, которая имеет стоимостное или временное выражение.

Допустим, мы хотим разработать продукт за 500 000 ₽: просчитали расходы, утвердили смету, приступили к работе. Любое событие, которое приводит к дополнительным расходам, не предусмотренным бюджетом, можно считать риском.

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

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

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

Риски бывают известные и неизвестные:

  • Известные можно прогнозировать и контролировать, для них возможно планирование. Например, если мы заходим в насыщенную конкурентами нишу, то мы прогнозируемо рискуем остаться без достаточного спроса на свой продукт
  • Неизвестные риски не удается прогнозировать и тем более контролировать. Допустим, мы откладываем поставку импортного оборудования на 1 месяц. За этот месяц нефть просаживается в цене, стоимость доллара в России растет, стоимость импортного оборудования вырастает на треть. Мы не имели возможности предугадать рост курса — понесли убытки из-за неизвестных рисков

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

Зачем управлять рисками

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

Допустим, мы внедряем CRM-систему в торговое предприятие. Брифуем заказчика и понимаем, что он не сильно в теме автоматизации — рискуем к середине работы получить новый набор требований к функционалу. Тогда нам придется переделывать часть работы, составлять новый бюджет. Думаем об этом заранее: на этапе согласования технического задания обсуждаем условия пересмотра требований. Потратив час на согласование, страхуем команду от дополнительных издержек и срывов сроков.

Этапы управления рисками

Чтобы грамотно управлять угрозами для бизнеса, мы решили использовать метод фреймворка PMBoK от PMI. Разработчики предлагают поделить процесс управления на 6 этапов:

  1. Планирование управления
  2. Идентификация факторов
  3. Качественная оценка
  4. Количественная оценка
  5. Планирование реакции
  6. Мониторинг и контроль

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

Такую схему из 6 этапов предлагает PMBoK.

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

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

Вот такую проектную схему предлагают разработчики PMBoK.

Диаграмма потоков данных планирования управления рисками в PMBoK.

3 главных аспекта правильного планирования:

  • формирование благоприятной среды управления — гармонизация отношений внутри команды
  • использование заранее заготовленных схем и шаблонов процессов управления
  • создание описательной части и плана управления угрозами

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

Обычно в плане управления указывают:

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

Идентификация

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

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

Классификация рисковых событий по степени их контролируемости.

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

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

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

Фрагмент реестра рисковых ситуаций.

Анализ и оценка рисков проекта

Здесь мы совмещаем качественную и количественную оценку.

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

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

При анализе экспертные оценки делят на две категории: оценки вероятности наступления рисковых событий и оценки их влияния. Для их корректного анализа создают специальную матрицу с оценками. Например, вот такую матрицу предлагают разработчики PMBoK.

Матрица вероятности/воздействия угроз и благоприятных возможностей из PMBoK.

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

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

Чем выше вероятность реализации и существенней влияние на проектов, тем выше степень рисковой угрозы.

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

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

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

Обычно для количественного анализа используют такие методологии:

Вероятностный анализ — оценка на основе статистики по прошлым проекта с учетом вероятностной погрешности.

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

Имитационное моделирование — оценка, сделанная на основе многократных опытов с моделью.

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

Планирование реакции

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

В своей практике мы выработали 4 варианта реакций, которые помогают нам ликвидировать или хотя бы минимизировать последствия от возможных проблем. Вот какие стратегии можно использовать.

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

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

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

4. Использование. Превращаем негатив в позитив. Пример риска проекта: квалификация тестировщика вызывает у руководителя группы вопросы, есть вероятность срыва сроков и снижения качества продукта. Думаем, что делать — в качестве дублера привлекаем более опытного тестировщика. Мы увеличим бюджет, но сократим сроки на выполнение важных для нас процессов с гарантией их качества.

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

Диаграмма потоков данных планирования реакции на угрозы из PMBoK.

Мониторинг и управление

Последний этап — системная работа над выявлением новых угроз, их контроль и реакция в соответствии с планом управления. Обычно эту работу ведут на всех этапах реализации продукта, вплоть до подписания акта приема-передачи. Чем ближе конец работы, тем сильнее последствия может вызвать угроза.

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

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

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

Приоритизация на основе оценки рисков: максимальная эффективность в кратчайшие сроки

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

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

количественно определить критичность требований

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

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

Значит вам нужно использовать метод приоритизации на основе оценки рисков.

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

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

Определение возможности тестирования требований

Как часто вы видели, чтобы менеджеры проектов или руководители групп тестирования старались понять, насколько приемлемы для тестирования те или иные требования к ПО? Или чтобы требования анализировались в рамках «командного упражнения»? Ответом, скорее всего, будет «Очень редко».

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

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

Определение возможности тестирования требований — это первый шаг процесса приоритизации на основе оценки рисков. Следующий вопрос: На каком этапе жизненного цикла разработки ПО или Agile-процесса необходимо определять тестируемость требований? Ответ вполне очевиден. На этапе анализа или планирования спринта бизнес-аналитики должны собрать все требования, а команда тестировщиков должна проверить эти требования и убедиться, что они являются значимыми и могут быть протестированы.

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

Если все требования являются тестируемыми и вы в этом уверены, то это хорошая новость. Однако, если есть какие-то нетестируемые требования, то их можно сделать тестируемыми, применив метод приоритизации на основе оценки рисков.

Делаем требования тестируемыми

Например, одно из требований определено следующим образом: «Приложение должно выдавать сообщение о статусе или отключать пользователя в случае отсутствия его активности в течение примерно 60 секунд».

Если вы внимательно посмотрите на это определение, то увидите некоторые неоднозначности. У вас могут возникнуть следующие вопросы.

  1. О каком приложении идет речь?
  2. Должно оно только выдавать сообщение о статусе, или отключать пользователя, или делать и то и другое?
  3. Указан временной интервал «примерно 60 секунд». И неизбежно возникает вопрос: нужно ли отключать пользователя, если никакой активности нет на протяжении 50 секунд?

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

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

Сущность приоритизации на основе оценки рисков

Приоритизация на основе оценки рисков — это процесс, выполняемый с целью

  • Проверить, являются ли требования тестируемыми
  • Понять, что именно нужно тестировать
  • Приоритизировать требования в зависимости от их критичности. Под критичностью понимается критичность для бизнес», а не с технической точки зрения.

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

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

Третий пункт — это суть процесса приоритизации на основе оценки рисков. При приоритизации на основе оценки рисков мы присваиваем численные значения некоторым входным параметрам каждого требования. Это параметры «Влияние» и «Вероятность».

Например, у вас есть 100 требований. Вы присваиваете численные значения этим входным параметрам для всех 100 требований. Обычно эти два параметра оцениваются по шкале от 1 до 3: 1 — низкий уровень, а 3 — высоки» уровень.

«Влияние» указывает на важность требования. С какими последствиями есть вероятность столкнуться, если это требование не будет правильно реализовано в готовом продукте? Такого рода последствия обозначаются словом «влияние».

Например, если уровень влияния «высокий», то ему можно присвоить значение 3. Если уровень «низкий», то его можно оценить как 1. В случае среднего уровня влияния, значение будет 2. Точно так же оценивается параметр «Вероятность».

«Вероятность» указывает на возможность возникновения сбоев или ошибок на этапе промышленной эксплуатации. Она также оценивается по шкале от 1 до 3.

Теперь на основе оценок, присвоенных параметрам «Влияние» и «Вероятность», для каждого требования рассчитываются уровни риска по следующей простой формуле:

Уровень риска = Влияние * Вероятность

Очевидно, что по этой формуле максимальный уровень риска равен 9 (т.е. Влияние * Вероятность = 3*3 = 9), а минимальный уровень риска равен 1. Таким образом, уровни риска варьируются в пределах от 1 до 9.

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

Модель оценки и категоризации

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

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

Процесс приоритизации на основе оценки рисков

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

Шаг 1. В конце этапа анализа руководитель группы тестирования передает членам команды перечень всех требований. Каждый член команды проверяет требования на предмет ясности. Руководитель группы организует совещание со всеми членами команды, а также с бизнес-аналитиками, заинтересованными лицами и разработчиками.

Шаг 2. На этом совещании каждый высказывается по поводу всех требований и предлагает значения вводных параметров («Влияние» и «Вероятность»).

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

Шаг 3. Руководитель группы консолидирует все мнения и передает результаты приоритизации на основе оценки рисков с указанием уровня риска (высокий, средний и низкий) для каждого требования. Эти результаты могут быть представлены в следующем виде.

Результаты приоритизации

Исходя из этих данных, команды начинают работать над разработкой, тестированием и реализацией.

Преимущества приоритизации на основе оценки рисков

  • Этот процесс позволяет определить тестируемость требований и сделать требования тестируемыми, если они не соответствуют критериям тестируемости.
  • Можно сосредоточиться на задачах тестирования уже на этапе анализа требований.
  • Все заинтересованные лица получают актуальную информацию о требованиях.
  • Можно выявить критические важные требования. После этого можно больше внимания уделить тестированию данных требований.
  • Возможно получить количественную оценку информации о рисках в рамках проекта.
  • Кроме того, можно оптимизировать пользовательское приемочное тестирование, пропустив на этом этапе тесты требований с низким приоритетом. Однако для этого необходимо определить приемлемый уровень для бизнес-подразделений и привлечь их на свою сторону.
  • Это поможет вам оптимизировать процесс тестирования.

Выводы

Приоритизация на основе оценки рисков — это метод, с помощью которого можно проанализировать требования еще на этапе сбора требований. Благодаря применению этого метода вы сможете сосредоточиться на тестировании и минимизировать количество дефектов, которые возникают в системе из-за неточных формулировок требований. При этом вы можете определить приоритеты и категории требований. Это поможет вам оптимизировать пользовательское приемочное тестирование. Приоритизация требований является основой тестирования и повышает эффективность процесса разработки ПО.

Автор статьи
Yogesh Sanjeevan Kshirsagar
Principal Consultant

Немного теории об управлении рисками

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

Определение риска

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

Risks are schedule delays and cost overruns waiting to happen (by Peter Kulik)
Risk is the possibility of suffering loss (SEI, Dorofee 96)

  • риск это некоторое событие, которое может случиться в будущем и может привести к определенным потерям (снижение качества продукта, перерасходование бюджета, задержка сроков либо полной неудачи проекта)
  • проблема же – это событие, которое уже случилось. Риски превращаются в проблемы, если с ними не работать
Некоторые термины и определения
  • Риск – некоторое событие или условие, которое может позитивно либо негативно повлиять на результат проекта (план, качество, стоимость, объем реализованной функциональности)
  • Вероятность риска (Likelihood) – вероятность того, что риск сработает. Является одним из атрибутов риска и может измеряться целыми числами от 1 до 4 (где 1 – очень низкая вероятность, 4 – высокая вероятность)
  • Влияние риска (Impact) – обозначает величину позитивных или негативных последствий для проекта, если риск срабатывает. Является одним из атрибутов риска и может измеряться целыми числами от 1 до 4 (где 1 –малое влияние, 4 – блокирующее влияние). Может также носить название «потери»
  • Величина риска (Risk Exposure) – произведение вероятности на влияние риска (Risk Exposure = Likelihood x Impact)
  • Mitigate (к сожалению, не смог адекватно перевести) – разрабатывать стратегии и план действия для снижения вероятности и/или влияния риска до какого-либо приемлемого уровня (к примеру, можно использовать матрицу величины риска, речь о которой пойдет позже)
  • Mitigation strategy – план действий, направленный на снижение вероятности и/или влияния риска до какого-либо приемлемого уровня (план митигации рисков)
  • Contingency – подход, направленный на минимизацию влияния риска после того, как он сработал
  • Contingency plan – план, направленный на снижения влияния риска (последствий риска) после того, как риск сработал

Для одного и того же риска могут разрабатываться оба плана, но в большинстве случаев – только один (тут уже надо решить что важнее – не допустить срабатывания риска, или же минимизировать потери при его срабатывании). Также при разработке mitigation plan часто руководствуются либо только стратегией снижения влияния или только стратегией снижения вероятности риска (что позволяет экономить – зачем направлять усилия на снижение влияния риска, если одновременно снижается и его вероятность).

Процесс управления рисками
  • идентификация рисков
  • анализ рисков
  • планирование рисков
  • разрешение рисков
  • отслеживание и модификация данных по рискам (параметров и/или планов и стратегий)
С чего начать?

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

Анализ
  • оценка риска – определение значений атрибутов Вероятность риска (Likelihood) и Влияние риска (Impact)
  • классификация риска – группировка рисков, основанная на каких-либо характеристиках (например, по типу рисков их можно разделить на «Quality», «Management», «Hardware», «Software» и тд)
  • приоритизация риска – расставление приоритетов. Практически приоритизация делается на основе матрицы величины риска, о которой я говорил выше

При таком определении величина риска является простейшим способом определить количественную характеристику риска. Практически имеет смысл отслеживать и управлять рисками, которые находятся на главной диагонали данной матрицы или выше ее (то есть со значениями величины риска большими или равными 4 или 6).

После анализа риска мы можем составить топ10 рисков (Top 10 Risk List), выстроив риски по убыванию значения величины риска и выбрав первые десять. Следует помнить, что выбор большего числа рисков может превратить управление рисками в очень тяжелый процесс, который будет слишком дорог и неэффективен.

Планирование
  • исследование риска (research) – проведение дальнейшего исследования риска для его детализации и более аккуратного планирования
  • принятие риска (accept) – мы принимаем риск и готовы жить с его последствиями
  • избежание риска (avoid) – мы предполагаем, что риск никогда не станет реальностью
  • передача риска (transfer) – передача риска и ответственности за него в другую команду, другому менеджеру (возможно и руководству компании), другому лицу
Разрешение рисков

На данном этапе фактически происходит разрешение риска после того, как он сработал. То есть выполняется соотвуетствующий contingency plan. Задача этапа – выполнить его наиболее эффективным образом, а также собрать и проанализировать информацию о данном риске для следующего этапа.

Отслеживание и модификация данных по рискам
  • мониторинг статуса рисков
  • мониторинг статуса mitigation strategy и contingency plan
  • мониторинг проектных метрик, которые связаны с планами действий
  • определять и извещать все заинтересованные стороны о том, что сработал триггер того или иного плана действий
  • идентификация новых рисков, которые не учитывались до этого
  • изменение количественных оценок на риски (возврат к этапу анализа, Top 10 Risk List может значительно измениться)
  • определение, явилось ли изменение количественных оценок (если таковые есть) результатом выполнения тех или иных планов действий (mitigation strategy или contingency plan). Если величина риска снижается, то, скорее всего, mitigation strategy реализуется успешно, однако не стоит сильно обольщаться на этот счет
  • определение методов и способов коррекции планов действий с учетом определенных изменений, переход к планированию
Заключение

Ключевым моментом процесса управления рисками должно быть периодическое повторение данных процессов, желательно согласованное с длительностью циклов разработки и рабочих процессов. Можно порекомендовать проводить оценку рисков один раз в 1-2 недели в зависимости от размера проекта (в некоторых особо крупных проектах периодичность может быть увеличена до месяца, однако больше я бы делать не стал).
Также хочу порекомендовать сохранять историю изменений списка рисков и их параметров (хотя бы Top 10 Risk List) – в будущем это даст нам необходимые статистические данные.

Постскриптум

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *