Определения приоритетов

Автор Митч Лейси.Владелец, Mitch Lacey & Associates, Inc, консультационная фирма, специализирующаяся на принятии и усовершенствовании гибкого подхода и Scrum.

Январь 2012 г.

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

Применение

Управление жизненным циклом приложений; Team Foundation Server.

Содержание этой статьи

• Введение

• Модель Кано удовлетворения клиентов

• Игры нововведения

  • Обрезка дерева продукта

  • Купить функцию

• Относительное взвешивание — Карл Вигерс

• Заключение

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

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

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

Модель Кано удовлетворения клиентов

Модель удовлетворенности клиента Кано была разработана в 1980-х годах профессором Нориаки Кано из Университета Рика в Токио.Его модель предоставляет простую схему ранжирования, которая различает необходимые и отличительные атрибуты.Подход на основе анкеты, модель представляет собой эффективный способ визуализации характеристик продукта и стимулирования обсуждений внутри команды разработчиков.

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

• Что бы вы почувствовали, если бы этот автомобиль был оснащен системой навигации GPS?

Мы ограничиваем ответы следующими.

• Мне бы это понравилось

• Я ожидал бы, что это будет так

• Мне все равно

• Я мог бы жить с этим

• Мне бы это не понравилось

В этом примере предположим, что наши выдуманные клиенты ответили, сказав "В таком виде мне это нравится".

Далее мы зададим отрицательную форму вопроса:

• Что бы вы почувствовали, если бы этот автомобиль не был оснащен системой навигации GPS?

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

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

Таблица 1. Сопоставление Кано

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

• E = Возбудители.Это функции, которые клиент не ожидает и которые действительно отличают продукт из своих конкурентов.Их трудно определить, особенно сначала, так как может быть сложно придумать вопросы, которые заставляют назвать интересные функции.По этой причине возбудители обычно возникают и поднимаются по приоритету по мере продвижения проекта и поступления отзывов клиента.

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

  • В нашем примере полезной может оказаться функция GPS-навигации.Изучение этой функции, по меньшей мере до момента получения отзывов клиента, должно иметь относительно высокий приоритет.

• B = базовый план.Эти функции должны находиться в продукте.Это обязательные, высокоприоритетные функции.

  • Независимо от того, насколько успешно выполнены эти базовые атрибуты, клиент продолжает относиться к продукту нейтрально.Текстовый редактор, например, должен иметь функции «создать документ» и «сохранить документ».Это цена записи.

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

• L = линейно.Также известные как требования по производительности, линейные функции непосредственно связаны с удовлетворением клиента.Они попадают по приоритету сразу ниже основных функций, но их необходимо балансировать относительно затрат на них.

  • Расширенные функциональные возможности или высокое качество выполнения повышают удовлетворенность клиента.Уменьшенная функциональность понижает степень удовлетворенности.

  • Цена продукта зачастую связана с этими атрибутами.

• I = Безразлично.Эти функции наименее важны для клиента, и, таким образом, как таковые, должны быть наименее важные для продукту.Они, скорее всего, не будут давать практически никакой ценности.

В таблице 1 также присутствуют Q и R.

• Q: Questionable, спорный — вопрос скорее всего неправильный, или ответ подозрительный.

• : R: Reverse, обратный — комбинация ответов не позволяет вычислить результат.Возьмем систему GPS-навигации — если кто-то ответит, что он ожидает, чтобы она была, но и без нее тоже хорошо — это ответ R.

Если пара ответа получает оценку Q или R, необходимо изучить свои вопросы или пару ответа более глубоко.

Игры нововведения

Innovation Games — средства, которые помогут разработать первичное рыночное исследование.С этими средствами, клиенты играют в «игры» с целью создания отзывов и входных данных о продукте или услуге.Люк Хоффман создал и описывает более 12 игр в своей книге Innovation Games, которая займет почетное место в любой библиотеке.Мои любимые две игры для определения приоритетов невыполненной работы — это Обрезка дерева продукта и Купи функцию, которые Люк описывает в данном отрывке из этой книги (используется с разрешения):

Обрезка дерева продукта

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

Игра

Начните с рисования большого дерева на доске или толстой бумаге или печати картинки с деревом в виде плаката крупного формата.Толстые ветви представляют главные области функций в системе.Граница дерева — его самые крайние ветви — представляют функции, доступные в текущем выпуске.Запишите потенциальные новые функции на нескольких карточках, идеально в форме листьев.Попросите клиентов разместить необходимые функции вокруг дерева, указав следующий этап его роста.Составляют ли они дерево, которое растет сбалансированным способом?Не приходится ли основной рост на одну ветвь, возможно, ключевую функцию продукта?Становится ли недостаточно используемый аспект дерева сильнее?Мы знаем, что корни дерева (инфраструктура поддержки и заботы о клиентах) должна простираться так же далеко, как крона.А ваши?

