Оценка требований по Кано

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

При первом приближении взятие в работу должно идти в следующем порядке: правая-верхняя четверть, левая верхняя четверть, правая нижняя. На левую нижнюю никогда не хватает времени. Про оценку сложности можно говорить очень много, и об этом в другой раз. Сегодня предлагаю обсудить оценку полезности, предложенную Нориаки Кано в начале 80-х годов прошлого века. В рамках этой модели все требования (функции будущего продукта) разбиваются на 5 групп:

1.       Привлекательные характеристики. При наличии этих параметров пользователи будут испытывать удовлетворение. Однако, если этих функций в продукте не будет, к негативным эффектам это не приведет. Именно об этих характеристиках продукта будет рассказывать «сарафанное радио».

2.       Одномерные характеристики.  Эти характеристики вызывают удовлетворенность, если они есть, и неудовлетворенность, если их нет. К таким параметрам может относиться скорость работы приложения. При низкой скорости откликов – негатив, при высокой – удовлетворение.

3.       Обязательные характеристики. Их наличие считается обязательным, поэтому отсутствие вызывает негатив. К примеру, если ваш текстовый редактор не позволяет набирать текст, то вы его не продадите.

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

5.       Нежелательные характеристики. Это все то, что будет вызывать у пользователя раздражение. Как правило, эти характеристики возникают потому, что так было проще разрабатывать.

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

1.       Насколько вам понравится наличие … в продукте?

2.       Как вы отнесетесь к отсутствию … в продукте?

На каждый вопрос  пользователь может выбрать один из пяти вариантов ответа:

1.       Мне это нравится

2.       Я ожидаю именно этого

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

4.       Я могу это терпеть

5.       Мне это не нравится

Для обработки полученных в опросе результатов применяется оценочная таблица следующего вида:

В нее заносится, сколько человек ответило именно так на положительный и отрицательный вопрос о требовании. Допустим, если вы анализируете требование «наличие двухфакторной авторизации», и  на положительный вопрос (наличие двухфакторной авторизации) пользователь ответил «Ожидаю», а на отрицательный (отсутствие двухфакторной авторизации) – «Могу терпеть», то его голос будет добавлен вот в эту ячейку:

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

Пользуясь моделью Кано, необходимо понимать, что она не всегда применима. Например, она не может решить проблему, изложенную в теореме Эрроу. Да и Генри Форд говорил: «Если бы я слушал своих клиентов, мне бы пришлось дать им более быструю лошадь». Но если вас это не останавливает, то предложенная методика позволяет неплохо  ранжировать ценность требований в списке.

Для тех, кто захочет попробовать методику, но не готов в ручном режиме обрабатывать результаты, есть бесплатный сайт: http://www.kanosurvey.com/