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

1. Имеется перечень рисков. В этот перечень включены все главные риски проектов разработки программного обеспечения, а также риски, присущие исключительно данному проекту. Риски эти по природе своей причинные (то, что вызовет ужасные результаты, а не то, что само является ужасным результатом).

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

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

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

4. Имеются цели и оценки проекта, и они никогда не совпадают. Цели могут быть на уровне «нанопроцентной даты» или рядом с ней, а оценки должны быть гораздо более консервативными. Если целью данного проекта является поставка продукта через 12 месяцев, то оценка должна планировать поставку хотя бы месяцев через восемнадцать. В любом случае, конкретный уровень доверия, который связан с любым обстоятельством, должен быть указан диаграммой неопределенности.

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

6. Для каждого риска существует план реагирования и план ослабления. Действия по реагированию на риски включены в иерархическую структуру работ в качестве возможных действий. Действия по ослаблению риска включены в ИСР в качестве необходимых и своевременно осуществляются прежде, чем может возникнуть самая ранняя необходимость ввести в действие план реагирования.

7. Оценивается подверженность каждому из рисков.

8. Существуют количественные оценки выгоды по проекту. После завершения проекта обязательно измеряется реализованная выгода. Имеется упорядоченная по их выгодности (ценности) система компонентов создаваемой системы, используемая как входные данные при планировании версий.

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

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