Методика определения относительных приоритетов
1. Перечислить в таблице все функции, варианты использования или требования, для которых хотите определить приоритеты. Все элементы должны принадлежать к одному уровню абстракции — нельзя смешивать программные требования с функциями продукта. Если в проекте несколько десятков элементов, связанные функции группируются, чтобы составить управляемый первоначальный список. При необходимости следует провести второй раунд анализа, на более детальном уровне.
2. Совместно с заказчиком определяется относительная выгода, которую каждая функция дает клиенту или бизнесу, по шкале от 1 до 9. 1 балл означает,что никто не находит ее полезной, а 9 — что она крайне ценная. Эти оценки выгоды отражают связь функций с бизнес-требованиями к продукту.
3. Оценивается относительный ущерб, который потерпит клиент или разработчики, если функция не будет включена в продукт. Снова используется шкала от 1 до 9: 1 балл означает, что никто не расстроится,если ее не окажется; 9 показывает серьезный урон. Требования, имеющие низкие рейтинги и выгоды, и урона, увеличивают стоимость, но имеют малую ценность. Оценивая урон,учитывайте,насколько расстроятся клиенты, если определенная функция не будет реализована. Задайте себе вопросы, аналогичные перечисленным ниже.
Проиграет ли ваш продукт по сравнению с другими, содержащими эту функцию?
Будут ли какие-либо юридические или контрактные последствия?
Не нарушители вы какой-либо юридический или промышленный стандарт?
Не лишит ли это пользователей возможности выполнять какие-либо необходимые или ожидаемые действия?
Намного ли сложнее добавить эту функцию позже, в качестве модернизации?
4. В этой таблице подсчитаны итоговые значения ценности для каждой функции как сумма баллов ее выгоды и урона. По умолчанию выгода и урон оцениваются одинаково. Для уточнения вы можете изменить относительный вес этих двух параметров в верхней строке таблицы. В примере выгода оценивается дважды. В таблице суммируется ценность всех функций и посчитан процент от общего значения для каждого набора функций, равного сумме ценностей каждой функции (%).
5. Разработчики оценивают относительную стоимость реализации каждой функции по шкале от 1 (легко и быстро) до 9 (трудоемко и дорого). В таблице подсчитан процент общей стоимости, составленной из вклада каждой функции.
6. Подобным же образом,разработчики оценивают относительную степень технического или другого риска,связанного с каждой функцией,по шкале от 1 до 9. 1 балл означает, что вы сможете запрограммировать ее даже во сне, 9 баллов означает серьезную озабоченность возможностью реализации, нехваткой сотрудников с необходимым опытом или использованием неиспытанных или незнакомых средств и технологий.
В таблице подсчитан общий процент риска,который складывается из риска каждой функции. В стандартной модели выгода,урон,стоимость и риск оцениваются одинаково,но их вес можно изменить. В примере риск имеет половину веса фактора стоимости, который имеет тот же вес,что и ущерб. Если вы не желаете учитывать риск вообще в этой модели, приравняйте значение его веса к нулю.
7. После того как вы введете все результаты оценки в таблицу,по сле дующей формуле подсчитывается значение приоритета для каж дой функции:
Приоритет = %ценности
(%стоимости *вес стоимости)+(%риска *вес риска)
8. Список функций сортируется по уменьшению подсчитанного приоритета. Функции вверху списка характеризуются наиболее благо приятным сочетанием ценности, стоимости и риска и поэтому при равенстве остальных факторов — должны иметь наивысший приоритет.
9. На основании данного отсортированного по приоритетам функций определяется, какие функции будут включены в базовую версию продукта и под этими функциями проводится линия базового уровня.
Функции, находящиеся выше базового уровня являются обязательными и включаются в первый релиз. Функции, находящиеся ниже базового уровня, теперь являются будущими и будут рассматриваться при реализации следующих версий. Приоритет этих функций в дальнейшем может быть повышен (на основании того, что сделано, и исходя из будущих пожеланий заказчика).