CC BY
127
Абрамов В.Г., Шалаев А.Ю.* ОСОБЕННОСТИ УПРАВЛЕНИЯ РИСКАМИ В ПРОГРАММНЫХ ПРОЕКТАХ
Введение
Процессы проектирования и разработки программного обеспечения всегда сопряжены с факторами неопределенности внутренней и внешней среды, которые могут привести к ухудшению качественных показателей конечного продукта, к увеличению затрат, смещению сроков или даже к закрытию проекта, без достижения поставленных целей. Одним из методов уменьшения влияния факторов, приводящих к негативным вариациям, является систематическое управление рисками на протяжении всего жизненного цикла программного проекта.
Под риском будем понимать неопределенное событие или условие, наступление которого отрицательно или положительно сказывается на целях проекта1.
В количественном отношении неопределенность подразумевает возможность отклонения результата от ожидаемого значения, как в меньшую, так и в большую сторону. Такая неопределенность носит название «спекулятивной», в отличие от «чистой» неопределенности, предполагающей возможность только негативных отклонений конечного результата деятельности. В области управления проектами под риском преимущественно понимается возможность потери части ресурсов, недополучение доходов или появление дополнительных расходов в результате осуществления проекта. Риски отражают неопределенность или же недостаточный объем знаний, касающийся спектра возможных событий.
Риск может быть вызван одной или несколькими причинами и, в случае возникновения, может оказывать влияние на один или несколько параметров проекта. Например, причиной риска может быть недостаточное количество персонала, привлеченного для проекта разработки программного обеспечения. Наступлением риска в этом случае будет нехватка персонала в ходе реализации проекта. Возникновение этого неизвестного заранее события может повлиять на стоимость проекта, сроки его выполнения и качество создаваемого программного продукта. К условиям возникновения риска могут также относиться аспекты внешней среды проекта, способствующие увеличению риска. Например, к таким условиям можно отнести неудачный выбор методов при управлении проектом, отсутствие общих систем управления, одновременное выполнение нескольких проектов или зависимость от внешних участников проекта, которых невозможно контролировать.
Отношение к риску со стороны отдельных людей и организаций обусловлено их пониманием риска и ответной реакцией на его возникновение. Там, где это возможно, отношение к риску должно быть выражено в формализованной форме. Для каждого программного проекта должен быть разработан последовательный подход к риску, удовлетворяющий требованиям организации, а информация о риске и управлении им должна
* Абрамов Владимир Геннадьевич - кандидат физико-математических наук, доцент кафедры АЯ факультета ВМиК МГУ им. М.В. Ломоносова.
Шалаев А.Ю. - аспирант кафедры АЯ факультета ВМиК МГУ им. М.В. Ломоносова.
1 Руководство к Своду знаний по управлению проектами (Project Management Body of Knowledge), третье издание, Project Management Institute, Inc., Four Campus Boulevard, 1-930669-77-8, стр. 238.
быть открытой и достоверной. Для достижения успеха на протяжении всего проекта организация должна предпринимать предупредительные меры по управлению рисками.
Управление рисками - это процессы, связанные с идентификацией, анализом рисков и принятием решений, которые включают максимизацию положительных и минимизацию отрицательных последствий наступления рисковых событий2.
Цель управления рисками - увеличение вероятности успешной реализации программного проекта, посредством снижения степени воздействия рисков. Под процессом управления рисками в программных проектах будем понимать совокупность последовательных действий, направленных на регулирование вероятности успешной реализации проекта, то есть его завершение в рамках бюджета, запланированных сроков и надлежащего качества.
Подходы к организации управления рисками в различных предметных областях определяются в стандарте PMBOK (Project Management Body of Knowledge) и являются общими для всех областей приложения знаний; в зависимости от предметной области различаются конкретные методы и инструменты управления рисками.
Превентивное управление рисками
Согласно статистике, приводимой The Standish Group в отчете «2004 THIRD QUARTER RESEARCH REPORT»3, лишь 29% проектов по разработке программного обеспечения завершаются в рамках первоначально установленных сроков, бюджета и функциональности. Для 53% проектов по одному или нескольким параметрам фиксируется превышение запланированных показателей; наконец, 18% проектов заканчиваются неудачно.
Во многом приведенные результаты связаны с тем, что процесс управления проектами происходит в условиях постоянно присутствующей неопределенности состояния внешней и внутренней среды, которая обуславливает частичную или полную неопределенность конечных результатов деятельности.
Значительное влияние на процесс управления проектными рисками оказал пересмотр господствовавшего долгое время представления о том, что целью управления рисками является избежание или минимизация принимаемого риска4. Если последовательно логично развивать данную точку зрения, то можно прийти к «порочному кругу». Например, при продвижении на рынке нового программного продукта возможна следующая ситуация: «попытка снижения рисков ведет к потере доли рынка, что, в свою очередь, заставляет проводить агрессивную маркетинговую политику. Это приводит к неизбежному возникновению новых рисков, что вызывает появление значительных убытков, а это заставляет сокращать объемы ресурсов (финансовых, человеческих, временных). И, наконец, эта цепочка замыкается ситуацией, требующей уменьшения рисков». Этот круг можно разорвать, если отказаться от исходной посылки о защитной, «ответной» минимизации принятого риска в пользу активного, «упреждающего» управления им с целью снижения негативного влияния, которое специфические факторы оказывают на всех участников проекта.
2 Руководство к Своду знаний по управлению проектами (Project Management Body of Knowledge), третье издание, Project Management Institute, Inc., Four Campus Boulevard, 1-930669-77-8, стр. 237.
3 http://www.standishgroup.com/quarterly_reports/index.php
4 П.Л.Бернстайн. «Против богов. Укрощение риска», Изд-во Олимп-Бизнес, 2006 г., 400 стр.
Влияние риска на фазы программного проекта
На протяжении жизненного цикла программного проекта может происходить большое число событий, идентификация и анализ которых невозможны на начальных стадиях проекта. Например, при отсутствии у команды программистов достаточного опыта в конкретной предметной области, руководитель проекта не имеет возможности определить все потенциальные риски, связанные с разработкой программного обеспечения в этой предметной области.
Возможность события, связанного с риском, наиболее велика на стадиях выработки концепции, планирования и начала работ над программным проектом. Влияние последствий рискового события на затраты будет тем меньше, чем раньше такое событие произойдет. Именно на ранних стадиях выполнения проекта имеется возможность минимизировать влияние риска или вообще обойти его. Соответственно, когда работа над проектом выполнена наполовину, цена риска начинает быстро возрастать, достигая максимальных значений на завершающих стадиях жизненного цикла проекта.
Можно выделить область наибольшего влияния на смягчение риска, которая касается этапа формализации требований к программному продукту, его разработке, и частично процессу внедрения. Именно на этих этапах руководитель проекта может оказать наибольшее влияние на процесс уменьшения рисков.
Специфика рисков в программных проектах
Процесс разработки больших программных систем чрезвычайно сложен и непредсказуем. Программные проекты часто прерываются, выходят за рамки сроков и бюджета или приводят к некачественным результатам.
Специфика разработки программного обеспечения определяется сочетанием следующих факторов:
1.Отсутствие универсальной методологии разработки программного обеспечения. Каждый программный продукт уникален по своей природе; его создание характеризуется неповторимыми факторами внешней среды, требованиями заказчика, инструментальными средствами разработки, спецификой проектной команды. В результате не удается создать единую методику разработки программных продуктов. Такие авторитеты в области методологии программирования, как, например, Грэйди Буч (Grady Booch), Джим Рамбау (Jim Rumbaugh) и Уокер Ройс (Walker Royce), попытались сформулировать набор правил, которыми нужно руководствоваться при разработке программных продуктов. Эти правила повышают эффективность разработки, но не гарантируют ее успешности. Современным программистам не хватает этого набора универсальных принципов, отвечающим специфике конкретной разработки.
2. Уникальность создаваемых интеллектуальных решений. «В 9 случаях из 10 специалисты в области информационных систем работают над задачами, которые до этого ни они сами, ни кто-либо другой не выполняли. В отличие от каменщиков, десятилетиями кладущих одни и те же кирпичи одним и тем же способом, программисты не пишут одинакового кода»5.
5 Lois Zells, ISSIG Project Management Institute (http://www.pmi-issig.org/) © фгу 2005
3.Высокая гибкость процесса разработки программного обеспечения (ПО). При выполнении проекта разработчик ПО не обладает системой универсальных принципов, позволяющих оценить качество принятого архитектурного решения создаваемой системы. Единственный инструмент в его руках - это тестирование отдельных компонент и всей системы в целом. Это означает, что даже неудачная архитектура, спланированная на ранних этапах проекта, может быть реализована, а полученная реализация системы будет работоспособна. Исправление дефектов архитектуры, обнаруженных на поздних стадиях разработки проекта, очень дорого и, порой, приводит к негативному завершению проекта.
4.Минимальные затраты на исправление неправильно принятых решений при проектировании программного обеспечения, по сравнению с проектами в других предметных областях. К примеру, в большинстве случаев стоимость внесения изменений в конструкцию фундамента дома, после того, как возведено здание, не сравнимо со стоимостью исправления кода программного модуля. «В мире, где строительство и разрушение бесплатны, выбирается метод проб и ошибок, а фундаментальные исследования остаются для простаков. Программное обеспечение разрабатывается именно в таком мире. Программист создает чертеж в виде программы на языке высокого уровня. Затем он позволяет компилятору и компоновщику в мгновение ока и почти без затрат построить программный продукт. Создание чертежа требует значительных усилий, но строительство с помощью компилятора и компоновщика практически бесплатно. Программисту вообще не надо беспокоиться о сносе и уборке обломков - по крайней мере, до тех пор, пока ему достаточно дискового пространства. Неудивительно, что идеология проб и ошибок так глубоко укоренилась в процессе разработки программного обеспечения, а сообщество программистов не удосужилось исследовать основные принципы разработки программного обеспечения. Метод проб и ошибок завел нас достаточно далеко. Но рост сложности современных программных систем подводит нас к жесткому пределу. За пределами определенного уровня сложности создание качественных архитектур методом проб и ошибок становится невозможным»6.
5..Нелинейная зависимость экономической эффективности от масштабирования разработки ПО. Масштабирование разработки программного обеспечения не влечет за собой соответствующего роста экономической эффективности проекта. Это является следствием проектной природы самой разработки. Известно, что в других отраслях рост экономической эффективности относится только к производственным процессам, но не к задачам проектирования. Причина проста - при проектировании приходится иметь дело не только с каждым из элементов проекта, но также и со всеми взаимосвязями между ними. При росте числа элементов проекта число взаимосвязей между ними нелинейно возрастает.
б.Сложность расчета стоимости, длительности и качества программных проектов. Для разработки программного обеспечения нормативы длительности, трудоемкости и качества определяются с меньшей точностью, а стоимость информационных систем сопоставима со стоимостью труда разработчиков.
Учет специфики разработки программного обеспечения позволяет более эффективно управлять рисками для повышения вероятности успешного завершения проекта в целом. Можно выделить следующие категории рисков, существенным образом влияющие на ход выполнения программного проекта:
¡.Задачи и цели
Проект должен соответствовать стратегическим целям компании. К примеру, для организации, миссия которой состоит в создании наиболее эффективного программного обеспечения для предприятий нефтегазовой промышленности, принятие заказа на разработку ПО для работы с векторной графикой является рискованным мероприятием, противоречащим текущим целям и задачам организации.
2. Организационный менеджмент
Проект должен вписываться в текущую или планируемую организационную структуру компании. Если организация не обладает подобной структурой или она еще не создана, трудно рассчитывать на успешную реализацию программного проекта. Например, создание специальной проектной команды для управления критически важным программным проектом на базе организации функционального типа, без соответствующих организационных решений со стороны руководства компании, влечет за собой риск, связанный с невозможностью привлечения персонала для реализации проекта в режиме полной занятости из различных функциональных подразделений.
Наиболее эффективная реализация программных проектов возможна в организациях
7
проектного типа .
3. Управление проектом
Эта категория риска относится как к процессам управления проектом, так и к компетенции руководителя проекта. Риск существует не только из-за недостатков и неадекватной трактовки процессов менеджмента, но может быть также следствием предыдущего опыта работы менеджера проекта.
4.Заказчики и пользователи
Проект должен иметь постоянную «обратную связь» с заказчиком. Разработка программного продукта требует обширных вводных данных, которые могут предоставить заказчики и конечные пользователи; данные определяются на начальной фазе проекта, и практически всегда уточняются и дополняются во время выполнения проекта. Модель жизненного цикла разработки программного обеспечения должна выбираться с учетом динамики изменений требований к конечному программному продукту; при высокой динамике рекомендуется использование эволюционной модели быстрого прототипирования, модели быстрой разработки приложений (RAD), инкрементной модели, а также адаптированных моделей жизненного цикла разработки ПО, при низкой - каскадной и V-образной моделей8.
5.Бюджет и расходы
Бюджет программного проекта и объемы затрат позволяют задействовать широкий спектр возможностей, приводящих проект к успешному завершению. Для уменьшения риска, относящегося к этой категории, следует четко представлять размеры проекта, располагать достоверной предысторией о работе над подобными проектами, а также иметь достаточно полное представление о внешних факторах, влияющих на выполнение проекта. Для оценки длительности и стоимости разработки ПО можно использовать такие специфические для
7 Руководство к Своду знаний по управлению проектами (Project Management Body of Knowledge), третье издание, Project Management Institute, Inc., Four Campus Boulevard, 1-930669-77-8, стр. 29.
8 Р.Т.Фатрелл, Д.Ф.Шафер, Л.И.Шафер «Управление программными проектами. Достижение оптимального качества при минимуме затрат», Изд-во «Вильямс», 2003г., стр. 121.
области разработки ПО модели/методы, как метод Delphi, регрессионная модель COCOMO, математическая модель (SLIM), а также эмпирические модели9.
6. График
Самый большой риск состоит в том, что команде разработчиков программного обеспечения навязываются слишком тесные временные рамки графика. В связи с этим руководитель проекта должен применять максимально точные методы оценки длительности проекта - например, параметрическую оценку, оценку по аналогам, или оценку методом «снизу вверх»10.
Для точной оценки трудоемкости и длительности выполнения проекта необходимо разбиение его этапов на мелкие компоненты. Степень детализации должна зависеть от проекта и его сложности. Важно, чтобы разработке компонентов предшествовал этап проектирования, в процессе которого создается проектный документ с последующим его обсуждением и принятием командой проекта. Этот процесс способствует однозначному распределению ответственности за реализацию компонентов программного продукта между членами проектной команды. Оценку времени и стоимости исполнения каждого этапа работ должен давать сотрудник, который выполняет данный этап; в случае, если сотрудник ошибается, будут нарушены сроки выполнения всего проекта, так как все последующие решения будут приниматься руководителем проекта исходя из неверных оценок.
Если разработчики не могут оказывать влияния на формирование графика и даты ключевых этапов проекта, велика вероятность того, что график выполняться не будет. Команда разработчиков ПО должна принимать участие в создании проектных графиков и иметь возможность вносить туда изменения. В то же время, утвержденные графики выполнения проекта не должны существенно влиять на качество и функциональность конечного программного продукта.
7.Изменения проекта
Проекты редко выполняются строго в соответствии с планом управления проектом; на различных фазах выполнения появляется информация, существенным образом изменяющая описание содержания проекта и функциональность конечного продукта. Например, потеря документации, содержащей уточненные требования заказчика к результатам этапов проектирования, ведет к созданию программной системы, не отвечающей ожидаемым запросам пользователей.
Управление изменениями должно проводиться от начала проекта вплоть до его завершения. Каждое запрошенное изменение плана управления проектом или его содержания должно быть задокументировано, принято или отклонено лицом с соответствующими полномочиями из команды управления проектом или из сторонней организации, представляющей инициатора или заказчика проекта. В команде управления проектом должен функционировать механизм последовательного информирования участников проекта обо всех изменениях.
8. Управление качеством программного обеспечения
Попытка уменьшения бюджета проекта путем делегирования функций отдела качества программного обеспечения заказчику, ведет к существенному увеличению финансовых и технологических рисков проекта.
9 Р.Т.Фатрелл, Д.Ф.Шафер, Л.И.Шафер «Управление программными проектами. Достижение оптимального качества при минимуме затрат», Изд-во «Вильямс», 2003г., стр. 364.
10 Руководство к Своду знаний по управлению проектами (Project Management Body of Knowledge), третье издание, Изд-во «Вильямс», 2003г., стр. 157.
Отдел качества должен быть в каждой компании; требование его независимости от отдела разработки является обязательным. Существует естественная тенденция, когда отдел разработки хочет поскорее сдать проект и приступить к новому, и процесс достижения требуемого качества является необходимой, но самой нелюбимой всеми разработчиками процедурой. Соответственно, очень важно, чтобы руководитель проекта не имел никакого воздействия на отдел качества.
С целью обеспечения требуемого качества программного обеспечения может применяться метод ежедневного построения рабочей версии программного продукта и пакета сопроводительной документации, с последующим тестированием и созданием сопроводительных отчетов со стороны отдела качества11.
9. Среда разработки
Данная категория существенно зависит от программно-аппаратных платформ и инструментов по разработке программного обеспечения. Если команда не подобрана специально для решения конкретной задачи, отсутствует адекватное пространство для выработки соглашений и поддержки взаимодействия с заказчиком. В результате риск существенно возрастает.
¡0. Персонал
Профессионально подобранная команда проекта является важным фактором достижения планируемого результата. Штат включает программистов-разработчиков, программистов-аналитиков, инженеров, которые ответственны за процесс тестирования программного обеспечения, системных аналитиков, аналитиков приложений, системных программистов, специалистов по аппаратному обеспечению во главе с руководителями и менеджерами проектов, а также некоторых специалистов смежных профессий, которые непосредственно не работают в области информационных систем, но тоже вовлечены в эти проекты.
Умение членов команды проекта интегрировать знания из различных предметных областей, формулировать требования, ставить и решать задачи, является критическим для успешного выполнения проекта.
¡¡. Поддержка
Хотя программные проекты формально завершаются, процесс дальнейшей технической и консультативной поддержки существенен для жизненного цикла программного продукта. Заказчик не считает проект удачно завершенным, если такая возможность не предоставляется. Команда разработчиков несет ответственность за поддержку и исправление ошибок в программном обеспечении в течение определенного периода после поставки продукта.
Цель управления рисками проекта - повышение вероятности возникновения и воздействия благоприятных событий и снижение вероятности возникновения и воздействия неблагоприятных для проекта событий. Рассмотрим основные процессы управления рисками в программных проектах.
Процессы управления рисками проекта
В ходе выполнения программного проекта происходит выявление, анализ и оценка потенциальных и возникших рисков, определяется их влияние на функциональность программного продукта, стоимость и длительность проекта, принимаются решения о реакции
на негативные события, создаются резервы и планируются расходы на случай чрезвычайных обстоятельств. Процессы управления рисками проекта включают в себя12:
1.Планирование управления рисками - выбор подхода, планирование и выполнение операций по управлению рисками проекта;
2.Идентификация рисков - определение того, какие риски могут повлиять на проект, и документальное оформление их характеристик;
3.Качественная оценка рисков - расположение рисков по степени их приоритета для дальнейшего анализа или обработки путем оценки и суммирования вероятности их возникновения и воздействия на проект;
4.Количественная оценка - количественный анализ потенциального влияния идентифицированных рисков на общие цели проекта;
5.Планирование реагирования на риски - разработка действий с целью повышения благоприятных и снижения неблагоприятных последствий при возникновении рисков;
бМониторинг и контроль рисков - отслеживание идентифицированных рисков, мониторинг остаточных рисков, идентификация новых рисков, исполнение планов реагирования на риски и оценка их эффективности на протяжении жизненного цикла проекта.
Эти процессы взаимодействуют друг с другом, а также с другими процессами управления проектом. В зависимости от потребностей проекта в каждом процессе могут принимать участие один или несколько человек или групп. Каждый процесс имеет место по крайней мере один раз в ходе каждого проекта, а если проект разделен на фазы - то в одной или нескольких фазах проекта. Несмотря на то, что процессы, представленные выше, рассматриваются как дискретные элементы с четко определенными характеристиками, на практике они могут частично совпадать и взаимодействовать.
Планирование управления рисками
Тщательное и подробное планирование управления рисками повышает вероятность успешного достижения целей программного проекта. Планирование управления рисками -это процесс определения подходов и планирования операций по управлению рисками проекта. Планирование процессов управления рисками позволяет обеспечить их соразмерность как самому риску, так и проекту в целом, а также выделить достаточное количество времени и ресурсов для выполнения операций по управлению рисками и определить общее основание для оценки рисков.
Процесс планирования управления рисками должен быть завершен на ранней стадии планирования проекта, поскольку он крайне важен для успешного выполнения и оценки других процессов. Для разработки плана управления рисками команда проекта проводит совещания, на которых рассматриваются факторы внешней среды предприятия, активы организационного процесса (включающие заранее разработанные подходы к управлению рисками, общие определения понятий и терминов, стандартные шаблоны и др.), план и содержание проекта. В совещаниях могут принимать участие руководитель проекта, отдельные члены команды и участники проекта, представители организации, отвечающие за операции по планированию рисков и реагированию на них, и, при необходимости, другие лица.
Результатом процесса планирования является план управления рисками, включающий в себя методологию управления рисками в проекте, иерархическую структуру рисков (с перечислением категорий и подкатегорий риска, которые могут появиться в конкретном проекте), оценку стоимости мероприятий, необходимых для управления рисками, а также распределение ролей и ответственности сотрудников и партнеров организации в плане по управлению рисками.
Идентификация рисков
Идентификация рисков предусматривает определение рисков, способных повлиять на проект, и документальное оформление их характеристик. Идентификация рисков должна привлекать как можно больше участников: руководителя проекта, членов команды проекта, команду управления рисками, экспертов в предметных областях, заказчиков, конечных пользователей и независимых специалистов.
Идентификация рисков - это итеративный процесс, поскольку по мере развития проекта в рамках его жизненного цикла могут обнаруживаться новые риски. Частота итераций и состав участников выполнения определенного цикла в каждом случае могут быть разными. Например, аналитики и разработчики требований принимают участие в процессах идентификации рисков на ранних стадиях жизненного цикла проекта. А на стадиях завершения проекта к этим процессам подключаются специалисты отдела технической поддержки, а также пользователи, эксплуатирующие созданную программную систему. В процессе идентификации рисков должны принимать участие члены команды проекта с тем, чтобы у них вырабатывалось чувство "собственности" и ответственности за риски, а также за действия по реагированию на них.
Выявление риска начинается с составления списка всех факторов, которые могут затормозить работу над проектом или вовсе помешать его реализации, а также результатов их воздействия (см. категории рисков и специфику рисков в программных проектах). При идентификации рисков учитываются факторы внешней среды предприятия, активы организационного процесса, план управления проектом, включающий в себя планы по управлению расписанием, стоимостью и качеством, а также основной результат планирования управления рисками - план управления рисками. Ключевую информацию для процесса идентификации рисков из плана управления рисками составляют категории рисков, схема распределения ролей и ответственности, резерв на операции по управлению рисками в бюджете и расписании.
Для идентификации рисков могут использоваться следующие методы сбора информации: «мозговой штурм», метод Delphi (метод достижения консенсуса между экспертами), анализ сильных и слабых сторон (SWOT-анализ), опросы среди опытных сотрудников, принимающих участие в проекте и экспертов в предметных областях.13 Среди дополнительных инструментов и методов выделяется анализ контрольных списков, составленных на основе исторической информации и знаний, накопленных в ходе исполнения прежних аналогичных проектов; а также анализ допущений, сделанных в ходе разработки проекта.
Результатом процесса идентификации рисков является реестр рисков, который становится элементом плана управления проектом. Реестр рисков содержит список
идентифицированных рисков, список потенциальных действия по реагированию на риски, основные причины возникновения риска, а также уточненный список категорий рисков.
Качественный анализ рисков
Качественный анализ рисков включает в себя расстановку приоритетов для идентифицированных рисков, результаты которой используются впоследствии в ходе количественного анализа рисков и планирования реагирования на них. При качественном анализе рисков определяются приоритеты идентифицированных рисков на основании вероятности их возникновения и влияния на достижение целей проекта. Качественный анализ рисков подлежит уточнению на протяжении всего жизненного цикла проекта и должен отражать все изменения, относящиеся к рискам проекта.
В процессах качественного анализа рисков используется информация об активах организационного процесса, описание содержания проекта, план управления рисками, а также реестр рисков, в котором ключевым элементом для проведения качественного анализа рисков является список идентифицированных рисков.
Инструментами и методами качественного анализа рисков являются определение вероятности и воздействия рисков, разработка матрицы вероятности возникновения и последствий риска, оценка качества данных и срочности риска.
Определение вероятности возникновения риска предполагает проведение исследований на предмет возникновения того или иного специфического риска в процессе выполнения проекта. Вероятность и воздействие оцениваются для каждого идентифицированного риска. При оценке воздействия риска определяется потенциальный эффект, который он может оказать на цель проекта.
Назначение приоритетов рискам для последующего количественного анализа и реагирования осуществляется на основании рейтинга рисков. Присвоение риску определенного места происходит на основе оценки вероятности его возникновения и возможных последствий. Оценка важности рисков и приоритетности для их обработки осуществляется при помощи таблицы соответствия или матрицы вероятности и последствий. Такая матрица содержит комбинации вероятности и воздействия, при помощи которых рискам присваивается определенный ранг: низкий («зеленая зона»), средний («желтая зона») или высший приоритет («красная зона»). В черно-белой матрице эти условия могут обозначаться различными оттенками серого цвета. Например, в матрице, изображенной на
рис. 114:
• область темно-серого цвета (наивысшие цифровые значения) обозначает высокий уровень риска;
• область светло-серого цвета (средние по значению цифровые обозначения) обозначает средний уровень риска;
• область среднего по интенсивности серого цвета (наименьшие цифровые значения) обозначает низкий уровень риска.
Вероятность угрозы Благоприятны* ейзмсиносгн
0.50 о.сь ojos 0,1e 0.3S 0,72 0.72 о.зе 0.10 0.03 0,05
0 .то 0,04 оот 0,14 0,3$ ftW 0.5$ 0,14 0,07 0,04
0,5c 0,03 Û 05 0,10 0,20 0.40 0.40 0.20 0.1ü 0.05 0,03
0.30 0.С2 0.03 0,06 0,12 0.24 0.24 0.12 0.06 0,03 0,02
о.ю 0,01 001 0,02 0,04 o.us o.«¡ 0.04 oioг U.01 0,01
0,06 a 13 0,20 0,40 0.30 о.ао 0.40 0.2q 0.10 0,05
Рис.1. Матрица вероятности и последствий
Каждому риску присваивается показатель (ранг) на основании вероятности его появления и воздействия на цель проекта в случае его возникновения.
Результатом качественного анализа рисков является обновленный реестр рисков, включающий в себя относительное ранжирование или список приоритетов рисков проекта. Кроме того, риски, сгруппированные по категориям, список рисков, требующих немедленного реагирования, список рисков для дополнительного анализа и реагирования, список низкоприоритетных рисков, нуждающихся в наблюдении.
Количественный анализ рисков
Количественный подход к принятию решений в условиях неопределенности использует оценку эффекта тех рисков, которые в процессе качественного анализа были квалифицированы как потенциально или существенным образом влияющие на конкурентоспособные свойства проекта. В ходе этого процесса используются такие методы, как моделирование Монте-Карло и анализ дерева решений15. Они используются для оценки вероятности достижения конкретных целей проекта и идентификации рисков, требующих наибольшего внимания.
Количественный анализ рисков проводится на основе данных плана управления рисками, реестра рисков, а также плана управления проектом и активов организационного процесса (см. стр. 8).
Инструменты и методы количественного анализа рисков можно разделить на два класса. Первый включает в себя методы сбора и представления данных, второй - методы количественного анализа рисков и моделирования.
В методы сбора и представления данных входят опросы, распределение вероятностей рисков и экспертные оценки. Опросы используются для количественной оценки вероятности наступления и воздействия рисков на цели проекта, проводятся с участием экспертов и, как правило, включают в себя сбор информации об оптимистическом, пессимистическом и наиболее вероятном сценарии. Распределение вероятностей для каждого рискового события задает функцию распределения, наиболее полным образом характеризующую диапазон количественного воздействия риска на проект и частоту его возникновения. Выбор функции
распределения осуществляется на основании статистической обработки исторических данных по факторам риска, исходя из типа операций или путем решения стохастических дифференциальных уравнений. Наиболее часто применяются бета- и треугольное распределения, а также равномерное, нормальное и логарифмически нормальное. На этапе экспертной оценки привлекаются как внешние, так и внутренние эксперты (являющиеся сотрудниками организации), для подтверждения правильности данных и методов, используемых в количественном анализе рисков.
Методы количественного анализа рисков и моделирования включают в себя «анализ чувствительности», анализ ожидаемой денежной стоимости, анализ дерева решений, моделирование и имитация.
Анализ чувствительности помогает определить, какие риски обладают наибольшим потенциальным влиянием на проект. В процессе анализа устанавливается, в какой степени неопределенность каждого элемента проекта отражается на исследуемой цели проекта, если остальные неопределенные элементы принимают фиксированные значения.
Анализ ожидаемой денежной стоимости (ОДС) - это статистическое понятие, при помощи которого рассчитывается средний результат для случаев, когда будущее включает в себя сценарии, которые нельзя с уверенностью предсказать. ОДС благоприятных возможностей выражается в положительных величинах, а риски - в отрицательных величинах. При расчете ОДС значение каждого возможного результата умножается на вероятность его появления, а затем полученные значения суммируются (в случае с использованием деревьев решений). Например, если существует 50% вероятность того, что во время выполнения проекта нехватка квалифицированных разработчиков приведет к убыткам в $1000, то ожидаемая денежная стоимость от этого вероятного события -$500 (0.5*$1000).
Дерево решений - это диаграмма, описывающая действия при выборе той или иной альтернативы. С помощью дерева решений можно включить вероятность в анализ комплексных решений, включающих множество альтернатив и неизвестных будущих условий, которые могут быть определены при помощи дискретного и непрерывного распределения вероятностей. Диаграмма объединяет стоимость каждой возможности выбора, вероятность возникновения всех возможных сценариев, а также прибыли или убытки на каждом альтернативном логическом пути.
Анализ дерева решений включает в себя шесть этапов:
1.Определение проблемы. Идентифицируются факторы, которые связаны с выбором доступных альтернатив. Затем оценивается распределение вероятностей, с учетом возможного поведения этих факторов. Собирается финансовая информация относительно условных результатов.
2.Моделирование процесса решения. Строится дерево решения, иллюстрирующее все альтернативы, связанные с проблемой. Этот шаг структурирует проблему, позволяет полностью схематично представить процесс решения шаг за шагом. На этом этапе выбирается число периодов, на которые должно быть разделено будущее.
3.Подстановка значений вероятности и соответствующей финансовой информации. Данные подставляются к каждой ветке, а также ко всем ответвлениям от нее. Это позволяет сопоставить значения вероятности и условный денежный результат по каждой альтернативе.
4.«Решение» дерева. Для всех узлов дерева рассчитывается ОДС; результаты по всем веткам суммируются. Определяется ветвь дерева, имеющая наибольшую ожидаемую денежную стоимость.
5.Анализ чувствительности. Определение, как выбранное решение реагирует на изменения входных данных. Изменение значений вероятности и условных финансовых результатов позволяет проверить величину и направление реакции. Этот шаг позволяет проводить эксперименты без реальных обязательств или реальных ошибок.
6.Формирование списка основных предположений. Объясняются методы оценки для определения распределения вероятностей. Какие виды бухгалтерского учета и методов определения издержек лежат в основе условных финансовых результатов; указываются причины, по которым будущее было разделено на определенное число периодов. Аргументируя данные предположения, Вы позволяете другим знать то, какие риски они берут, когда они используют результаты вашего анализа.
7.Анализ дерева решений. Использование этого шага дает возможность определить пределы, под которыми полученные результаты будут иметь силу, особенно условия, при которых решение не будет иметь силу.
Моделирование и имитация проекта использует целостную модель проекта для определения последствий от воздействия подробно описанных неопределенностей на результаты проекта в целом. Моделирование обычно проводится с помощью метода Монте-Карло. Это метод формализованного описания неопределенности, используемый в сложных для прогнозирования проектах. Он связан с применением имитационных моделей, позволяющих создавать множество сценариев и наиболее полно учитывающий всю гамму неопределенностей, с которой может столкнуться реальный проект.
Последовательность шагов при реализации этого метода следующая:
1.Создание модели прогнозирования. В качестве модели прогнозирования выступают математические зависимости, полученные при расчете показателей эффективности программного проекта. Например, такими показателями могут быть коэффициент окупаемости инвестиций (ROI), рентабельность реализации, оборачиваемость совокупных активов.
2.Выявление ключевых факторов, которые в значительной степени влияют на результаты проекта и имеют значительную вероятность наступления.
3.Определение распределения вероятности ключевых факторов. Для этого устанавливаются минимальное и максимальное значения, которые, по мнению аналитика, могут принимать ключевые факторы; прогнозируются вид и параметры распределения вероятности внутри заданных границ.
4.Выявление корреляционных зависимостей между переменными. Определяются все зависимые переменные, и с помощью коэффициентов корреляции описывается степень этих зависимостей.
5.Генерирование множества случайных сценариев, основанных на заданных ограничениях. Для реализации этого этапа требуется описание модели прогнозирования на компьютере. Количество «прогонов» модели, выполняемой на компьютере, должно быть достаточно, чтобы полученная выборка была репрезентативна.
6.Проведение статистического анализа результатов имитационного моделирования.
В процессе количественной оценки и анализа рисков менеджер проекта должен помнить о наиболее важном аспекте процесса определения количественной меры риска. Дело в том, что все численные значения производны от наилучших оценок, которые известны как прогнозы. Поскольку нет уверенности в том, что наступил момент, который описывается в прогнозе для этих рисков, нельзя также заключить, оказывает ли риск какое-то реальное воздействие на данный проект. Задача состоит в том, чтобы количественно оценить
относительный риск, сравнивая один риск с другим, и спрогнозировать влияние данного риска на проект.
Планирование реагирования на риски
Планирование реагирования на риски - это разработка методов и технологий снижения отрицательного воздействия рисков на проект. Планирование включает в себя идентификацию и распределение каждого риска по категориям. Эффективность разработки реагирования прямо определит, будут ли последствия воздействие риска на проект положительными или отрицательными.
Стратегия планирования реагирования должна соответствовать типам рисков, рентабельности ресурсов и временным параметрам. Вопросы, обсуждаемые во время встреч, должны быть адекватны задачам на каждой стадии проекта, и согласованы со всеми членами группы по управлению проектом. Обычно требуется несколько вариантов стратегий реагирования на риски.
Наиболее часто рассматриваются следующие типы реакций:
Снижение или сохранение риска. Это наиболее распространенный вариант реакции на риск. К примеру, если результаты моделирования показывают высокую вероятность задержки сроков выполнения проекта к заданной пользователем дате, наиболее оптимальным будет распределение дополнительных ресурсов (а также использование сверхурочных работ) на операции критического пути, что повлечет за собой снижение риска. В некоторых случаях сознательно идут на сохранение риска. Некоторые риски настолько велики, что их просто невозможно переадресовать или снизить. Руководитель проекта просто принимает риск как должное, так как возможность такого риска очень мала. В других случаях риски, внесенные в сметный резерв проекта, будут просто покрыты в случае своего возникновения. Риск сохраняется, если разработать чрезвычайный план и применить его в случае риска. Иногда риск можно не учитывать и просто согласиться с превышением сметы в случае риска.
Переадресация риска другой стороне - дело достаточно обычное; переадресация не меняет риск. Переадресация риска почти всегда приводит к выплате надбавки за процесс переадресации. Контракты с фиксированными ценами являются классическим примером переадресации риска от владельца к подрядчику. Подрядчик понимает, что его компания заплатит за любой риск, который будет иметь место. Следовательно, фактор финансового риска добавляется к стоимости контракта. Перед тем как переадресовать риск, владелец должен решить, какая сторона лучше всего сумеет контролировать действия, которые могли бы привести к риску. А также способен ли подрядчик справиться с риском. Более легким способом переадресации риска является страхование. Однако во многих случаях это нереально, так как нелегко и недешево дать определение риска и условий страховому агенту, незнакомому с проектом. Такие риски, как природные катаклизмы, обладающие низкой вероятностью и серьезными последствиями, определяются и страхуются более легко.
Участие в рисках означает, что разные стороны принимают на себя части риска. Примером подобного подхода может служить совместная разработка формата хранения видеоданных и программных алгоритмов работы с ними несколькими конкурирующими между собой компаниями.
Мониторинг и контроль
Мониторинг и контроль контролируют идентификацию рисков, определяют остаточные риски, обеспечивают выполнение плана рисков и оценивают его эффективность с учетом понижения риска. Показатели рисков, связанные с осуществлением условий выполнения плана фиксируются. Мониторинг и контроль сопровождает процесс внедрения проекта в жизнь.
Качественный контроль выполнения проекта предоставляет информацию, помогающую принимать эффективные решения для предотвращения возникновений рисков. Для предоставления полной информации о выполнении проекта необходимо взаимодействие между всеми менеджерами проекта.
Цель мониторинга и контроля состоит в выявлении следующих событий:
• Система реагирования на риски внедрена в соответствии с планом;
• Реагирование достаточно эффективно или необходимы изменения;
• Риски изменились по сравнению с предыдущим значением;
• Наступление влияния рисков;
• Необходимые меры приняты;
• Воздействие рисков оказалось запланированным или явилось случайным результатом
Контроль может повлечь за собой выбор альтернативных стратегий, принятие
корректив, перепланировку проекта для достижения базового плана. Между менеджерами проекта и группой риска должно быть постоянное взаимодействие, должны фиксироваться все изменения и явления. Отчеты по выполнению проекта должны формироваться регулярно.
Использование программных средств управления рисками
Автоматизация процессов идентификации и планирования реагирования на риски значительно повышает эффективность работы руководителя проекта. Количественная оценка рисков в полном объеме может быть произведена только с использованием современных информационных технологий, реализующих математические модели оценки рисков. Современные методики количественного анализа основаны на РБЯТ-анализе, анализе сценариев и вычислениях методом Монте-Карло16. На рынке программных средств, поддерживающих управление рисками, представлено большое количество систем, реализующих процессы управления рисками в проектах различной сложности. Каждая из этих систем родилась при автоматизации управления проектами в конкретной области деятельности (строительство, нефтедобыча, и др.). В силу этого, при реализации нового проекта возникают сложности, связанные со спецификой новой проблемной области и накладывающие свои требования на систему управления рисками. Тем не менее, любая современная система может предложить реализацию некоторых типовых требований к полнофункциональному управлению рисками:
1.Поддержка всего жизненного цикла управления рисками (планирование управления рисками, идентификация, анализ, планирование реагирования, мониторинг и контроль);
2.Поддержка анализа всех составляющих риска (стоимостной, временной, ресурсной);
3.Поддержка различных методов расчета и моделирования;
4.Широкие графические возможности и автоматическая генерация отчетов;
5. Документирование и поддержка базы данных по рискам.
Управление рисками может быть встроено непосредственно в систему управления проектами, или представлять собой отдельный модуль, который можно использовать автономно, на основе модели, созданной в системе управления проектами.
В настоящее время на российском рынке активно используются около 10 систем данного класса. Наиболее полный спектр функций предоставляют следующие системы:
• @Risk Professional for Project (модуль, который может быть интегрирован в MS Project, http://www.palisade.com);
• Open Plan (полнофункциональная, наиболее мощная система управления проектами, включающая в себя модуль управления рисками, http://www.welcom.com);
• RiskTrak (система управления рисками, http://www.risktrak.com/);
• Enterprise Risk Assessor (система управления рисками, http://www.methodware.com);
Анализ функциональности названных продуктов позволяет выделить Open Plan и @Risk
Professional for Project как системы, в максимальной степени отвечающие предъявленным требованиям.
Основным преимуществом вышеприведенных систем является универсальность, позволяющая автоматизировать управление рисками в широком спектре отраслей и произвести оценку влияния нежелательных событий на ход выполнения проекта.
Управление программными проектами имеет следующую специфику: новизна используемых технологий, сложность заданий, уникальность создаваемых решений, отсутствие у разработчиков необходимой квалификации, и неразвитая методология оценки трудозатрат в рамках проекта. В силу этого, использование модулей оценки рисков существующих систем неудобно, т.к. они не учитывают специфики программных проектов, жизненного цикла разработки ПО, особенностей команды разработчиков, отличительных черт процессов управления программными проектами.
Требования к программной системе управления рисками
Определим для программной системы управления рисками следующие функциональные требования:
1.Реализуемые процессы управления рисками в программных проектах должны соответствовать стандарту Project Management Body of Knowledge Института Управления Проектами (PMI).
2.Система должна учитывать специфику проектов по созданию программного обеспечения.
3.Подсистема количественной оценки рисков должна предоставлять возможности по развернутой параметризации отдельных рисков проекта и их взаимосвязи.
4.Подсистема количественной оценки рисков, на основании базовых параметров проекта, должна отслеживать состояние критических значений, заданных для каждого риска, и предотвращать варианты, способствующие неудачному завершению проекта.
5.Модель оценки рисков должна позволять применять как традиционные алгоритмы, основанные на чувствительности, PERT-моделирование, моделирование по методу Монте-Карло и стресс-тестирование системы, так и специальные оценочные алгоритмы, характерные для проектов разработки ПО.
6. Оценка риска может проводиться как для любого элемента иерархической структуры работ, так и интегрально для всего проекта, в любой момент его планирования и исполнения.
7.Результаты моделирования процессов управления рисками должны быть представлены в удобном виде для быстрой оценки текущего состояния проекта.
8.Система должна представлять собой универсальный модуль с возможностью подключения к различными системам управления проектами (на уровне спецификации интерфейсов).
Работа с программной системой управления рисками осуществляется по следующей методике (рис.2):
1.Определение проекта и иерархической структуры работ проекта (ИСР) в системе управления программными проектами (СУПП), (т.е. группировка элементов (работ) проекта по признаку их отношения к определенным выходным результатам, позволяющей структурировать и определять общее содержание проекта; каждый нижний уровень иерархии детализирует свой верхний уровень).
2. На основании составленной декомпозиции работ в программной системе оценки рисков задается и параметризируется набор рисковых событий, связанных с выполнением отраженных в ИСР операций. Также могут задаваться риски, не определенные в ИСР, но влияющие на ход выполнения проекта (пример: степень участия заказчика в создании технического задания на разработку программного обеспечения).
3.Определяется корреляция между заданными рисковыми событиями, посредством правил взаимосвязи, поддерживаемых системой (поддерживаются арифметические операции и процентные соотношения).
4.В системе оценки и имитационного моделирования рисков программного проекта задаются базовые параметры модели и выполняется процесс вычисления ключевых параметров проекта на основе вероятностных алгоритмов.
5.Полученные результаты моделирования используются для ранжирования рисковых событий по степени влияния на проект и принятия решений по их смягчению, переназначению или хеджированию. По результатам моделирования возможно повторное использование созданной модели для количественной оценки ключевых параметров эффективности имеющихся альтернатив.
Определение
и WB!
Пара
(коли
эизация риское г венная оценка
Определен рисковь
корреляции
Анализ результатов, действия
Имитационное моделирование
Рис. 2. Алгоритм использования системы количественной оценки рисков
На основе указанной методики был разработан модуль управления рисками, архитектура которого, вместе с системой управления программными проектами, представлена на рис.3:
Система управления проектами (например, MS Project)
ИСР
Ресурсы
Сетевая модель
Календари
(Интерфейсы)
Модуль управления рисками
Система идентификации рисков (рубрикатор)
Предметные области риска
Категории риска
Факторы категорий риска
Вероятностные распределения Экспертные оценки Ключевые показатели эффективности (КПИ)
Система количественной оценки рисков
Система имитационного моделирования
Система анализа результатов
Имитационное моделирование : тип, параметры
Изменения КПИ
Детализированные текстовые отчеты
Графики
Система принятия решений
Рис 3. Архитектура программной системы количественной оценки рисков
Использование представленных систем осуществляется в следующем порядке:
1. В системе управления проектами (СУП) формируются и передаются в модуль управления рисками:
• иерархическая структура работ проекта (ИСР);
• данные о ресурсах, необходимых для выполнения каждого элемента ИСР;
• сетевая диаграмма расписания проекта (сетевая модель, отображение логических связей между плановыми операциями проекта);
• календари проекта;
• и др.
2. В системе идентификации рисков на основании переданных их СУП данных задается и параметризируется набор рисковых событий, связанных с выполнением проекта. С целью наиболее полной идентификации рисков используются справочники предметных областей и категорий риска. Для идентифицированных рисков создается модель прогнозирования, описывающая взаимосвязь между рисковыми событиями (с использованием специализированного языка описания рисков).
3. В системе количественной оценки рисков для каждого идентифицированного риска задаются параметры вероятностного распределения, на основе опытных данных, экспертных оценок, данных системы КПИ.
4. Система имитационного моделирования генерирует множество случайных сценариев для прогнозной модели, основанных на заданных пользователем ограничениях. Результат моделирования - детализированные текстовые отчеты, графики, изменения КПИ -передаются в систему принятия решений. По результатам моделирования возможно повторное использование созданной модели прогнозирования для количественной оценки ключевых параметров эффективности имеющихся альтернатив.
На основе полученной в результате моделирования информации, можно выявить и оценить потенциальные проблемы проекта, связанные с его длительностью, ресурсами или стоимостью, и принять решения об адекватной на них реакции.
Заключение
Методика управления рисками была реализована в программной системе оценки и имитационного моделирования рисков в СУПП, и внедрена в опытную эксплуатацию в структурном подразделении по управлению образовательными проектами компании «Базовый элемент», использовалась в ряде проектов для идентификации, качественной и количественной оценки, а также моделирования рисковых событий, связанных с выполнением данных проектов.
Это позволило:
1. Уменьшить отклонения от базового плана проектов по параметрам «Стоимость -Качество - Ресурсы» на 34% за счет создания математических моделей рисковых событий, позволяющих проводить моделирование по методу Монте-Карло, анализ чувствительности и стресс-тестирование для всех параметров проекта.
2. Обеспечить оперативное принятие решений на основе анализа вариантов выполнения проекта. Производить быструю оценку ключевых показателей эффективности проекта при изменении одного или нескольких его параметров, а также более точно выполнять прогнозирование изменений таких параметров проекта, как длительность, стоимость, качество, ROI (коэффициент возврата инвестиций).
