Что такое Kano-анализ и как его применять для приоритизации требований?

Что такое Kano-анализ и как его применять для приоритизации требований?

Kano-анализ — это метод категоризации функций/требований системы на основе того, как они влияют на удовлетворенность пользователя. Модель была разработана японским ученым Нориаки Кано в 1984 году и стала основой для prioritization в product management и business analysis.

Просто: Kano-анализ отвечает на вопрос: какие функции реально важны для клиента, а какие просто «шум»?

Пять категорий требований в Kano-модели

1. Базовые требования (Must-Have / Threshold Attributes)

Определение: Функции, которые просто ДОЛЖНЫ быть. Их отсутствие вызывает высокое недовольство. Их наличие — просто ожидание.

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

Примеры:

• Email клиент ДОЛЖЕН получать письма (иначе зачем?)
• Онлайн банк ДОЛЖЕН быть безопасным
• Мобильное приложение ДОЛЖНО работать быстро
• Магазин ДОЛЖЕН принимать оплату

График: При отсутствии = большое недовольство. При наличии = нейтрально.

Инвестмент: Обязателен, но не вложение в конкурентное преимущество.

2. Характеристики производительности (Performance / Linear Attributes)

Определение: Чем больше, тем лучше. Удовлетворенность прямо пропорциональна уровню реализации.

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

Примеры:

• Скорость загрузки приложения
• Размер хранилища в облаке
• Качество видео на YouTube
• Батарея смартфона
• Частота обновлений ПО

График: Линейный. Больше = счастливее.

Инвестмент: Это область конкуренции. Здесь можно выиграть у конкурентов.

3. Привлекательные требования (Delighters / Excitement Attributes)

Определение: Функции, которые пользователь не ожидает. Их наличие вызывает восторг. Их отсутствие не расстраивает.

Психология: "Вау! Я не знал, что так можно!" Создают лояльность и говорят за вас.

Примеры:

• Google Maps показывает пробки в реальном времени
• Netflix рекомендует фильмы на основе истории
• Spotify создает персональные плейлисты (Discover Weekly)
• Telegram позволяет отправлять большие файлы
• Uber показывает местоположение водителя в реальном времени

График: При отсутствии = мало влияет на восторг. При наличии = восторг растет.

Инвестмент: Здесь создается эмоциональная связь с продуктом.

Важно: Со временем Delighters превращаются в Performance требования, а потом в Must-Have.

Пример: 5-10 лет назад:

• Смартфон с интернетом = Delighter
• Сегодня = Performance (чем быстрее, тем лучше)
• В будущем = Must-Have

4. Безразличные требования (Indifferent / Neutral Attributes)

Определение: Требования, которые пользователю вообще не волнуют. Есть или нет — все равно.

Психология: Пользователь о них даже не думает.

Примеры:

• Цвет кнопки "Save"
• Точный формат лога ошибки
• Размер иконки в меню
• Название переменной в коде (для end user)

Инвестмент: Ноль ROI. Не инвестируйте сюда.

5. Обратные требования (Reverse / Dis-satisfiers)

Определение: Больше — хуже. Пользователи хотят ровно нужное количество.

Психология: Переизбыток может раздражать.

Примеры:

• Размер приложения (тяжелое приложение занимает место)
• Количество уведомлений (слишком много = раздражает)
• Вес устройства
• Цена (чем дешевле, тем лучше, но только до определенного предела)

Инвестмент: Найти оптимальное значение, а не максимизировать.

Как провести Kano-анализ?

Шаг 1: Собрать требования

Отбросить очевидные, собрать все требования/функции, которые вы хотите приоритизировать.

Шаг 2: Создать опрос

Для каждого требования задать ДВА вопроса:

Функциональный вопрос: "Как вы чувствуете себя, если у продукта ЕСТь эта функция?" Ответы:

