Наконец, к привлекательным относят те функции, которые обеспечивают восхищение и нередко готовность заплатить более высокую цену за продукт. Вместе с тем отсутствие привлекательных функций не снижает удовлетворенность клиентов ниже уровня нейтральности. Встроенный в гостиничный тренажер телевизор был для меня привлекательным качеством. Я бы не уехал с чувством неудовлетворенности, если бы его не было, поскольку не встречал такого ни в одной другой гостинице. Фактически привлекательные функции зачастую порождают новые потребности, так как клиенты или пользователи не подозревают о потребности в этих функциях, пока не увидят их.
Взаимосвязь этих трех типов функций представлена на рис. 11.1. Стрелка, идущая снизу вправо на рисунке, показывает, что после реализации определенного количества обязательной функции удовлетворенность клиентов не увеличивается с наращиванием ее объема. Также не имеет значения, в какой мере добавляется обязательная функция, — удовлетворенность клиентов никогда не поднимается выше срединной точки.
В отличие от этого линия в верхней части слева говорит о том, что удовлетворенность клиентов резко возрастает даже при ограниченной реализации привлекательной функции. Наконец, линия, проходящая посередине, демонстрирует прямую взаимосвязь между включением линейных функций и удовлетворенностью клиентов.
Поскольку обязательные функции необходимы продукту, чтобы занять рыночный сегмент, акцентировать внимание следует на приоритетности разработки всех пороговых функций. Нет нужды разрабатывать обязательные функции продукта в первых итерациях релиза. Вместе с тем в силу того, что пользователи считают эти функции обязательными, они должны быть реализованы до выпуска готового продукта. Не забывайте при этом, что может быть вполне приемлемой частичная реализация обязательных функций, поскольку прирост удовлетворенности клиентов быстро падает после достижения базового уровня поддержки таких функций. Например, я пишу эту книгу в издательской системе Adobe FrameMaker, которая поддерживает минимальную функцию «отмена», обеспечивая возврат лишь на один уровень. С моей точки зрения, ее разработчики продвинулись со своей одноуровневой функцией «отмена» довольно далеко по оси удовлетворенности клиентов, однако я бы предпочел, чтобы этих уровней было намного больше.
Во вторую очередь внимание следует сконцентрировать на реализации как можно большего количества линейных функций. Поскольку каждая из этих функций напрямую повышает удовлетворенность клиентов, чем больше их будет включено, тем лучше (за исключением, конечно, таких ситуаций, когда продукт и без того раздулся от слишком большого количества функций). Наконец, если позволяет время, нескольким привлекательным функциям необходимо присвоить такой приоритет, чтобы они попали в план релиза.
Учтите, что функции на диаграмме Кано со временем смещаются вниз. Еще совсем недавно беспроводной доступ в интернет в гостиничном номере был привлекательной функцией. Сейчас это уже линейная функция, которая вот-вот станет пороговой.
Оценка тем по модели Кано
Самый простой подход к использованию модели Кано в agile-проекте — анализ всех тем и их грамотная разбивка по типам. Намного лучше, однако, определить тип каждой темы совместно с клиентами или пользователями. Это на удивление легко, поскольку можно использовать письменный опросный лист. Для точной приоритизации требований опросный лист, возможно, придется направить 20–30 пользователям (Griffin and Hauser, 1993).
Кано предлагал определять категорию функции с помощью двух вопросов: один вопрос для выяснения того, что пользователь будет чувствовать при наличии функции в продукте, и второй — что он будет чувствовать при ее отсутствии. Говорят, что первый вопрос имеет функциональную форму, поскольку предполагает наличие функции, а второй — дисфункциональную форму, поскольку в этом случае функция отсутствует. Ответ на каждый вопрос выбирается на стандартной шкале из пяти пунктов:
1. Мне это нравится.
2. Я ожидал, что это будет выглядеть так.
3. Мне безразлично.
4. Я могу смириться с этим.
5. Мне это не нравится.
В качестве примера вспомним наш веб-сайт SwimStats. Допустим, мы собираемся добавить три новые функции:
• Возможность видеть график результатов пловца в соревнованиях прошлого сезона.
• Возможность для пловцов размещать информацию о своей специализации.
• Возможность для любого зарегистрированного члена сайта загружать фотографии.
Чтобы определить типы этих функций, мы проводим опрос потенциальных пользователей, задавая им следующие вопросы:
• Если бы была возможность построить график результатов пловца в соревнованиях прошлого сезона, как бы вы к этому отнеслись?
• Если бы не было возможности построить график результатов пловца в соревнованиях прошлого сезона, как бы вы к этому отнеслись?
• Если бы у пловцов была возможность размещать информацию о своей специализации, как бы вы к этому отнеслись?
• Если бы у пловцов не было возможности размещать информацию о своей специализации, как бы вы к этому отнеслись?
• Если бы была возможность загружать фотографии, как бы вы к этому отнеслись?
• Если бы не было возможности загружать фотографии, как бы вы к этому отнеслись?
Первая пара этих вопросов и гипотетические ответы одного из пользователей приведены на рис. 11.2.
Из рис. 11.2 следует, что пользователь вполне может давать взаимоисключающие ответы. Например, он может сказать, что ему нравится возможность построить график результатов пловца в соревнованиях, и в то же время, что ему не нравится та же самая функция. Существует 25 возможных комбинаций ответов на функциональную и дисфункциональную формы вопроса. Нам необходимо найти способ одновременного просмотра обоих ответов и оценки мнения пользователя.
Категоризация ответов
Такой способ представлен на рис. 11.3. С помощью перекрестной связи ответов на функциональный и дисфункциональный вопросы реакцию потенциального пользователя можно свести к однозначному варианту. Поэтому если пользователь говорит, что он ожидает получить возможность строить график результатов в соревнованиях и что ему не нравится отсутствие такой возможности (как на рис. 11.2), то мы устанавливаем перекрестную связь ответов и получаем, что он считает эту функцию обязательной. По его представлениям, возможность строить график результатов в соревнованиях является обязательной функцией.
