" №13-14. 2003г.
Основные понятия
Выполнение проектов, особенно если они связаны с разработкой программного обеспечения (ПО), — явно не детерминированный процесс. Новизна используемых технологий, сложность заданий, отсутствие у разработчиков необходимой квалификации — из-за этих и многих других факторов проекты часто идут не так, как планировалось. Один из приемов, повышающих вероятность успеха в таких условиях, — использование методов управления рисками. Традиционно под управлением рисками понимают процесс идентификации и анализа событий и ответа на них. При этом ставится цель максимизировать вероятность положительных событий и их последствия и минимизировать вероятность и последствия событий неблагоприятных. Впрочем, достаточно часто ограничиваются работой только с негативными событиями.
Введем несколько формальных определений.
Риск — это событие, способное (в случае его реализации) оказать влияние на ход выполнения проекта. Риски существуют во всех проектах, но не всегда реализуются. Риск, который реализовался, превращается в проблему.
Воздействие, или последствие риска — влияние реализовавшегося риска на возможность выполнить определенные составляющие плана. Воздействие обычно касается стоимости, графика и технических характеристик разрабатываемого продукта. К примеру, при разработке ПО воздействие риска может привести к тому, что продукт перестанет удовлетворять заказчика в полной мере или даже станет непригодным. Воздействие часто имеет скрытый период — от момента проявления риска до появления результирующего изменения в системе. Для оценки воздействия риска обычно используют условные единицы или качественную шкалу (например, пренебрежимое, малое, существенное, большое, катастрофическое). Для работы с положительными рисками нужно соответствующим образом расширить шкалу.
Вероятность риска — вероятность, с которой данный риск превратится в проблему. Здесь также применима качественная шкала (пренебрежимая вероятность, малая и т. д. — вплоть до весьма вероятной). Но могут использоваться и численные значения (обычно выбирают некоторый набор типовых значений, например, 0,1; 0,3; 0,5; 0,7; 0,9). Следует отметить, что событие, которое должно обязательно произойти, не является риском, и действия, которые необходимо в связи с ним предпринять, определяются в рамках обычного планирования и управления, а не управления рисками.
Управление рисками — это процедуры и действия, которые позволяют менеджеру выявлять, оценивать, отслеживать и устранять риски до или во время их превращения в проблемы. Риски желательно выявить как можно раньше и заведомо еще до того, как они превратились в проблему (обычно в этом случае принятие мер требует меньших ресурсов). После выявления риска необходимо принять решение об ответных действиях. Задача руководителя проекта — выбрать такие действия, которые позволят снизить вероятность неблагоприятного события или уменьшить его последствия в случае реализации риска. При этом желательно, чтобы расход ресурсов был минимальным.
Наиболее часто используются следующие стратегии борьбы с риском.
1. Избежать риска. Реорганизовать проект таким образом, чтобы он не зависел от данного события. Например, при разработке ПО можно исключить вызывающую сомнение функциональность. К сожалению, таким образом редко удается полностью удовлетворить заказчика.
2. Переадресовать риск. Исполнитель прибегает к своего рода страховке — если проявится риск, заказчик берет на себя оплату дополнительных работ. В случае реализации такого риска руководство компании обязуется привлечь к проекту еще некоторое количество сотрудников.
3. Согласиться с присутствием риска. Это не означает, что не надо ничего делать, а просто пассивно ждать реализации риска. Согласившись с присутствием риска, можно предпринять некие действия, направленные на снижение вероятности его проявления, уменьшение его последствий (например, предусмотреть такую архитектуру системы, которая позволит компенсировать потерю производительности) либо разработать план альтернативных действий (например, перехода на другую СУБД), который будет выполняться, если риск реализуется.
Список рисков — упорядоченный по приоритету список выявленных и отслеживаемых рисков. Приоритет определяется как произведение вероятности на величину воздействия (в условных единицах).
Диалог с оппонентом
Типичный диалог специалиста по управлению рисками (Специалист) с менеджером проекта (МП), которому предстоит внедрять управление рисками в своем проекте, выглядит примерно так.
МП: Зачем нужно управлять рисками? Может быть, в нашем проекте их вообще нет?
Специалист: Вот признаки, которые часто указывают на рискованный характер проекта:
- большие размеры разрабатываемой системы;
- неясные и изменяющиеся требования;
- использование в проекте новых технологий;
- сложность системы;
- размеры системы, не соответствующие бюджету;
- высокая степень зависимости от определенных людей.
Однако риски — это не особенность каких-то специфических проектов. Любой проект без труда можно сделать крайне рискованным. Для этого достаточно:
- неправильно оценить реальный размер и сложность задач разработки;
- недостаточно точно оценить необходимые ресурсы;
- превысить возможности (компетенцию) организации;
- не обеспечить стабильность пожеланий пользователя;
- использовать недостаточно зрелые программные среды и инструменты;
- назначить сроки выполнения проекта без учета реальных размеров и сложности системы;
- предпринять действия, не согласующиеся с корпоративной культурой фирмы-разработчика;
- понадеяться на “серебряную пулю”, которая позволит резко повысить производительность.
МП: Тогда, может быть, лучше посмотреть, какие именно риски реализуются, и потом бороться с возникшими проблемами?
Специалист: Как правило, последствия риска — не фиксированная величина. Они зависят от момента, когда риск выявлен. Например, если бы мы заранее учли, что нам придется перейти на другую СУБД, то большую часть бизнес-логики мы бы перенесли на сервер приложений. И нам не пришлось бы переписывать столько хранимых процедур и триггеров.
Основные проблемы
Управление рисками — несложный и нетрудоемкий процесс. Больших проблем с его внедрением теоретически быть не должно. Но, к сожалению, сказать, что он внедрен повсеместно, нельзя. И дело здесь не только в технических трудностях, но и в традициях, которые часто приходится при этом ломать.
Если спросить у рядового разработчика или руководителя, почему в их фирме нет процесса управления рисками, можно услышать массу самых разных ответов. Тут будет и самое простое: “У нас нет рисков”, и более изощренные варианты: “Мы боремся с проблемами по мере их возникновения”, “Наше дело — разработка программы, а не заполнение бюрократических форм”, “Использование этого инструмента не рискованно. Так нам сказал поставщик”. Реальные же причины нелюбви к управлению рисками чаще всего кроятся в следующем.
Прежде всего руководство боится отойти от традиционной позиции “мы это обязательно сделаем”. Управление рисками предполагает, что могут быть и неудачи. А отсюда и следующая причина: руководство часто рассматривает управление рисками как способ, позволяющий подчиненным обосновать будущее поражение. Хотя реально речь идет как раз о мерах по повышению вероятности успешного выполнения проектов.
Руководители проектов тоже нередко побаиваются управления рисками. Они считают, что если заранее выявленный риск все-таки реализуется, это будет рассматриваться как их ошибка. Хотя реально такая ситуация обычно позволяет продемонстрировать, насколько удалось снизить потенциальные последствия риска с помощью превентивных мер.
Есть свои причины не любить управление рисками и у исполнителей. С одной стороны, можно опасаться, что на принесшего плохую весть повалятся все шишки за ее последствия. С другой — в условиях налаженного управления рисками пропадает необходимость в подвигах. А ведь так приятно чувствовать себя героем, спасшим проект от очередной проблемы!
Таким образом, внедрение управления рисками часто требует существенного изменения всей корпоративной культуры. Ниже мы рассмотрим в числе прочего некоторые методы и приемы, позволяющие ускорить этот процесс.
Задачи управления рисками
Процесс управления рисками разделяется на несколько составляющих. Специалисты несколько расходятся во мнениях по поводу их числа и классификации, но, на наш взгляд, достаточно полным можно считать следующий перечень.
Планирование управления рисками. План должен описывать общие подходы к управлению рисками в проекте и основные действия, которые придется выполнять.
Выявление рисков. Необходимо определить те ситуации или события, которые могут вызвать отрицательные последствия для проекта. Участники проекта выявляют риски на основе своего опыта, приобретенного в предыдущих проектах или на предыдущих стадиях данного проекта. Выявленные риски тщательно документируются.
Анализ и оценка приоритетности рисков. Выявленный риск следует проанализировать, чтобы определить его потенциальное влияние на расходы, график работ и т. д. Для каждого риска оценивается также вероятность, с которой он может реализоваться. Приоритет риска определяется на основе произведения его вероятности на возможные последствия (выражаемые величиной ожидаемого ущерба).
Планирование ответных действий. Для каждого риска определяются шаги, необходимые для снижения вероятности проявления риска и его последствий. Выполнение планов не входит в процесс управления рисками, оно осуществляется в рамках основных процессов разработки. Для борьбы с рисками можно планировать не только действия, но и соответствующие резервы (деньги, время, люди).
Мониторинг рисков. Цель данной меры — изменение приоритетов и планов преодоления рисков при изменении их вероятности и последствий, а также своевременное выявление рисков, которые реализуются в данный момент. По сути представляет собой повторение шагов выявления и анализа рисков.
Рассмотрим перечисленные задачи более детально.
Планирование управления рисками
В планировании управления рисками есть ряд главных моментов.
Назначение ответственного лица. Отвечать за процесс должен один человек, который собирает сведения о возможных рисках, организует их анализ и формирует регулярные отчеты. Чаще всего это не требует полной занятости — ответственный может выполнять и другие роли в проекте. Планирование и выполнение действий, направленных на снижение рисков, остается в ведении руководителя проекта. Выделение специального человека, в чьи обязанности входит выявление рисков, и введение дополнительных премий тем, кто выявил риск, помогает бороться с негативным отношением к управлению рисками в команде.
Определение тактики и методов, применяемых в конкретном проекте для выявления, анализа и снижения рисков. Это может быть метод исключения рискованных решений или разработка запасных планов. Здесь же устанавливаются поощрения для сотрудников, указавших на реализовавшиеся риски или предложивших наиболее эффективные меры по их устранению и т. п.
Определение бюджета, предназначенного для управления рисками. Бюджет существенно влияет на ассортимент средств, которыми можно воспользоваться для преодоления рисков.
Планирование основных действий по управлению рисками и их привязка к жизненному циклу проекта (согласование сроков мероприятий, направленных на управление рисками, с основными производственными процессами).
Выявление рисков
Риски, с которыми приходится иметь дело в проектах разработки ПО, можно условно разбить на несколько типов:
1. Технические риски, связанные с разработкой новых решений или изменением старых, направленным на повышение производительности или достижение принципиально новой функциональности.
2. Программные риски, связанные с приобретением или использованием ПО третьих фирм (если это приобретение не находится под должным контролем разработчиков и руководителей проекта).
3. Риски на этапе сопровождения системы, в том числе связанные с размещением ПО у заказчика, поддержкой, обучением и т. п.
4. Стоимостные риски, связанные с превышением затрат или проблемами финансирования проекта.
5. Риски сроков, связанные с необходимостью ускорить разработку из-за внешних причин.
6. Риски неудовлетворенности заказчика.
Чтобы определить риски проекта, обычно используются следующие четыре метода.
Исторический анализ. Сравнение данного проекта с аналогичными, выполненными ранее. Вчерашние проблемы часто остаются рисками в новых проектах.
Аналитический метод. Включает такие технологии, как моделирование, анализ по схеме "причина-результат", анализ таблиц истинности и т. д.
Совещания, посвященные выявлению и оценке рисков. Как правило, они проводятся с использованием мозгового штурма. Если число участников проекта невелико, они все приглашаются на совещание. В противном случае собирают только лидеров групп и ведущих разработчиков.
Индивидуальные интервью. Проводятся как с руководством проекта, так и с рядовыми участниками. По желанию интервьюируемых они могут остаться анонимными и не упоминаться как “источники” риска. Сотрудники могут даже присылать свои сообщения анонимно по электронной почте — анонимность позволяет избежать опасений, что “принесшего дурную весть накажут”.
Каждый выявленный риск необходимо документировать, записав суть риска и причины, которые могут его вызвать.
Анализ и оценка приоритетности
Выявленные риски следует проанализировать. Анализ включает оценку вероятности риска и его возможных последствий в кратко- и долгосрочном плане.
Кроме того, анализ рисков предполагает сравнение новых рисков с ранее выявленными. Новый риск может повторять или расширять один из ранее выявленных. В таком случае следует не включать его в список рисков, а уточнить описание и оценки выявленного раньше риска.
Если же риск новый, его нужно оценить. По результатам опросов и интервью или по аналогии с ранее выполнявшимися проектами для риска оценивается вероятность проявления и тяжесть последствий. К сожалению, в таких случаях редко удается получить сколько-нибудь точные численные оценки. Тем не менее обычно не составляет труда выбрать для риска одно из заранее определенных значений вероятности (например, из уже упоминавшегося ряда от 0,1 до 0,9) и целочисленное значение тяжести последствий (скажем, от 1 до 5). Сделать это проще, чем оценить последствия в реальных деньгах. Вместе с тем такой оценки обычно хватает для решения главной проблемы — выделения наиболее приоритетных рисков. В результате возможные показатели приоритета (произведения вероятности проявления риска на тяжесть последствий) будут варьироваться в пределах от 0,1 до 4,5 (см. таблицу).
Таблица. Возможные значения приоритетов рисков
| |
0.1 |
0.3 |
0.5 |
0.7 |
0.9 |
|
1 |
0.1 |
0.3 |
0.5 |
0.7 |
0.9 |
|
2 |
0.2 |
0.6 |
1.0 |
1.4 |
1.8 |
|
3 |
0.3 |
0.9 |
1.5 |
2.1 |
2.7 |
|
4 |
0.4 |
1.2 |
2.0 |
2.8 |
3.6 |
|
5 |
0.5 |
1.5 |
2.5 |
3.5 |
4.5 |
Как правило, риски с текущим значением приоритета меньше 1 (выделены зеленым) просто игнорируются. Риски со значением приоритета в диапазоне 1—2 оставляются в списке, но реальных действий по их устранению обычно не предпринимается. Основное же внимание уделяется рискам с приоритетом больше 2.
Если для определения вероятности и последствий рисков использовались качественные оценки, то и приоритетность рисков оценивается на качественном уровне. Например, можно игнорировать те риски, у которых вероятность или последствия пренебрежимые. А высокоприоритетными следует считать риски, у которых вероятность выше средней и последствия выше существенных.
Как правило, список приоритетных рисков для проекта ограничивают десятью или двадцатью (для очень больших проектов) наиболее значимыми. Если учитывать большее число рисков, это, с одной стороны, приведет к существенно большему расходу ресурсов, а с другой стороны, почти не скажется на вероятности успешного завершения проекта. Списки наиболее приоритетных рисков должны быть доступны для всех участников проекта.
Для рисков с высоким приоритетом в ходе анализа очень полезно определить показатели (метрики), которые позволяют судить о приближении момента проявления риска или о существенном изменении вероятности его проявления.
Планирование ответных действий
Для каждого из рисков, вошедших в список приоритетных, необходимо выбрать стратегию реагирования. Как уже говорилось, стратегия может быть направлена на то, чтобы “обойти” риск, застраховаться от него или смягчить его последствия. Иногда риск можно исключить полностью, отказавшись от одного-двух низкоприоритетных свойств системы. В других случаях можно попытаться использовать более зрелые или лучше известные разработчикам технологии.
В случае внешних рисков, на которые практически невозможно как-то воздействовать, единственным ответом будет резервирование дополнительных ресурсов. Как говорят, на этот случай можно даже оформить страховку в страховой компании. Как минимум, следует оговорить потенциальный риск с руководством собственной компании и с заказчиком.
И, наконец, существуют риски, относящиеся к категории достаточно приоритетных и при этом поддающиеся воздействию. Это и есть основное поле битвы. Для таких рисков необходимо выбрать действия, которые помогут снизить вероятность наступления события и его возможные последствия.
Строго говоря, задача не в том, чтобы свести возможность проявления риска или его последствия к нулю. Если такое решение и достижимо, оно может потребовать слишком много ресурсов. Реальная цель — снизить вероятность и последствия проявления риска до приемлемого уровня.
Если вы уверены в пригодности вероятностной модели для ваших рисков и в точности ваших оценок, то для анализа принимаемых решений и выбора оптимального можно применить, например, байесов подход. Оптимальным будет решение, которое минимизирует среднюю стоимость выполнения проекта или максимизирует среднюю прибыль. Но для этого требуется перевести используемые условные единицы в деньги, и в деньгах же оценивать стоимость планируемых мероприятий по преодолению рисков.
Для рисков, не устраненных окончательно или не поддающихся "смягчению", нужно разработать хотя бы предварительный резервный план действий на случай их проявления (часто его называют “план Б”).
Для части рисков, обычно связанных с недостатком информации, можно явно указать действие, которое определит, проявится риск или нет. Например, чтобы понять, удастся ли интегрировать новую систему в уже существующую инфраструктуру, как правило, достаточно создать небольшой прототип новой системы. Он либо покажет, как должна осуществляться интеграция, либо заставит проявиться соответствующий риск. Типичный прием — запланировать такие действия на возможно более ранние сроки. Это позволяет, с одной стороны, менее спешно и более осмысленно предпринимать ответные действия, с другой стороны — раньше выявить новые риски, которые могут возникнуть после проявления уже известных.
Мониторинг рисков
К сожалению, управление рисками — это не одноразовое мероприятие. Вероятность и последствия однажды выявленных рисков и оценка их приоритетности могут в дальнейшем измениться; могут появиться и новые риски. Например, по мере накопления сведений об определенных инструментах и методах у исполнителей растет уверенность, что работы могут быть выполнены в срок. Или, наоборот, опыт сборки и тестирования предварительных версий системы, возможно, заставляет усомниться в достаточной ее производительности. Это значит, что данные о рисках должны регулярно обновляться. Повторный анализ рисков желательно провести таким образом, чтобы свежие сведения можно было использовать при планировании очередной итерации проекта.
Специальный случай мониторинга — анализ показателей (метрик), которые могут указывать на приближение или скрытую реализацию одного из выявленных ранее рисков. Метрики должны вычисляться достаточно часто. Изменение значений свыше установленного предела должно быть поводом к внеочередному анализу и оценке рисков.
Некоторые практические рекомендации
Опыт управления рисками позволил определить несколько типичных приемов, как правило, существенно повышающих качество процесса.
Формализация управления рисками. Борьбу с рисками нужно оформить официально и определить необходимые формальные процедуры. Для реализации процесса назначается ответственный. Составляется и регулярно обновляется план работ по управлению рисками. Ведется формальная база данных рисков или хотя бы их список. Проводится формальное отслеживание рисков. Регулярно формируются и доводятся до всех участников проекта отчеты о состоянии рисков. Результаты управления рисками активно используются в управлении проектом. Без такой формализации исполнители в текучке могут просто забыть о новой работе, либо не удается преодолеть негативное отношение участников разработки к процессу управления требованиями.
Выделение специальных резервов для нейтрализации рисков. Для борьбы с рисками заранее планируются резервы, включающие резерв времени (обычно порядка 10% от оцененного времени выполнения проекта); резерв денежных средств на дополнительный штат, инструменты, дополнительное время разработки; собственно резервный штат, включая список специалистов, которых можно быстро привлечь к работе.
Отсутствие резервов может вызвать очень тяжелые последствия вплоть до полной остановки работ по проекту. Объем резервов должен согласовываться с текущей оценкой рисков. При использовании части средств для борьбы с проявившимся риском объем резервов должен быть пересмотрен и при необходимости увеличен.
Эффективное использование резервов требует определенной подготовки. Необходимо готовить резервные планы, заранее учитывать сложность ввода новых специалистов в проект. Например, желательно подготовить в компании резерв сотрудников, знакомых с проектом хотя бы в общих чертах. Это могут быть, например, сотрудники, привлекавшиеся к рецензированию материалов проекта.
Использование формальных показателей (метрик) для управления рисками. Уже упоминавшиеся метрики — весьма действенное средство своевременного выявления и мониторинга рисков. Имеется в виду, что метрики должны быть определены заранее и использоваться для формирования предупреждений. При выходе за предустановленные пределы значений (например, если первоначально запланированный объем кода превышен на 10%) или при выполнении особых условий (к заданному сроку не найден квалифицированный персонал) автоматически формируется предупреждение для управляющего персонала.
Определять критерии формирования таких предупреждений можно с помощью различных методов анализа временных рядов для “долгоиграющих” рисков. Формирование критериев в любом случае требует определенного опыта работы по управлению рисками и набора предварительной статистики.
В качестве показателей обычно используются метрики, связанные с бюджетом, размерами системы, ходом выполнения графика работ, количеством обнаруживаемых дефектов и скоростью их устранения.
Непрерывное управление рисками. Мы уже говорили об этом, но все же повторим. Чтобы управление рисками было действительно эффективным, надо осуществлять его на непрерывной основе в течение всего жизненного цикла проекта. Повторный анализ рисков позволяет уточнить оценки вероятности проявления и последствий. Регулярные отчеты о наиболее существенных рисках позволяют повысить качество управления проектами.
Отслеживание внешних зависимостей. Внешние причины, скажем, задержки поставки отдельных программных компонентов или оборудования, также часто выступают как весьма приоритетные риски проекта. Для их снижения требуются специальные меры, такие, как регулярный мониторинг хода разработки у поставщика или поиск альтернативных поставщиков. Кроме того, руководство фирмы должно понимать, что эти риски находятся вне компетенции участников проекта.
Этапы освоения
На пути к освоению процесса управления рисками команды обычно проходят через определенные стадии. Понимание того, на какой стадии вы находитесь, поможет выбрать ориентиры для следующего шага.
Стадия 1. Решение проблем
Эта стадия соответствует исходному положению дел. Люди заняты решением уже возникших проблем, о будущем никто не думает. С рисками, даже известными, никто ничего не делает, пока они не превращаются в реальные проблемы. Это связано, в частности, с тем, что даже руководители не уверены в своих оценках вероятности проявления риска и его последствий. Поскольку руководство не поощряет сообщения о рисках, большинство о них и не упоминает. Стандартные процедуры если и существуют, то только для преодоления рисков, ставших проблемами.
Стадия 2. Снижение последствий
Это стадия соответствует началу внедрения управления рисками. Руководство проекта уже само спрашивает: “А что может не получиться? Какие могут возникнуть проблемы? А какие будут последствия?”. Команда понимает, что такое риск. Но еще не всегда хватает опыта для того, чтобы обсудить все необходимые детали. На этой стадии руководство обычно предпочитает формировать резервные планы, чтобы использовать их, если основной план провалится.
Стадия 3. Предотвращение рисков
На этой стадии управление рисками перестает быть прерогативой руководства и становится всеобщим процессом. Руководство понимает, что управлением рисками нельзя заниматься в одиночку, к этому процессу все больше привлекается команда, а затем и заказчик. Если для предыдущей стадии характерно внимание к затратам и планам (а это обычно только внешние симптомы технических рисков), то сейчас упор делается на выявление технических источников риска. Управление рисками превращается из пассивного, основанного на ожидании внешних событий, в активный процесс выявления потенциальных рисков. Члены команды приобретают опыт в выявлении рисков, но, возможно, еще затрудняются с количественными оценками.
Стадия 4. Предвосхищение рисков
На четвертой стадии происходит переход от качественных оценок и методов к количественным. При этом начинают использоваться метрики, позволяющие обнаружить проявления предсказуемых рисков. Члены команды и заказчик используют количественные оценки для правильного определения приоритетов. Используются специальные меры для снижения вероятности или тяжести последствий риска, а также для выбора альтернативных решений (сам выбор упрощается при наличии количественных оценок). С такой системой раннего предупреждения ожидаемые проблемы исключаются с помощью предварительных коррекций.
Стадия 5. Учет возможностей
Пожалуй, настало время заняться и положительными рисками. На этой стадии управление рисками позволяет управлять будущим. Риски теперь воспринимаются как шанс выполнить работу лучше, чем планировалось, и уложиться в меньшую сумму затрат. В управление рисками, как в борьбу за качество, включились все. Профессиональный уровень позволяет всем участвовать в обсуждениях и предлагать собственные решения. Участники проекта понимают, что не все заранее известно, что существуют оптимистичные и пессимистичные сценарии. Они осознают, что каждый их выбор ведет к определенным затратам, это помогает им выбирать лучшее решение. Управление рисками выходит за пределы исходной задачи и становится мощным оружием.
В заключение осталось пожелать всем успешно освоить все перечисленные стадии. А чтобы наверняка этого добиться — управляйте рисками!
Сведения об авторах:
Автор работает в дирекции по консалтингу и методологии создания программного обеспечения информационных систем компании ООО ИК СИБИНТЕК, г. Москва.
Закис Алексей – главный специалист управления методологии создания и сопровождения программного обеспечения.
Если Вас заинтересовал данный материал, то можете присылать вопросы по адресу: rational@sibintek.ru, www.sibintek.ru.
Виртуальные VPS серверы в РФ и ЕС
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
