Управление масштабом проекта

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

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

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

2. Относительная количественная шкала. Каждый атрибут функции оценивается по девятибальной шкале. 1 означает наименьшее значение параметра, 9 – наивысшее.

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

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

Critical (Критический)	Основные функции. Если их не удастся реализовать, система не будет удовлетворять потребностям заказчика. В версии должны быть реализованы все критические функции, в противном случае график разработки срывается.
Important (Важный)	Функции, важные для успешной и эффективной работы системы в большинстве ситуаций. Отсутствие важной функции может повлиять на удовлетворенность заказчика, но выпуск версии не должен задерживаться из-за отсутствия какой-либо важной функции.
Useful (Полезный)	Функции, которые нужны в менее типичных ситуациях, будут использоваться не так часто, или их можно достаточно эффективно заменить другими действиями. Если они не войдут в релиз, это не окажет заметного воздействия на отношение заказчика или доходы.

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

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

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

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

Риск, связанный с нарушением безопасности – реализованная функция создаст бреши в защите системы.

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

При использовании качественной шкалы для оценки рисков используется градация «высокий-средний-низкий».