Управление рисками в разработке ПО

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

Такие методологии как например RUP и XP, четко описывают процесс управления рисками.

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

Основная цель процесса управления рисками — это изменить модель поведения. Вместо реагирования на уже наступившие риски («аврал, аврал!») мы проводим предупреждение рисков и прорабатываем сценария действия в случае наступления рискового события. Это то, что называется «be proactive».

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

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

Эти меры, в свою очередь, эффективно снижают некоторые из рисков и, соответственно, повышают шансы на успех проекта.

Пример. Менеджер проекта получает информацию, что разработчики проекта получают зарплату меньше среднерыночной. Это повышает риск ухода части разработчиков до окончания работ по проекту и, соответственно, повышает риск переноса срока сдачи проекта и риск провала проекта. Менеджер может решить добиться для разработчиков 20% повышения зарплаты если посчитает, что риск превышения бюджета проекта менее опасен нежели провала или задержка проекта.

Еще пример. Разработчики решают использовать в проекте bug-tracking system так как, по их расчету, риск «потерять» важные проблемы и отсутствие внятного состояния хода проекта превышает риски задержки проекта в связи с необходимостью поддержки базы инцидентов.

Никакой, даже самый совершенный процесс управления рисками, не в состоянии контролировать (в смысле влиять на) риски. Зато он может снижать вероятность их наступления и контролировать последствия, что уже очень не мало.

Далі буде: программирование как управление рисками.

Литература:

1. Know Your Enemy: Software Risk Management (Karl E. Wiegers, 1998)
2. Amazon.com: Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))
3. Amazon.com: Proactive Risk Management : Controlling Uncertainty in Product Development

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Теми: методології розробки

Artur Rakytskyi Seasoned IT Manager in MilTech / AdTech / other areas 20.09.2010 19:27

2 erka: Бюджет проекта декларируется довольно большим, а реально на разработку и внедрение уходит значительно меньше. Разница возвращается в карман представителю заказчика. Иногда заранее известно, что успех проекта не нужен. Хорошо, если об этом известно хотя бы менеджеру проекта:) Но иногда это не так. Выводы можете спрогнозировать сами:)

Відповісти

Підтримати

Мдя... с форматированием сообщений здесь туговато: (

anonymous 20.09.2010 19:27

Я понимаю, что теория и практика — это два айсберга и риски не проблемы девелоперов, а проблема заказчика и менеджера. Девелопер может только рассказать о возможности какой-то угрозы превратиться в риск.Еще один вопрос. Что такое откатные проекты?:)

Ну и добавлю немного о моем методе. Он довольно прост:) Если проект «time-critical», угрозу оцениваем временем, на который сдвинется проект при реализации риска. Если риск создает неприемлемые крайние сроки, он может служить причиной отказа от такого проекта.Если проект «cost-critical», угрозу оцениваем в деньгах. Обычно, как часть резервного фонда (бонусного фонда). Если риск очень «дорогой», он может служить причиной отказа от такого проекта.Если проект «mission-critical», угрозу оцениваем в наборе функций, от которых прийдется отказаться. Если риск затрагивает важные функции, он может служить причиной отказа от такого проекта. Это довольно редкий случай, и обычно это исследовательские проекты, успех/неуспех которых не сильно влияет на участников. Я лично с такими еще не сталкивался на практике:) Вот реальный пример шкалы оценки угрозы:

Оценка угрозы  ВлияниеГрафик1 крайне слабоесдвиг на 1 день2 слабоесдвиг на 3 дня3 среднеесдвиг на 1 неделю4 сильноесдвиг на 2 недели5 крайне сильноесдвиг на 1 месяц

Длительность проекта 3 месяца. Проект «time-critical», одна итерация разработки. Внедрение будет в рамках отдельного проекта.Пример самого «страшного» риска.

№:11Источник:2.5 ТребованияУсловие:Требования в проекте ведутся некачественно - некоторые требования вообще не определены, некоторые требования определены только частично, не существует инструмента управления требованиями. На выявление и определение требований не выделено время в проекте.Последствия:Некачественное решение. Частые изменения требований. Ситуация может привести к огромному количеству ошибок и замечаний к решению как на фазе стабилизации, так и в следующих проектах внедрения.Вероятность:50%Угроза:5Ущерб:250Предотвращение:Не применимо.Ликвидация результатов:Потребуется увеличить сроки и бюджет проекта.Событие:Создано большое количество замечаний и найдено большое количество ошибок во время фазы стабилизации. Общее время исправления этих замечаний и ошибок больше, чем фаза разработки.Ответственный:Управление продуктом

Думаю, объяснять подробно не нужно:)

