5.2 Планирование реагирования на риски

Привет, Вы узнаете о том , что такое планирование реагирования на риски, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое планирование реагирования на риски, риски , настоятельно рекомендую прочитать все из категории Управление разработкой программных IT проектов.

планирование реагирования на риски — это процесс разработки путей и определения действий по увеличению возможностей и снижению угроз для целей проекта. Данный процесс начинается после проведения качественного и количественного анализа рисков.

Запланированные операции по реагированию на риски должны соответствовать серьезности риска, быть экономически эффективными в решении проблемы, своевременными, реалистичными в контексте проекта и согласованными со всеми участниками.

Согласно [3] возможны четыре метода реагирования на риски: ■ Уклонение от риска (risk avoidance).

• Передача риска (risk transference).
• Снижение рисков (risk mitigation).
• Принятие риска (risk acceptance).

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

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

Снижение рисков предполагает понижение вероятности и/или последствий негативного рискованного события до приемлемых пределов. Принятие предупредительных мер по снижению вероятности наступления риска или его последствий часто оказываются более эффективными, нежели усилия по устранению негативных последствий, предпринимаемые после наступления события риска. Например, раннее разрешение архитектурных рисков снижает потери при досрочном закрытии проекта. Или регулярная ревизия поставок заказчиком может снизить вероятность риска его неудовлетворенности конечным результатом. Если в проектной команде высока вероятность увольнения сотрудников, то введение на начальной стадии в проект дополнительных (избыточных) людских ресурсов снижает потери при увольнении членов команды, поскольку не будет затрат на «въезд» в проектный контекст новых участников.

И, наконец, принятие риска означает, что команда проекта осознанно приняла решение не изменять план управления проектом в связи с риском или не нашла подходящей стратегии реагирования. Мы вынуждены принимать все «неизвестные риски».

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

Важно помнить о вторичных рисках (Secondary Risks), возникающих в результате применения реагирования на риски, которые тоже должны быть идентифицированы, проанализированы и при необходимости включены в список управляемых рисков.

Главные риски программных проектов и способы реагирования

Мой список из пяти главных причин провала программных проектов — следующий:

• Требования заказчика отсутствуют / не полны / подвержены частым изменениям.
• Отсутствие необходимых ресурсов и опыта.
• Отсутствие рабочего взаимодействия с заказчиком.
• Неполнота планирования. «Забытые работы».
• Ошибки в оценках трудоемкостей и сроков работ.

Это звучит банально, но сколько бы раз об этом не твердили ранее, по-прежнему, приходится сталкиваться с программными проектами, в которых отсутствуют какие-либо определенные цели и требования. Об этом говорит сайт https://intellect.icu . Цитата из жизни: «Была бы разработана хорошая программа, а какой процесс автоматизировать с ее помощью, мы найдем». К этому можно добавить только одно: «Когда человек не знает, к какой пристани он держит путь, для него никакой ветер не будет попутным» (Сенека Луций Аней, философ, 65-3 до н.э.)

К часто упускаемым требованиям можно отнести:

• Функциональные
• Программы установки, настройки, конфигурации.
• Миграция данных.
• Интерфейсы с внешними системами.
• Справочная система.
• Общесистемные
• Производительность.
• Надежность.
• Открытость.
• Масштабируемость.
• Безопасность.
• Кросплатформенность.
• Эргономичность.

Как правило, эти требования «всплывают» при подготовке и проведении приемо-сдаточных испытаний и могут сильно задержать проект по времени и увеличить трудозатраты на его реализацию. Чтобы этого не происходило, следует достигать соглашения с заказчиком по всем перечисленным пунктам предпочтительнее еще на стадии инициации проекта. Например, если требования портируемости продукта на разные аппаратно-программные платформы нет, то это целесообразно включить в раздел концепции с допущениями проекта.

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

• Переоценка проекта каждый раз, когда требования добавляются / изменяются (уклонение).
• Итерационная разработка. Контракт с компенсацией затрат на основе «Time & Materials» (передача риска Заказчику).
• Учет в оценках трудоемкости и сроков возможности роста требований, например, на 50% (резервирование риска).

И еще, при сборе требований следует соблюдать принцип минимализма Вольтера: «Рассказ закончен не тогда, когда в него нечего добавить, а тогда, когда из него нечего больше выкинуть». Для большинства программных продуктов применим принцип Парето: 80% ценности продукта заключены лишь в 20% требований к нему.

Если у нас в проекте недостаточно квалифицированных специалистов, то мы можем снизить последствия этого риска, применив следующие действия:

• Привлечь экспертов-консультантов на начальных этапах.
• Учитывать в оценках трудоемкости издержки на обучение сотрудников.
• Уменьшать потери от текучести кадров, привлекая на начальном этапе избыточное число участников.
• Учесть в оценках «время разгона» для новых сотрудников.

Для установления открытых и доверительных отношений с заказчиком, необходимо предпринимать следующие шаги:

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

При планировании работ по проекту часто «забывают»:

• Обучение.
• Координация работ.
• Уточнение требований.
• Управление конфигурациями.
• Разработка и поддержка скриптов автосборки.
• Разработка автотестов.
• Создание тестовых данных.
• Обработка запросов на изменения.

