Понимание управления рисками при разработке программного обеспечения

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

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

Что такое риск в разработке программного обеспечения?

Проще говоря, риск – это потенциальная проблема. Это действие или событие, которое может поставить под угрозу успех проекта. Риск – это возможность понести убытки, и общая подверженность рискам конкретного проекта будет учитывать как вероятность, так и размер потенциальных убытков.
Антикризисное управление редко бывает эффективными. Выявление и агрегирование рисков – единственный метод прогнозирования для определения вероятности того, что в проекте разработки возникнут незапланированные или недопустимые события. К ним относятся прекращения, прерывания, задержки графика, недооценка стоимости и перерасход ресурсов проекта.

Что такое управление рисками?

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

Управление рисками включает в себя следующие действия:

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

Выявление и классификация рисков

Большинство проектов по разработке ПО рискованны из-за множества потенциальных проблем, которые могут возникнуть. Опыт других проектов может помочь менеджерам классифицировать риски. Здесь важны не элегантность или диапазон классификации, а, скорее, точное определение и описание всех реальных угроз для успеха проекта. Простая, но эффективная схема классификации состоит в том, чтобы распределить риски по областям воздействия.

Пять типов рисков при управлении программными проектами

Для большинства проектов мы можем выделить пять основных областей воздействия риска:

• Новые, непроверенные технологии
• Пользовательские и функциональные требования
• Архитектура приложений и системы
• Пользовательский опыт
• Организационная деятельность

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

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

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

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

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

План управления рисками

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

Мониторинг и нивелирование последствий

Чтобы быть эффективным, мониторинг рисков должен быть неотъемлемой частью большинства проектных мероприятий. По сути, это означает частую проверку во время встреч по проекту и критических событий.

Действия при мониторинге:

• Включите раздел «управление рисками» в регулярные отчеты
• Пересматривайте планы рисков после любых существенных изменений в графике проекта.
• Регулярно пересматривайте и изменяйте приоритеты рисков, исключая те, которые имеют наименьшую вероятность.
• Проводите мозговой штурм по потенциально новым рискам после изменений в расписании или объеме проекта.
• Берите из плана управления рисками соответствующие меры по смягчению последствий риска (при его возникновении).

Варианты нивелирования

1. Принять: признать, что на проект влияет риск. Примите четкое решение принять риск без каких-либо изменений в проекте. Утверждение руководства проектом здесь обязательно.
2. Избегать: скорректируйте объем проекта, график или ограничения, чтобы минимизировать влияние риска.
3. Контролировать: примите меры, чтобы минимизировать воздействие или уменьшить усиление риска.
4. Передать: осуществите организационный сдвиг в подотчетности, ответственности или полномочиях другим заинтересованным сторонам, которые примут на себя риск.
5. Продолжить мониторинг: мониторинг среды проекта на предмет потенциально увеличивающегося воздействия риска, Имеет смысл для незначительных рисков

Коммуникации

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

Резюме

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

• Всегда будьте дальновидными в отношении управления рисками. В противном случае команду проекта будет штормить от одного кризиса к другому.
• Используйте контрольные списки и сравните с аналогичными предыдущими проектами.
• Расставьте риски по приоритетам, ранжируя каждый в соответствии с серьезностью воздействия.
• Составьте список ТОП-20 рисков для вашего проекта. Как и большинство менеджеров проектов, вы, вероятно, сможете повторно использовать этот список в следующем проекте!
• Внимательно следите за появлением рисков, встречаясь с ключевыми заинтересованными сторонами, особенно с отделом маркетинга и заказчиком.
• Если это возможно, декомпозируйте крупные риски на более мелкие, легко распознаваемые и легко управляемые.
• Поощряйте заинтересованные стороны думать проактивно и сообщать о рисках на протяжении всего проекта.

P.S. Есть вопросы по управлению процессами и командами разработки в своей компании?
Тогда вам сюда→

Источники→