2 erka, Скакунов Александр: Статистику вести пока не на чем:) Не так много проектов я завершил:) В основном были достаточно длительные проекты (от 4 месяцев). Поэтому сравнивать результаты крайне сложно. Есть конечно общие риски, например, тот же уход тим-лида. Но в каждом конкретном случае он означал разное. Например, в одном проекте тим-лид таки ушел (после успешной сдачи первой версии, а планировалось еще 2 внедрения), но его смог заменить опытный девелопер, который стал хорошим тим-лидом, а сегодня он уже руководитель проекта:) Если бы я занимался веб-проектами (дизайн + стандартные сервисы), я бы мог вести статистику. Но в таких проектах управление рисками может быть неоправданно дорогим занятием;) Самое полезное в управлении рисками — это (IMHO): 1. превентивные меры; 2. оценка крайних сроков (с учетом рисков, пессимистический прогноз); 3. перенос рисков на следующую итерацию (своего рода гарантия не увеличения вероятности для некоторых рисков); 4. железобетонная аргументация в “разборе полетов” с заказчиком. К слову, риски БЕСПОЛЕЗНЫ, если заказчик не знает о них, или не понимает их, или не принимает их после каждого пересмотра. Не говоря уже о рисках, связанных с бизнесом заказчика (изменение законодательной базы, появление конкурентов, появление намного более привлекательного аналога для товаров/услуг). Эти риски ОБЯЗАН определять сам заказчик, или хотя бы подробно объяснять ситуацию по каждому из них. Особенно в длительных (от 6 месяцев) проектах.Это все я не из книг здесь излагаю (хотя, конечно, книги дали хороший старт). Это практика, и вполне успешная. Но предупрежу сразу: начать выгодно использовать управление рисками — это довольно сложная и комплексная задача. Нужно не только понять теорию, но и на практике “чувствовать” правильность того, что ты делаешь. Как только появляется чувство “непонятности, неопределенности” в этой области, нужно или сразу отказываться от “теоретизирования”, или тратить больше времени на анализ ситуации, на обсуждения и исследования. Иначе можно сильно навредить проекту. Например, можно записать довольно стандартній риск “форс-мажор”, и прикрывать им все просчеты в анализе предметной области. Если анализом занимается представитель заказчика, он может так поступать. Это очень плохая практика — подстановка понятий. Я обычно избегаю таких определений рисков. Если говорят, что из-за форс-мажора проект может быть отменен, я это даже не фиксирую. Если и будет отменен, то из-за какой-то вполне конкретной ситуации. И про эту ситуацию заказчик или руководство знало ранее, но считало правильным ее скрыть от меня (откатные проекты — хороший пример). А раз так, то и ответственность лежит на них, а не на проектной группе.

Andrey Podgurskiy 20.09.2010 19:27

Вальсирую с медведями — очень хорошая книга на эту тему. Читается легко. Написано толково.По ней структура менеджмента рисков состоит из следующих шагов: 1 оцениваем прошлые проекты, смотрим какие риски возникли2 мозговой штурм — какие есть риски для этого проекта3 добавляем «базовые риски» — в книге их выюоано 5- каждый риск — это график вероятности к затратам.риски складываем — получаем сумму рисков (график).Если соотносить с вероятностною прибылью — получим прибыльность проекта (тоже график) Риск предупредили — поправили графики. Риск не сработал — поправили графики.Смысл что в эстимейтах звучит не «6 недель», а «с вероятностью 50% — это до 6 недель, с вероятностью 75% — это до 8 недель». «тул» для складывания рисков где есть «базовые» 5 рисков — http://www.systemsguild.com/ri.../

Alexander Skakunov Founder в Місія на Марс 20.09.2010 19:27

Да, побольше примеров, тема интересная.

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

Это повышает риск ухода части разработчиков до окончания работ по проекту и, соответственно, повышает риск переноса срока сдачи проекта и риск провала проекта.

Создавать «риски после рисков» == тратить время зря:) Само собой, что мы должны добиваться выполнения проекта вовремя, в рамках бюджета и с приемлемым качеством. Это даже не обсуждается:) Поэтому создавать риск «мы не успеем» — это сродни суеверию:) Конечно мы можем не успеть, но ПОЧЕМУ? Вот на этот вопрос и отвечают КОНКРЕТНЫЕ риски. И не просто уход ведущего разработчика, а конкретно «уход Иванова И.И. на второй итерации проекта на фазе разработки» (если проект длительный). Нужно этот риск оценить как «время, на которое придется сместить конец итерации», «деньги, которые придется потратить на замещение позиции». Это КОНКРЕТНЫЕ цифры, и нужно оперировать именно ими, а не «рискуем завалить сроки проекта»...

Никакой, даже самый совершенный процесс управления рисками, не в состоянии контролировать (в смысле влиять на) риски.

Я бы сформулировал «не в состоянии влиять на угрозы». Риски — это вероятностная оценка. Влиять мы на нее можем, что и говорит следующая фраза:

Зато он может снижать вероятность их наступления...

.Лично я придерживаюсь простого правила. Если я могу ИДЕНТИФИЦИРОВАТЬ риск, указав конкретные цифры влияния события на проект — я его фиксирую и отслеживаю. Если риск из серии «а черт его знает, что там будет в результате», я его откладываю, и иногда даже не записываю (если не вижу способа уточнить прогноз).

Еще одна книжка на эту тему.

Управление рисками в разработке ПО

10 коментарів

Підписатись на коментарі