Планирование процесса

Неопределенность и непредсказуемость неизбежны. Следовательно план проекта должен учитывать появление непредсказуемых факторов. Рекомендуется два подхода: резерв времени и планирование на основе рисков.

Резерв времени

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

Планирование с учетом рисков

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

1. он стимулирует раннее создание прототипов, проверяющих корректность концепций,

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

3. позволяет расставить приоритеты на основе технических и бизнес-рисков,

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

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

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

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

Поиск компромиссов

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

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

	Оптимизация	Ограничения	Как получится
Ресурсы		+
Дата выпуска	+
Характеристики			+

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

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

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

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

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

Лекция 7. Общие замечания к модели разработки MSF. Часть 2

Управление рисками

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

1. обучаться,

2. быстро адаптироваться к переменам,

3. предусматривать изменения,

4. действовать эффективно.

Существует два принципиально разных подхода к управлению рисками. Большинство групп в качестве метода управления рисками практикуют реагирование – они так или иначе реагируют на уже возникшую проблему. Однако существует подход превентивного управления рисками. Этот подход предполагает наличие продуманного плана и процесса управления рисками до их реализации, то есть до возникновения проблемы. Процесс управления рисками должен быть не только продуманным, но и постоянным. При превентивном управлении риски постоянно контролируются, а информация о состоянии важнейших рисков служит основой для принятия решений на всех стадиях проекта. Управление рисками продолжается до их исчезновения или, если проблема все-таки возникла, до ее устранения.

Ориентация на выпуск в срок

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

1. Мобилизует проектную группу: для выпуска продукта в срок проектной группе придется мобилизовать все свои способности.

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

3. Предоставляет в распоряжение группы мощный инструмент принятия решений: все решения принимаются на основе их связи с выпуском продукта в срок.

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

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

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

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

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

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

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

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

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

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

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