7. Документирование действий по рискам

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

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

Ключ к успеху – удобная для всех участников система документации! При создании таких документов полезно держать в виду следующие два вопроса: «Если меня завтра не станет, то может ли кто-либо разобраться в этом?» и «Можно ли заполнить эту форму или отчет в конце рабочего дня в пятницу?» Если ответом на второй вопрос будет: «Можно, но плохо именно в этот момент», то плохо будет всегда, так что это верный знак того, что надо что-то менять в подходе к составлению таких отчетов и документов.

Практический подход к документированию управления рисками руководствуется следующими принципами:

1. Документирование – это непрерывный процесс

2. У документации различные пользователи: она дает исторический след проекта, дает сводки «усвоенных уроков» и функционирует как механизм коммуникации между прикосновенными лицами.

3. Документация должна быть: текущей, точной и полной, ясной и лаконичной.

4. Руководствуйтесь здравым смыслом при документировании.

5. Распространяйте свою документацию и читайте документацию других.

8. Заключительное оценивание рисков

По завершении программного проекта очень полезно провести заключительное оценивание рисков в нем как часть ретроспективного обзора (post-mortem review) выполненного проекта, как успешного, так и неуспешного.

Такая оценка проводится по следующим направлениям:

1. Затраты, график, производительность: Каковы «усвоенные уроки»? Удовлетворен ли заказчик? Каковы последствия данного проекта для будущих проектов и будущего организации?

2. Признание и награждение отличившихся участников проекта.

3. Оценивание степени достижения целей проекта.

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

В зависимости от качества таких оцениваний, могут создаваться или сокращаться будущие риски в новых проектах, меняться в ту или иную сторону образ и репутация данной организации-разработчика. Такая работа способствует созданию возможностей на будущее через возможные усовершенствования в контракте, позиционирование данной организации как разработчика и улучшение связи с общественностью (public relations).

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

деловые риски – несут вероятность как выигрыша, так и потерь – это нормальные риски ведения дела;

чистые риски – несут вероятность только потерь – часто могут быть застрахованы страховыми компаниями;

внешние события – вне контроля или влияния со стороны разработчиков:

• непредсказуемые – регуляторные, природные катаклизмы, окружающая среда, общественный интерес;

• предсказуемые – колебания рынка, валют, инфляция, налогообложение;

внутренние события – в рамках контроля или влияния разработчиков:

• финансовые – затраты на запуск, бюджет заказчика, точность требований, ценовая политика, время выхода на рынок, тип контракта, движение наличности;

• по графику – ползучие требования, кадры, реалистичность, доступность оборудования и технологий, трудности запуска, каскадные задержки, неадекватное планирование;

• технические – экспертиза, зрелость технологии, размер и сложность, требования интеграции/инсталляции, настройка на потребителя, сопровождение;

• юридические – неоднозначность в контракте, невозможность выполнить, право копирования, торговые секреты, патенты, лицензии.

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

Табл. 17. Риски, контролируемые разработчиками

	Проявления	Инструменты
Финансовые	Потенциальные денежные приобретения Потенциальные денежные потери Профиль движения наличности Будущие потенциал и вероятность дела Требуемые вложения и отдача	Результат в ожидаемом денежном выражении (EMV) Анализ безубыточности (break-even) Доходность продаж (ROS) Возврат от инвестиций (ROI) Доходность активов (ROA) Анализ движения наличности (cash flow) Анализ затрат ЖЦ (LCC) Экономическая добавленная ценность (EAV)
График	Реалистичность сроков Загрузка ресурсов Доступность ресурсов Гибкость требований	Экспертное суждение Сетевой анализ (PERT, CPM, PDM) Анализ диаграмм Гантта Анализ диаграмм этапов
Технические	Наличие внутренних экспертов Наличие внешних экспертов Знание технологии и предмета Доступ к обучению Сложность Зрелость технологии	Экспертное суждение Исторические данные Анализ через деревья решений
Юридические	Нарушения контракта и его прекращение Нарушения патентов Нарушение прав копирования Раскрытие или кража торговых секретов Заявки контракта	Специальные статьи контракта Гарантии Страхование Арбитраж Судебное разбирательство

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

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

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

3. Чрезмерное давление графика – этапы поставок спланированы с превышением нагрузки на исполнителей.

4. Некомпетентность руководства – no comment

5. Неадекватность оценки затрат – затраты на разработку оценены неверно.

6. Синдром «серебряной пули» – мнение, что существует одно решение для всех проблем в проекте.

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

8. Низкое качество – no comment

9. Низкая производительность труда – фактическая производительность труда оказалась меньше расчетной

10. Отмененные проекты – проект прекращен по не зависящим от исполнителей причинам, что очень демотивирует команду для следующих проектов.

В Табл. 18 представлены данные из источников США по проценту проектов, подверженных самым распространенным общим рискам в ПО.

Табл. 18. Самые распространенные общие риски в ПО

Системы управления информацией			Системное программное обеспечение
80	Ползучесть требований пользователя		70	Долгосрочный график (>3 лет)
65	Чрезмерное давление графика		65	Неадекватность оценки затрат
60	Низкое качество		60	Избыточный документооборот
55	Превышение затрат		50	Подверженные ошибкам модули
50	Неадекватное конфигурационное управление		35	Отмененные проекты
Программное обеспечение военного назначения			Программное обеспечение по контракту
90	Избыточный документооборот		60	Высокие затраты на сопровождение
85	Низкая производительность труда		50	Трения между подрядчиком и клиентом
75	Долгосрочный график (>3 лет)		45	Ползучесть требований пользователя
70	Ползучесть требований пользователя		30	Неожиданные критерии приемки
45	Неиспользуемое программное обеспечение		20	Право собственности на программное обеспечение и поставки
Программное обеспечение пользователя			Коммерческое программное обеспечение
80	Непередаваемые приложения		70	Неадекватная документация пользователя
65	Скрытые ошибки		55	Низкая удовлетворенность пользователя
60	Несопровождаемое программное обеспечение		50	Избыточное время выхода на рынок
50	Избыточные приложения		45	Вредные действия конкурентов
20	Право собственности на программное обеспечение и поставки		30	Расходы на судебные разбирательства

Типичные ответные стратегии на некоторые их этих рисков состоят в следующем.

Ползучесть требований пользователя: прототипирование, совместное проектирование приложения (Joint Application Development – JAD), информационная инженерия (Information Engineering – IE).

Давление графика, долгосрочный график, время выхода на рынок: технологии планирования, технологии для сокращения графика (готовые модули, повторное использование компонентов, системы САПР, объектно-ориентированные анализ, проектирование и средства кодирования, информационная инженерия и быстрая разработка приложений), структурный анализ, инспекции и обзоры.

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

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

Высокая стоимость сопровождения: анализаторы структурной сложности, средства реструктуризации (для языков COBOL и C), средства обратного восстановления (reverse engineering), анализ модулей с ошибками и удаление их.

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

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

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

Низкая удовлетворенность пользователя: GUI, эксперты по интерфейсу, улучшение пользовательской документации, улучшение функций подсказки (HELP).

Трения между заказчиком и клиентом: партнерство, управление рисками в команде.

Юридические проблемы: обсуждать проблемы на переговорах, нанимать юристов, понимающих вопросы ПО, прибегать к посредничеству до арбитража и спора в суде.