Дерево продукта — Хоманн

Как это работает

И вы и клиенты знают, что функции различаются по важности.Поэтому нам обычно хочется прилагать усилия к самым важным функциям — тем функциям, которые представляют наибольшую ценность для клиентов.К сожалению, иногда это означает, что мы слишком мало вкладываем усилий в функции, необходимые для завершения продукта.Игра Prune the Product Tree (подрезка дерева продуктов) предоставляет клиентам способ осуществлять ввод в процесс принятия решений, глядя на набор функций, представляющих продукт целостным образом.

Купить функцию

Какая Функция заставит клиентов купить ваш продукт?Какая функция приведет к обновлению клиентов?Какая Функция сделает клиентов такими счастливыми, так что они проигнорируют или не придадут значения функциями, про которые они хотели, чтобы вы их исправили или удалили?

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

Купить функцию –Sterne

Игра

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

Эта игра работает лучше всего с 4—7 клиентами в группе, чтобы можно было создать больше возможностей для клиентов объединить свои деньги через переговоры.В отличие от игры "Коробка продукта", игра "Купи функцию" основана на списке функций, которые, по всей вероятности, будут находиться в вашей дорожной карте разработки.

Как это работает

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

Относительное взвешивание — Карл Вигерс

Другой прекрасный метод для определения приоритетов – это относительное взвешивание, введенное Karl Weigers в 1999 г.Этот метод не только предоставляют механизм приоритизации требований на основе ввода пользователей и отзывов, но также включает экспертную оценку команды.Как Kano и Innovation Games, Relative Weighting позволяет владельцу продукта точнее оценить , какие функции реализовывать и в каком порядке приоритета.

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

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

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

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

В следующем примере пользователи определили относительную полезность функции "Статус запроса заказа поставщика" на уровне 5 баллов.Они оценили ее относительный проигрыш как 3.Чтобы получить общее значение этой функции, умножим два числа на их относительные весы и сложим их.

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

В этом случае общее значение для этой функции — 13 точек.

Когда мы получаем полное относительное значение и процент значения для функций, мы больше не спрашиваем пользователей, а переходим к получению мнений от команды.Мы просим команду оценивать относительной стоимости для реализации каждую функцию с использованием той же шкалы.Карл Уэджерс (Karl Weigers) объясняет: "Разработчики оценивают стоимость на основе факторов, таких как сложность продукта, объем работ по пользовательскому интерфейсу, возможность повторно использовать существующий дизайн или код, необходимый уровень документации и тестирования".

После того как мы оцениваем относительные затраты, мы оцениваем относительный риск.Опять же, Weigers с текстом «разработчики оценивают относительную степень технического или другого риска, связанного с каждой функцией по шкале от 1 до 9.Оценка 1 означает, что запрограммировать можно во сне, тогда как 9 указывают на серьезные беспокойства об осуществимости, доступности штата с необходимым опытом или использовании ненадежных или малознакомых средств и технологий.Электронная таблица будет вычислять процент общего риска, который поступает из каждой функции."

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

• Общий процент значения: Разделите значение суммы относительных преимущества и недостатков на общую сумму внизу.В следующем примере это 13/154 = 8 %.

• Процент относительной стоимости: разделите значение относительной стоимости на общую сумму относительной стоимости внизу.В следующем примере это 2/42 = 4,8 %.

• Процент относительного риска: разделите значение относительного риска на общую сумму относительного риска внизу.В следующем примере это 1/33 = 3 %.

• Приоритет: разделите процент ценности на (процент затрат * вес затрат) + (процент ценности * вес ценности).В следующем примере это будет выглядеть следующим образом: 8,4 % / ((4,8 % * 1) + (3 % * 0,5).Это дает значение приоритета (1,345).

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

В конце концов лист выглядит, как эта таблица.

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

Вейгерс объясняет, как сделать модель более точного соответствующей реальности:

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

Карл Уэджерс (Karl Weigers) написал 2 книги, более подробно описывающие систему оценки: Software Requirements, Second Edition и More About Software Requirements: Thorny Issues and Practical Advice.

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

См. также

Основные понятия

Начало работы в команде

Гибкое планирование и итерации

Отзывы и предложения заинтересованного лица запроса и процессов с помощью Team Web Access

Отслеживание работ и управление рабочим процессом

1. Гибкие требования к программному обеспечению, Dean Leffingwell, Addison Wesley

   "Привлекательное качество и обязательное качество" Noriaki Kano, Quality JSQC, Vol.14, № 2, октябрь 1984 г.Оригинальная статья профессора Кано.

2. http://www.processimpact.com/articles/prioritizing.html