Разбиение больших проектов на ряд независимых (управляемых) частей

Существует два принципиально разных подхода к управлению

рисками:1)простое реагирование. Большинство групп в качестве метода управления рисками

практикуют реагирование— они так или иначе реагируют на уже возникшую проблему.

2)превентивное управления рисками. Этот подход предполагает наличие продуманного плана и процесса управления рисками до их реализации, то есть до возникновения проблемы. Процесс

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

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

Задачи большого проекта лучше разделить на несколько компактных и, желательно, независимых частей, которые следует трактовать как отдельные проекты или внутренние выпуски продукта. Такой метод можно рассматривать как выпуск нескольких версий в рамках одного проекта,

когда финальная версия продукта выпускается только в конце проекта.

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

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

Подразделение больших проектов на компактные составляющие:

• позволяет проектной группе сосредоточиться на конкретной работе по выполнению сравнительно небольших и потому лучше управляемых независимых проектов;

• приносит удовлетворение от завершения промежуточных проектов, избавляя от ощущения безысходности, которое появляется у разработчиков больших проектов;

• вовремя сигнализирует о проблемах, поскольку завершение отдельных проектов служит промежуточными этапами большого проекта; если сдача какого-то проекта задерживается, группа имеет возможность скорректировать ход проекта в целом;

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

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