И еще. Не стоит надеяться, что участники проекта будут каждую неделю по 40 часов работать именно над вашим проектом. Есть множество причин, по которым они не смогут работать по проекту 100% своего времени. К списку наиболее распространенных причин этого относятся:

• Сопровождение действующих систем.
• Повышение квалификации.
• Участие в подготовке технико-коммерческих предложений.
• Участие в презентациях.
• Административная работа.
• Отпуска, праздники, больничные.

Рекомендация, планировать, что разработчики, которые назначены в ваш проект на 100% будут реально работать над вашими задачами в среднем от 24 до 32 часов в неделю.

Ошибкам в оценках трудоемкости и сроков проекта и походам, которые позволяют их минимизировать, буде посвящена следующая лекция.

Управление проектом, направленное на снижение рисков

На стадии инициации проекта оценка его трудоемкости имеет погрешность от -50% до +100% [4]. Это, если оценка хорошая! А если плохая, то неопределенность, а, следовательно, и риски сорвать сроки и превысить плановую трудоемкость, могут быть в разы больше. Если не прилагать специальных усилий этот «дамоклов меч» неопределенности будет висеть над проектом на всем его протяжении (Рисунок 31).

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

Ранее мы уже говорили о том, что 80% ценности разработки обусловлена лишь 20% требований к продукту, без реализации которых продукт для заказчика становится просто ненужным. Остальные требования, как правило, так называемые «украшательства», от части которых заказчик, как правило, может отказаться, чтобы получить проект в срок. Поэтому следует в первую очередь реализовывать ключевые функциональные требования.

Но есть и еще архитектурные риски. Известно, что закон Парето применим и к потреблению вычислительных ресурсов: 80% потребления ресурсов (время и память) приходится на 20% компонентов. Поэтому, необходимо реализовывать архитектурно-значимые требования так же в первую очередь, создавая «представительный» прототип будущей системы, который «простреливает» весь стек, применяемых технологий. Прототип позволит измерить и оценить общесистемные свойства будущего продукта: доступность, быстродействие, надежность, масштабируемость и проч. (Рисунок 32)

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

Рисунок 31. Неопределенность не уменьшается, если управление не направлено на раннее разрешение рисков

Рисунок 32. Определение приоритетов требований на первые итерации проекта

Управление, нацеленное на снижение рисков, позволяет существенно снизить неопределенность на ранних стадиях проекта (Рисунок 33).

Рисунок 33. Управление, нацеленное на снижение рисков, позволяет уменьшать неопределенность

Проработка ключевых функциональных требований и детальное планирование их реализации позволяет уменьшить разброс начальных оценок, примерно, в 2 раза: от -30% до +50%. Детальное проектирование и разработка прототипа будущей системы позволит получить еще более точные оценки общей трудоемкости: от -10% до +15%.

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

Если с заказчиком не удается найти взаимоприемлемое решение при первоначальной оценке проекта, то разумно попытаться договориться о выполнении проекта в 2 этапа с самостоятельным финансированием:

1. Исследование. Бизнес-анализ, уточнение требований, проектирование и прототипироание решения, уточнение суммарных оценок трудозатрат. Эта работа, как правило, требует 10 % общих трудозатрат и 20% времени всего проекта.
2. Непосредственно реализация. Если уточненные оценки трудозатрат окажутся приемлемыми для заказчика.

С вменяемыми заказчиками это часто удается.

Мониторинг и контроль рисков

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

Мониторинг и управление рисками — это процесс идентификации, анализа и планирования реагирования на новые риски, отслеживания ранее идентифицированных рисков, а также проверки и исполнения операций реагирования на риски и оценка эффективности этих операций.

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

Мониторинг и управления рисками включает в себя следующие задачи:

• Пересмотр рисков.
• Аудит рисков.
• Анализ отклонений и трендов.

Пересмотр рисков должен проводиться регулярно, согласно расписанию. Управление рисками проекта должно быть одним из пунктов повестки дня всех совещаний команды проекта. Неплохо начинать каждый статус митинг с вопроса: «Ну и какие еще неприятности нас ожидают?» Идентификация новых рисков, и пересмотр известных рисков происходит с использованием процессов, описанных ранее.

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

Тренды в процессе выполнения проекта подлежат проверке с использованием данных о выполнении. Для мониторинга выполнения всего проекта могут использоваться анализ освоенного объема и другие методы анализа отклонений проекта и трендов (см. Лекция 8. Реализация проекта). На основании выходов этих анализов можно прогнозировать потенциальные отклонения проекта на момент его завершения по показателям стоимости и расписания. Отклонения от базового плана могут указывать на последствия, вызванные как угрозами, так и благоприятными возможностями.

Выводы

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

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

Цели управления рисками проекта — снижение вероятности возникновения и/или значимости воздействия неблагоприятных для проекта событий.

Главные причины провала программных проектов:

• Требования заказчика отсутствуют / не полны / подвержены частым изменениям.
• Отсутствие необходимых ресурсов и опыта.
• Отсутствие рабочего взаимодействия с заказчиком.
• Неполнота планирования. «Забытые работы».
• Ошибки в оценках трудоемкостей и сроков работ.

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