• Нравится мне
• Ожидаю, что это будет
• Мне все равно
• Могу мириться с отсутствием
• Мне не нравится

Дисфункциональный вопрос: "Как вы чувствуете себя, если у продукта НЕТ этой функции?" Те же ответы.

Пример для Spotify:

Вопрос 1: "Как вы чувствуете себя, если Spotify создает для вас персональные плейлисты?" → Ответ: Нравится мне (Delighter!)

Вопрос 2: "Как вы чувствуете себя, если Spotify НЕ создает персональные плейлисты?" → Ответ: Мне все равно (подтверждает Delighter)

Шаг 3: Классифицировать требования

В зависимости от комбинации ответов::

Шаг 4: Построить матрицу

Удовлетворенность
      ^
      |
      | Delighters
      |
      |      Performance
      |
      |              Must-Have
------+--------------------------->
      | Indifferent   Reverse
      -

Ось X: Наличие функции (0 = нет, 1 = есть) Ось Y: Удовлетворенность

Шаг 5: Приоритизировать

Приоритет 1: Must-Have (без них система не конкурентоспособна) Приоритет 2: Performance (улучшение здесь = конкурентное преимущество) Приоритет 3: Delighters (если есть ресурсы) Приоритет 4: Indifferent (игнорировать) Приоритет 5: Reverse (изучить, может быть изменено требование)

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

Must-Have (ОБЯЗАТЕЛЬНО)

• Просмотр меню
• Оформление заказа
• Оплата
• Трекинг доставки (адрес, статус)
• Работа приложения на iOS и Android

Performance (Конкурентное преимущество)

• Скорость поиска (индексирование)
• Качество рекомендаций (алгоритм ML)
• Время обработки заказа
• Интеграция с различными ресторанами

Delighters (Вау-фактор)

• Персональные промокоды на основе истории
• "Заказать как в прошлый раз" одной кнопкой
• Бесплатная доставка первый заказ
• Живые уведомления о приближении курьера (как в Uber)
• Schedule заказ на будущее

Indifferent

• Точный цвет кнопки
• Порядок фильтров
• Название раздела меню

Reverse

• Размер приложения (легче = лучше)
• Количество уведомлений (слишком много = раздражает)

Почему это важно для BA?

1. ROI

Не все требования одинаково важны. Must-Have дают 20% удовлетворенности, а Delighters могут дать 80%.

2. Планирование спринтов

• Спринт 1: Все Must-Have
• Спринт 2-3: Performance
• Спринт 4+: Delighters

3. Говор с бизнесом

"Это Delighter, который превратится в Must-Have через год. Инвестируем сейчас, доминируем потом."

4. Scopе контроль

Разработчик просит добавить новую функцию:

• "Это Must-Have, Performance или Delighter?"
• Если Indifferent = не добавляем
• Если Delighter = добавляем в backlog, но не в текущий спринт

Эволюция Kano

С течением времени требования мигрируют вниз по иерархии:

Год 1 (2015):  Delighter (Instagram Stories)
         ↓
Год 2 (2016):  Performance (Stories на Snapchat, Facebook)
         ↓
Год 3 (2017):  Must-Have (все социальные сети скопировали)

Это означает, что вчерашний Delighter сегодня — просто ожидание.

Инструменты для проведения Kano-анализа

• Google Forms / Survey Monkey (опросы)
• Excel / Tableau (анализ результатов)
• Miro / Figma (визуализация матриц)
• AHA Insights / ProdPad (специализированные платформы)

Ключевые выводы

1. Не все требования одинаково влияют на удовлетворенность
2. Must-Have — это таблица умножения, Performance — конкурентное преимущество
3. Delighters создают эмоциональную связь и лояльность
4. Со временем Delighters становятся Must-Have
5. Kano помогает принять сложные решения о приоритизации

Основная идея: Инвестируй в Must-Have как базу, в Performance как конкурентное преимущество, и в Delighters как в будущее доминирования.