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

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

Январь 2012

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

Применение

Application Lifecycle Management; Team Foundation Server

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

• Введение

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

• Инновационные игры

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

  • Покупка функции

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

• Заключение

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

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

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

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

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

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

• Как бы вы отнеслись к оснащению этого автомобиля системой навигации GPS?

Ответы ограничиваются приведенными ниже вариантами.

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

• Я считаю, что так и должно быть.

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

• Я бы это стерпел.

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

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

Далее мы зададим вопрос в нефункциональной форме.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В таблице 1 также есть варианты Q и R.

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

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

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

Инновационные игры

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

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

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

Игра

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

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

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

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

Покупка функции

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

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

Покупка функции по Штерну

Игра

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

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

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

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

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

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

Первым шагом является присвоение веса относительному преимуществу функции. Поощрение представляет собой преимущество для пользователей от использования функции в конечном продукте. Следующий шаг — назначение относительного штрафа. Штраф — это последствие отсутствия функции в готовом продукте для пользователей. (При оценке поощрений и штрафов выполняется то же самое, что и при оценке с помощью вопросов в функциональной и нефункциональной формах в методе Кано.) Веса — это произвольные числа, представляющие то, как ваша компания оценивает преимущества и риски, связанные с функциями. Это очень напоминает то, как учитель определяет значимость домашней работы, посещаемости, тестов и контрольных при выставлении итоговой оценки. У каждого учителя может быть своя система. Если принято решение, что поощрение перевешивает штраф, сделайте вес выше штрафа с помощью любого коэффициента, который вам кажется подходящим. Если вы считаете, что штрафы перевешивают поощрения, соответствующим образом скорректируйте веса. В примере в таблице 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 баллам.

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

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

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

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

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

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

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

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

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

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

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

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

Карл Вигерс написал две книги, в которых более подробно описывается относительное взвешивание: Software Requirements, Second Edition и More About Software Requirements: Thorny Issues and Practical Advice.

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

См. также

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

Совместная работа (изучаем в подробностях) [перенаправление]

Совместная работа [перенаправление]

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

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

1. Agile Software Requirements. Дин Леффингвел (Dean Leffingwell), Эддисон Весли (Addison Wesley)

   "Attractive Quality and Must-be Quality", Нориаки Кано, Quality JSQC, том. 14, выпуск 2, октябрь 1984 г. Оригинальная статья Нориаки Кано.

2. First Things First: Prioritizing Requirements, Карл Э. Вигерс