В чем разница между анализом риска и его снижением?

Question

В чем разница между анализом рисков и их уменьшением, а также когда (до кодирования или после кодирования?) И кем (QA / аналитик / разработчик?) Они должны выполняться в жизненном цикле разработки программного обеспечения?

Мнения, ссылки или шаблоны документов будут полезны.

---

EDIT Если я последую за комментарием Мида:

«По словам Тома Демарко - Управление рисками - это управление проектами для взрослых»

означает ли это, что некоторые части традиционного SDLC не должны соблюдаться? Какие части? то есть. какие аспекты типичного SDLC заменяет управление рисками? Вам не нужно столько тренировок MS Project?

Answer 1

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

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

A) Предотвращение риска: минимизируйте вероятность реализации этих рисков (не делая рискованную вещь, то есть, покупая готовый компонент или пакет программного обеспечения);

B) Смягчение последствий: минимизировать серьезность рисков, если они имеют место (иметь план действий в чрезвычайных ситуациях, добавить дополнительное время и / или бюджет, сделать полное резервное копирование и т. Д.); и / или

C) Принятие риска: будьте готовы иметь дело с рисками, когда они возникают (низкая вероятность или низкое влияние риска по сравнению со стоимостью управления может не стоить ничего с ними делать, если вы единственный разработчик и есть вероятность быть пораженным астероидом, это просто может стоить просто принять риск).

D) Передача риска: пусть кто-то другой будет нести за вас риск, кто-то, кто может справиться с ним лучше, например, страховая компания или сторонний поставщик.

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

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

Answer 2

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

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

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

1) Сначала вы идентифицируете каждый риск в реестре рисков, который является просто списком в Excel.

2) Далее вы оцениваете каждый риск: воздействие и вероятность .

3) Сочетание воздействия и вероятности затем описывает уровень риска (см. Первую матричную таблицу)

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

5) Исходя из этого, вы или кто-то другой решите, какой ответ предпринять для каждого риска в вашем реестре согласно ответу @JohnFx. Если вы являетесь премьер-министром, и у вас низкий риск, тогда «принятие» может быть правильным подходом. Концепция управления рисками и управления заключается в том, что вы записываете это и четко сообщаете об этом заинтересованным сторонам. Тогда вы все знаете, почему и что вы делаете.

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

И то, и другое должно быть сделано в начале. Как правило, они сделаны, чтобы увидеть, если завершение проекта выгодно для бизнеса. (риск против вознаграждения)