При первом приближении взятие в работу должно идти в следующем порядке: правая-верхняя четверть, левая верхняя четверть, правая нижняя. На левую нижнюю никогда не хватает времени. Про оценку сложности можно говорить очень много, и об этом в другой раз. Сегодня предлагаю обсудить оценку полезности, предложенную Нориаки Кано в начале 80-х годов прошлого века. В рамках этой модели все требования (функции будущего продукта) разбиваются на 5 групп:
1. Привлекательные характеристики. При наличии этих параметров пользователи будут испытывать удовлетворение. Однако, если этих функций в продукте не будет, к негативным эффектам это не приведет. Именно об этих характеристиках продукта будет рассказывать «сарафанное радио».
2. Одномерные характеристики. Эти характеристики вызывают удовлетворенность, если они есть, и неудовлетворенность, если их нет. К таким параметрам может относиться скорость работы приложения. При низкой скорости откликов – негатив, при высокой – удовлетворение.
3. Обязательные характеристики. Их наличие считается обязательным, поэтому отсутствие вызывает негатив. К примеру, если ваш текстовый редактор не позволяет набирать текст, то вы его не продадите.
4. Неважные характеристики. Пользователь к ним нейтрален. Например, для большинства пользователей того-же текстового редактора функция подсчета символов в тексте – нейтральная.
5. Нежелательные характеристики. Это все то, что будет вызывать у пользователя раздражение. Как правило, эти характеристики возникают потому, что так было проще разрабатывать.
Для того, чтобы отнести требование к одной из этих групп, необходимо провести анкетирование пользователей. По каждому требованию задаются два вопроса:
1. Насколько вам понравится наличие … в продукте?
2. Как вы отнесетесь к отсутствию … в продукте?
На каждый вопрос пользователь может выбрать один из пяти вариантов ответа:
1. Мне это нравится
2. Я ожидаю именно этого
3. Мне все равно
4. Я могу это терпеть
5. Мне это не нравится
Для обработки полученных в опросе результатов применяется оценочная таблица следующего вида:
В нее заносится, сколько человек ответило именно так на положительный и отрицательный вопрос о требовании. Допустим, если вы анализируете требование «наличие двухфакторной авторизации», и на положительный вопрос (наличие двухфакторной авторизации) пользователь ответил «Ожидаю», а на отрицательный (отсутствие двухфакторной авторизации) – «Могу терпеть», то его голос будет добавлен вот в эту ячейку:
В результате получим некоторые значения в зонах нашей таблицы. Если основная масса ответов о требовании пришлась на зону «Привлекательно», то, значит, эта функция может стать фишкой приложения. Когда основная масса находится в зоне «Обязательно», выбора нет, этот функционал должен быть реализован. Если лидирует зона «Нежелательно», будьте уверены, этот функционал пользователи не оценят. Зона «Не важно» оставляет простор для выбора. И самая интересная зона - «Непонятно». Если в этой зоне много голосов, от опрашиваемые не поняли функцию, поскольку не может одновременно нравится и наличие этой функции, и ее отсутствие.
Пользуясь моделью Кано, необходимо понимать, что она не всегда применима. Например, она не может решить проблему, изложенную в теореме Эрроу. Да и Генри Форд говорил: «Если бы я слушал своих клиентов, мне бы пришлось дать им более быструю лошадь». Но если вас это не останавливает, то предложенная методика позволяет неплохо ранжировать ценность требований в списке.
Для тех, кто захочет попробовать методику, но не готов в ручном режиме обрабатывать результаты, есть бесплатный сайт: http://www.kanosurvey.com/
