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

Любая проектная деятельность сопряжена с рисками. Высший пилотаж — управлять ими так, чтобы клиент отмечал только хорошее :) Это одна из ключевых областей проектной деятельности, и ценность ее трудно преувеличить.

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

Оценка рисков проекта происходит минимум дважды (а также каждый раз при внесении существенных изменений в скоуп). Первый раз — при черновой оценке проекта или создании тз на сайт. Второй — перед контрактацией.

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

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

Что такое риск

Риск — это незапланированное событие, влияющее на срок, стоимость или скоуп проекта по разработке системы.

Вероятность

Риск характеризуется вероятностью наступления. Она почти всегда рассчитывается экспертно и грубо: обычно уровня оценки от ? до ? достаточно. Есть риски с вероятностью единица, например: изменение скоупа проекта происходит всегда, но объем бывает разный. Поэтому это риск, а не элемент плана создания web-сайта.

Типы рисков

Мы делим риски на два широких класса: наши и клиентские.

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

Напротив, за собственные риски отвечать можем только мы. К примеру, такой типичный случай, как увольнение ведущего разработчика проекта.

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