Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
Интересная тема… а есть толковый книжки, переведенные на русский?
Пример позитивного риска, закончившегося успехом — для сайта электронного магазина было принято решение отказаться от самописного ORM в пользу NHibernate. Понадобилось дополнительно 6 дней, чтобы полностью перевести проект, но потом это сэкономило очень много времени на разработке, когда требования изменились, а один из разработчиков ушел.
я совсем мало понимаю вероятно в риск-менеджменте, но вот поправьте меня если что: позитивные риски — это когда в результате какого-то события будут выгоды, но ели события не произойдёт, то выгоды не будет, также как и потерь? верно? тоесть «риск» как слово, в этом случае применяется условно? И риск-менеджмент в этом случае как бы «перевернут с ног на голову», тоесть Mitigation strategy должна быть направлена на увеличение Likelihood?
Привет!
Я тоже не мегакрут в положительных рисках — так что давай рассуждать.
Если исходить из примеров в статье, то положительный риск — это какие-то действия, которые в случае позитивного исхода принесут выгоду, в случае негативного — убытки. Таким образом, пока риск не сработал — мы получаем выгоду, как только он сработал (к примеру, какие-то проблемы в используемой системе, нехватка знаний и тд) — мы начинаем нести убытки.
Так что все по-прежнему, mitigation может быть направлена на уменьшение likelihood (примером такой стратегии может быть проведение курсов и обучения персонала использованию новой системы или фреймворка, детальное исследование используемой библиотеки, и тд) и перевернутости нет.
Давай попробуем рассмотреть пример 2 из статьи
В данном случае риском у нас является использование методологии разработки, которая может быть недостаточно знакома команде, либо она может не нравиться команде, либо еще что-то…
Если все пройдет гладко, то проект закончится раньше, а риск не сработает. Если же нет (риск сработал) — у нас будут потери в виде затрат времени, больших первоначальной оценки в 6 месяцев.
Таким образом mitigation strategy должна минимизировать вероятность срабатывания риска — можно проводить тренинги с командой на предмет улучшения знаний по принятой методологии, проактивный менеджмент проекта, который будет отслеживать малейшие колебания в команде и тд. Contingency plan в данном случае также не будет отличаться от обычных рисков — то есть будет направлен на уменьшение негативных последствий.
Надеюсь, что не сумбурно изложил… ;)
Я тоже не мегакрут в положительных рисках — так что давай рассуждать.
Если исходить из примеров в статье, то положительный риск — это какие-то действия, которые в случае позитивного исхода принесут выгоду, в случае негативного — убытки. Таким образом, пока риск не сработал — мы получаем выгоду, как только он сработал (к примеру, какие-то проблемы в используемой системе, нехватка знаний и тд) — мы начинаем нести убытки.
Так что все по-прежнему, mitigation может быть направлена на уменьшение likelihood (примером такой стратегии может быть проведение курсов и обучения персонала использованию новой системы или фреймворка, детальное исследование используемой библиотеки, и тд) и перевернутости нет.
Давай попробуем рассмотреть пример 2 из статьи
Была сделана оценка, согласно которой необходимо 6 месяцев, чтобы закончить проект среднего размера. Мы можем закончить проект раньше, если использовать методологию Экстремального программирования. При этом, первый билд будет доставлен заказчику через 3 месяца, остальные — каждый месяц. Однако, при таком подходе существует риск, что данная методология не сработает для этого проекта, либо что проектная команда будет сопротивляться изменениям, что повлечет задержки в проекте.
В данном случае риском у нас является использование методологии разработки, которая может быть недостаточно знакома команде, либо она может не нравиться команде, либо еще что-то…
Если все пройдет гладко, то проект закончится раньше, а риск не сработает. Если же нет (риск сработал) — у нас будут потери в виде затрат времени, больших первоначальной оценки в 6 месяцев.
Таким образом mitigation strategy должна минимизировать вероятность срабатывания риска — можно проводить тренинги с командой на предмет улучшения знаний по принятой методологии, проактивный менеджмент проекта, который будет отслеживать малейшие колебания в команде и тд. Contingency plan в данном случае также не будет отличаться от обычных рисков — то есть будет направлен на уменьшение негативных последствий.
Надеюсь, что не сумбурно изложил… ;)
хм… в таком случае, у «позитивных рисков», по-моему, не хвататет определения «позитивный Impact» т.е. какая выгода будет в случае, если риск не сработает. И «весомость» его должна превосходить «негативный Impact». Лишь в этом случае, мне кажется, риск можно счетать «позитивным».
По-моему, умение «положить на весы» эти два Impact-а и будет отправной точкой в управлении т.н. «позитивными рисками».
из примера 2 статьи очень трудно сказать, позитивный ли это риск, без проработки деталей.
я бы называл «позитивные риски» словом «challenge» — это слово определяет именно то что я хочу сказать.
По-моему, умение «положить на весы» эти два Impact-а и будет отправной точкой в управлении т.н. «позитивными рисками».
из примера 2 статьи очень трудно сказать, позитивный ли это риск, без проработки деталей.
я бы называл «позитивные риски» словом «challenge» — это слово определяет именно то что я хочу сказать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Позитив в управлении рисками ;)