Определение приоритетов на основе ценности, стоимости и риска

В малом проекте заинтересованные лица могут согласовать приоритеты требований неформально. Крупные или спорные проекты требуют более структурированного подхода, устраняющего из процесса некоторые эмоции, политику и догадки. Для помощи в определении приоритетов предлагается несколько аналитических и математических методик. Они предполагают оценку относительной ценности и относительной стоимости каждого требования. Требования с самым высоким приоритетом — те, что обеспечивают большую ценность продукта при меньшей стоимости (Karlsson и Ryan, 1997; Jung, 1998). Субъективная оценка стоимости и ценности посредством попарного сравнения всех требований не годится, если требований более двух дюжин.

Другая альтернатива— Quality Function Deployment (QFD), всесторонний метод определения относительной ценности для клиента предлагаемых функций продукта (Zultner, 1993; Cohen, 1995). Третий подход, заимствованный из Total Quality Management (TQM), позволяет оценить каждое требование по нескольким весомым критериям успеха проекта и подсчитать количество баллов для назначения приоритетов требований. Тем не менее, по-видимому, лишь немногие организации-разработчики ПО готовы применять QFD или TQM.

В табл. 14-2 показана крупноформатная модель, которая поможет вам оценить относительные приоритеты для набора вариантов использования, функций или функциональных требований. Загрузить эту таблицу в формате Microsoft Excel можно с https://www.processim-pact.com/goodies.shtml. В табл. 14-2 перечислено несколько функций Chemical Tracking System (а каких же еще?). Эта схема заимствует и QFD концепцию обоснования ценности для пользователя; учитывается как выгода для пользователя, если функция реализована в продукте, так и неудобство, если она отсутствует (Pardee. 1996). Привлекательность функции прямо пропорциональна ее полезному действию и обратно пропорциональна стоимости и риску, связанному с ее реализацией. При прочих равных условиях функции с наибольшим значением ценность/стоимость должны иметь наивысший приоритет. При этом набор оцениваемых приоритетов распределяется по всему континууму, а не по нескольким отдельным уровням.

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

· менеджер проекта, который ведет процесс, разрешает конфликты и при необходимости адаптирует данные, поступающие от других: участников;

· представители клиента — сторонники продукта или маркетологи, предоставляющие информацию о сильных и слабых сторонах продукта;

· представители разработчиков, например руководители команд, сообщающие данные о стоимости и риске.

Таблица 14-2. Образец матрицы определения приоритетов для Chemical Tracking System '

При использовании этой модели определения приоритетов пользуйтесь следующим планом.

1. Перечислите в таблице все функции, варианты использования или требования, для которых хотите определить приоритеты; я для примера взял функции. Все элементы должны принадлежать к одному уровню абстракции — не смешивайте функциональные требования с функциями продукта. Если определенные функции логически связаны (например, вы реализуете функцию В только при наличии функции А), в анализ включайте только ведущую функцию. Эта модель работает лишь для нескольких дюжин функций, далее она становится слишком громоздкой. Если у вас несколько дюжин элементов, группируйте связанные функции, чтобы составить управляемый первоначальный список. При необходимости вы можете провести второй раунд анализа, на более детальном уровне.

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

3. Оцените относительный урон, который потерпит клиент или бизнес, если функция не будет включена в продукт. Снова используйте шкалу от 1 до 9: 1 балл означает, что никто не расстроится, если ее не окажется; 9 показывает серьезный урон. Требования, имеющие низкие рейтинги и выгоды, и урона, увеличивают стоимость, но имеют малую ценность; они могут оказаться мишурой: выглядят привлекательно, но не стоят инвестиций. Оценивая урон, учитывайте, насколько расстроятся клиенты, если определенная функция не будет реализована. Задайте себе вопросы, аналогичные перечисленным ниже.

· Проиграет ли ваш продукт по сравнению с другими, содержащими эту функцию?

· Будут ли какие-либо юридические или контрактные последствия?

· Не нарушите ли вы какой-либо юридический или промышленный стандарт?

· Не лишит ли это пользователей возможности выполнять какие-либо необходимые или ожидаемые действия?

· Намного ли сложнее добавить эту функцию позже, в качестве модернизации?

· Возникнут ли проблемы из-за того, что отдел маркетинга обещал эту функцию, чтобы удовлетворить некоторых потенциальных клиентов, но команда решила не включать ее?

4. В этой таблице подсчитаны итоговые значения для каждой функции как сумма баллов ее выгоды и урона. По умолчанию выгода и урон оцениваются одинаково. Для уточнения вы можете изменить относительный вес этих двух параметров в верхней строке таблицы. В примере, взятом для табл. 14-2, выгода оценивается дважды, как и урон. В таблице суммируется ценность всех функций и посчитан процент от общего значения для каждого набора функций, равного сумме ценностей каждой функции (%).

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

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

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

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

приоритет =

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

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

Заинтересованные в проекте лица часто по-разному оценивают важность того или иного требования и потенциальный уровень от его отсутствия. Один из вариантов таблицы приоритетов учитывает входные данные от нескольких классов пользователей или других заинтересованных в проекте лиц. На странице Multiple Stakeholders (Множество пользователей) загружаемой электронной таблицы скопируйте колонки Relative Benefit (Относительная выгода) и Relative Penalty (Относительный урон) для каждого заинтересованного в проекте лица, участвующего в анализе. Затем назначьте вес для каждого участника, больший вес отдавая привилегированным классам пользователей, а не группам, имеющим меньшее влияние на принятие решений, касающихся проекта. В таблице будет учтен вес каждого участника при подсчете общего значения ценности.

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

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