Учебный пример. Выделение рисков

Вернемся к учебному примеру “Система бронирования билетов для авиакомпании”.

Выделим некоторые возможные риски.

	Наименование риска	Комментарий
	Не успеем сдать проект во время	Из-за неправильной организации работ затратим больше времени, чем заявлено в контракте
	Не хватит квалификации персонала	При создании продукта используется новая технология (JNL), персонал с ней не работал и может не разобраться
	Один из членов команды заболеет	Команда не многочисленна и отсутствие одного из членов команды ведет задержке в работах
	Заказчик изменит требования	В данный момент требования согласованы с заказчиком и утверждены, но в процессе работы заказчик может захотеть добавить в решение новую функциональность
	Авария на подстанции, отключение электричества	Потеряем время, пока авария будет устраняться.
	Отключат доступ к Интернету	Ухудшится возможность быстрого получения необходимых сведений, пропадет электронная почта и другие средства коммуникации
	Заказчик вовремя не оплатит счета	Задержка в покупке необходимого оборудования
	Из-за необнаруженной вовремя ошибки система нанесет урон заказчику	На время устранения ошибки пассажиры не смогут заказывать билеты через систему. Потребуется “ручная” работа персонала. Компания потеряет возможных клиентов и часть прибыли.
	На стороне заказчика нет заявленной в требованиях аппаратуры	Не сможем адекватно развернуть систему
	Не сможем подобрать необходимые кадры	Придется совмещать роли

Мы выделили не так уж и много рисков, однако можно заметить, что они происходят из самых разных областей и связаны с людьми (риск №3), с процессами (риски №1, №8, №10), с технологиями (риск №2), с внешними условиями (риски №5, №6), с заказчиком (риски №4, №7, №9). Помимо представленных риски могут иметь и другие источники.

Далее MSF рекомендует для каждого риска представить формулировку – выражение на естественном языке причинно-следственной связи между реально существующим фактором проекта и потенциально возможным, еще не случившимся событием или ситуацией. Первая часть формулировки риска называется условием (condition) и содержит описание существующего фактора или особенности проекта, которые, по мнению проектной группы, могут сделать результат проекта убыточным либо же сократить получаемую от проекта прибыль. Вторая часть формулировки риска называется (по)следствием (consequence). Она описывает ту нежелательную ситуацию, которой следует избежать.

В качестве примера представим формулировки некоторых выявленных выше рисков.

Первопричина	Условие	Последствие	Приносимый ущерб
Нехватка кадров	Один из членов команды заболеет	Функции заболевшего придется передать другому	Потери времени
Форс-мажор	Авария на подстанции, отключение электричества	Потеряем время, пока авария будет устраняться	После устранения аварии придется увеличить нагрузку, чтобы наверстать потери времени
Организация работы	Не сможем подобрать необходимые кадры	Участникам придется совмещать роли	Дополнительные трудозатраты, снижение качества продукта, увеличение времени разработки решения

5.5. Модель процессов MSF for Agile Software Development [2]

Модель процессов MSF представляет общую методологию разработки и внедрения IT- решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral).

Рис. 6.2. Модели процесса (слева направо): каскадная, спиральная, MSF.
Источник: белая книга [1]

Процесс MSF ориентирован на “вехи” (milestones) – ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата.

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