|
"Готовность - это все." - Гамлет, V:ii:215
Проект, как и жизнь, имеет свойство неопределенности. Риски выявляются для их упреждения и снижения, если это возможно,
или для того, чтобы быть готовым к неблагоприятным ситуациям.
Риск управляет планами итераций. В цели каждой итерации входит снижение конкретных рисков. Список рисков периодически
пересматривается для оценки эффективности используемых методов их снижения. Затем вносятся соответствующие коррективы в
план проекта и последующие планы итераций.
Ключ к эффективному управлению рисками - не ждать его осуществления (и превращения в дефект или неудачу) для
того, чтобы потом решить, как исправлять ситуацию. Как изменение курса на несколько градусов при трансконтинентальном
полете кардинально влияет на место прибытия самолета, ранее управление рисками имеет меньшую трудоемкость, чем выход из
уже наступившей нежелательной ситуации.
Существует три основных стратегии [BOE91]:
-
Исключение риска. Проект реорганизуется так, чтобы риск исчез.
-
Передача риска. Проект реорганизуется так, чтобы риск передался кому-нибудь другому (заказчик, вендор, банк)
или был перенесен на что-то другое (другой элемент). Это частный случай стратегии исключения риска.
-
Принятие риска. Принятие вероятности возникновения нежелательной ситуации. Наблюдайте за симптомами риска и
определите последовательность действий в случае возникновения предвиденных проблем.
Если вы решите принять риск, его можно снизить, т.е. принять меры по минимизации его влияния.
Важно различать прямые и косвенные риски. Прямой риск - риск, поддающийся контролю некоторой степени. Косвенные риски
не поддаются контролю.
Хотя косвенные риски не стоит полностью игнорировать, выявление таких рисков не несет особой пользы: раз с ними ничего
нельзя сделать, озабоченность такими рисками вряд ли что-то принесет. Хотя конец света может наступить завтра,
он также может и не наступить, и если это будет так, то лучше войти в завтрашний день с готовой работой!
Иногда косвенные риски могут быть на самом деле скрытыми прямыми. Например, проект может зависеть от какого-то внешнего
поставщика. Риск неполучения товара может показаться косвенным, но, имея план действий в непредвиденных
обстоятельствах, можно фактически управлять риском: можно воспользоваться услугами других поставщиков или разработать
необходимую функциональность самостоятельно. В большинстве случаев есть больше возможностей по управлению рисков, чем
нам кажется!
При столкновении с косвенным риском нужно либо найти способы получения контроля над риском, либо зафиксировать его
выявление и продолжить работу. Переживать о том, что не может быть изменено, не имеет смысла.
Организация
-
Достаточно ли усилий вкладывается в проект (управление, тестирование, контроль качества; возможно, внешние
участники)?
-
Является ли этот проект рекордно большим для данной организации?
-
Есть ли четко регламентированный процесс разработки? Методы сбора требований и управления?
Финансирование
-
Достаточно ли денежных средств для завершения проекта?
-
Выделены ли средства на обучение и роли наставников для менее опытных?
-
Есть ли ограничения по бюджету, например, фиксированная цена (и отмена проекта, если он не укладывается в бюджет)?
-
Корректны ли оценки затрат?
Штат
-
Достаточно ли людей доступно?
-
Имеют ли они соответствующие навыки и опыт?
-
Работали ли они вместе ранее?
-
Верят ли они в успех проекта?
-
Доступны ли представители пользователей для контроля?
-
Доступны ли эксперты в предметной области?
График
-
Прагматический ли график?
-
Можно ли менять содержание проекта для соблюдения графика?
-
Насколько критичен график?
-
Есть ли время на реализацию "соответствующим образом"?
-
Что будет, если конкуренты выйдут на рынок первыми?
-
Что будет, если финансирование прекратится (вариант: что может гарантировать "адекватное финансирование")?
-
Превышает ли прогнозируемая стоимость проекта прогнозируемые затраты? (учитывайте также альтернативные способы
вложения денег и стоимость капитала).
-
Что если не удастся заключить договор м ключевыми поставщиками?
-
Есть ли мера успешности проекта?
-
Оговорены ли индикаторы успешности проекта?
-
Стабильны ли (относительно) требования? Правильно ли они интерпретируются?
-
Являются рамки проекта неизменными, или возможно их расширение?
-
Являются ли сроки разработки маленькими и негибкими?
-
Существуют ли успешные решения на основе выбранной технологии?
-
Разумно ли решение о повторном использовании наработок?
-
Рабочий продукт должен быть опробован в одном месте перед тем, как его можно будет использовать в других
местах.
-
На стабилизацию компонента, позволяющую использовать его в других местах без значительных изменений, может
уйти несколько выпусков.
-
Обоснован ли объем транзакций в требованиях?
-
Корректны ли оценки частоты транзакций? Являются ли они слишком оптимистичными?
-
Обоснованы ли объемы данных? Могут ли они храниться на компьютерах обычных размеров или, если в требованиях
подразумевается использование более крупных систем, смогут ли последние обеспечить хранение данных таких объемов?
-
Имеются ли необычные или нетривиальные технические требования, при выполнении которых команда столкнется с
проблемами необычного рода?
-
Зависит ли успех от новых или неиспытанных продуктов, услуг или технологий, нового или не доказавших свою
пригодность аппаратного, программного обеспечения и методик?
-
Имеются ли интерфейсы с внешними системами, включая системы вне предприятия? Имеются ли уже готовые
интерфейсы?
-
Имеются ли жесткие требования по безопасности и надежности (например, "система не может сбоить")?
-
Имеют ли пользователи опыт работы с системами подобными разрабатываемой?
-
Увеличивается ли риск из-за большого размера или сложности приложения, либо новизны технологии?
-
Требуется ли поддержка национальных языков?
-
Возможно ли вообще спроектировать, реализовать и использовать систему? Некоторые систему могут оказаться настолько
большими или сложными, что достигнуть их корректной работы просто не получится.
-
Зависит ли проект от других (параллельных) проектов?
-
Зависит успех продукта от имеющихся продуктов или разрабатываемых третьей стороной компонентов?
-
Зависит ли успех продукта от успеха внедрения инструментов разработки (программы для проектирования, компиляторы и
т.д.), методов реализации (ОС, СУБД, механизм взаимодействия процессов и т.д.). Есть ли у вас резервный план на
случай отказа от этих технологий?
Эмпирически выяснено, что 85% рисков прямо или посредственно влияют на график, а следовательно и на затраты. Только
около 5% рисков влияют исключительно на затраты. Остальная часть рисков влияет на качество и т.п.
Если у проекта жесткие сроки, продвигайтесь к конечному сроку плавно инкрементальными выпусками. Не отказывайтесь от
разбиения продукта на несколько поставок в надежде на то, что это поможет уложиться в график.
Некоторые проекты имеют очень строгие графики. Например, это может быть ПО для подсчета голосов в ночь после
голосования. Продукт может стать устаревшим по сравнению с продуктами конкурентов: они могут выйти на рынок в то время,
когда ваш продукт готов только наполовину. В этом случае продолжение разработки может просто потерять смысл. Однако,
такие критические сроки выполнения очень редки. Обычно задержки влияют лишь на затраты.
Предлагайте график, соответствующий лучшим оценкам, с некоторым запасом на случай непредвиденных обстоятельств.
график = оценка + запас
Некоторые советуют выбирать график, соответствующий резервному плану, но это слишком пессимистично, т.к. вероятность
исполнения сразу всех рисков очень мала.
Риски, влияющие на график, внедрены в средства оценки и расчета затрат. Например, в модели COCOMO многие из факторов
затрат, такие как:
-
сложность (cplx)
-
ограничения по времени (time)
-
ограничения дисковое пространство (stor)
-
опыт (Vexp)
-
доступность хороших инструментов (tool)
-
жесткость графика (sced)
на самом деле являются факторами риска.
В число более сложных методов управления рисками входит имитационное моделирование методом Монте-Карло, в котором
имитируется большое число "сценариев" для расчета рисков проекта и непредвиденных обстоятельств [KAR96].
|
