Команда продукта распределяет фичи по бэклогу интуитивно — "это важно", "это клиенты просили" — и годами инвестирует в удобный интерфейс, не замечая, что базовая надёжность продукта страдает. Клиенты не благодарят за удобство, если продукт периодически падает — а команда не понимает, почему удовлетворённость не растёт вопреки постоянным улучшениям.
Хрестоматийный, широко признанный реальный пример именно того явления, которое описывает модель, — сенсорный интерфейс оригинального iPhone, представленного Apple в 2007 году. Мультитач-управление жестами (тап, смахивание, сведение/разведение пальцев для масштабирования) на момент выхода воспринималось как нечто поразительное — классическая восхищающая характеристика (delighter): большинство пользователей смартфонов даже не формулировали такую потребность, но были искренне впечатлены, столкнувшись с ней. Уже через несколько лет, когда конкуренты (Android-производители и другие) массово внедрили аналогичные сенсорные интерфейсы, рынок пересмотрел стандарт — то, что было приятным сюрпризом 2007 года, к началу 2010-х стало базовой, само собой разумеющейся характеристикой (must-be): смартфон без сенсорного экрана сегодня воспринимается как неполноценный продукт, а не как продукт с одной отсутствующей приятной опцией. Это ровно то, что модель называет «распадом категорий» (category decay) — сегодняшний восхищающий элемент неизбежно становится завтрашним базовым ожиданием.
Не все улучшения продукта равны: одни делают клиента чуть более довольным, другие — при своём отсутствии — делают его яростным, а при наличии остаются попросту незамеченными.
Происхождение и исследовательская база
Модель разработана профессором Нориаки Кано (Токийский университет Рика) в 1984 году на основе исследования нелинейной связи между наличием характеристик продукта и удовлетворённостью клиента, опубликована в статье "Attractive Quality and Must-be Quality". Методика получила широкое распространение в управлении продуктом как способ приоритизации функций через структурированный опрос клиентов (парные вопросы: "как вы отреагируете, если функция ЕСТЬ" и "как вы отреагируете, если функции НЕТ").
Ключевые идеи и принципы
Принцип: Базовые характеристики (must-be)
Характеристики, которые клиент считает само собой разумеющимися — их наличие не повышает удовлетворённость (клиент просто не жалуется), но их отсутствие вызывает сильное недовольство. Пример: рабочий тормоз в автомобиле.
Принцип: Желаемые характеристики (performance)
Характеристики с линейной зависимостью — чем больше/лучше, тем выше удовлетворённость, и наоборот. Пример: расход топлива автомобиля — чем экономичнее, тем довольнее клиент, и это можно улучшать постепенно.
Принцип: Восхищающие характеристики (delighters)
Характеристики, которых клиент не ожидал и не просил — их отсутствие не расстраивает (клиент о них не знал), но их наличие вызывает восторг и создаёт сильную эмоциональную привязанность. Со временем восхищающие характеристики становятся ожидаемыми (миграция качества вниз по модели).
Принцип: Индифферентные и обратные характеристики
Не все функции попадают в три основные категории — индифферентные не влияют на удовлетворённость вовсе (тратить на них ресурсы бессмысленно), обратные (reverse) снижают удовлетворённость части клиентов при их наличии (для них это лишняя сложность).
Ограничения, слепые зоны и критика
Классификация характеристики может со временем меняться — то, что было восхищающим вчера (сенсорный экран в телефоне), становится базовым ожиданием сегодня, поэтому опрос нужно периодически повторять, а не проводить один раз навсегда. Опросник Кано требует определённой методологической аккуратности (парные вопросы функциональный/дисфункциональный) — упрощённый вариант (просто спросить "нравится ли вам функция") даёт искажённый результат. Модель также хорошо работает для уже понятных клиенту категорий продукта, но плохо предсказывает реакцию на принципиально новые категории, о которых у клиента ещё нет накопленного опыта ожиданий.
Типовые ошибки
Ошибка 1: Все фичи в бэклоге считаются одинаково ценными.
Команда инвестирует одинаковые усилия в улучшение базовой надёжности и в добавление приятных мелочей, не понимая, что это функции с принципиально разной отдачей.
Как избежать: Классифицировать ключевые фичи по модели Кано перед распределением приоритетов в бэклоге.
Ошибка 2: Ресурсы вкладываются в улучшение уже достаточных базовых характеристик.
Команда продолжает "полировать" функцию, которая уже перешла порог "достаточно надёжно" — дополнительные вложения не повышают удовлетворённость, так как это must-be характеристика с плоской кривой отдачи после минимального порога.
Как избежать: Проверять базовые характеристики на минимально достаточный уровень и не тратить на них ресурсы сверх этого порога.
Ошибка 3: Восхищающие характеристики не пересматриваются со временем.
То, что было прорывной фичей 3 года назад, стало ожидаемым стандартом отрасли, но продукт продолжает преподносить это как конкурентное преимущество.
Как избежать: Периодически повторять опрос Кано — классификация функций смещается со временем, восхищающее становится базовым.
Ошибка 4: Опрос проводится упрощённо, без парных вопросов.
Клиентов спрашивают "нравится ли вам эта функция" вместо правильной пары функциональный/дисфункциональный вопрос — результат не позволяет корректно классифицировать характеристику.
Как избежать: Использовать правильную методологию опроса Кано — оба вопроса (наличие и отсутствие) для каждой характеристики.
Ошибка 5: результаты опроса Кано усредняются по всей клиентской базе без сегментации.
Одна и та же характеристика может быть базовой для одного сегмента клиентов (например, опытных пользователей) и восхищающей для другого (новичков) — усреднение по всей выборке смазывает эту разницу и даёт обманчиво нейтральную, «индифферентную» категорию там, где реально существуют два противоположных, ярко выраженных мнения разных сегментов.
Как избежать: анализировать результаты опроса Кано в разрезе значимых сегментов клиентской базы отдельно, а не только по общей выборке в целом.
Главное, что нужно знать
Модель Кано делит характеристики продукта на базовые (их отсутствие бесит, наличие не радует), желаемые (линейный рост удовлетворённости) и восхищающие (неожиданный восторг). Это меняет приоритизацию бэклога: сначала гарантировать базовые характеристики на достаточном уровне, затем инвестировать в желаемые пропорционально ценности, и отдельно искать восхищающие детали, которые создают эмоциональную лояльность.
План внедрения
Неделя 1: составить список ключевых характеристик продукта для классификации.
Неделя 2: провести опрос Кано с клиентами — парные вопросы по каждой характеристике.
Неделя 3: классифицировать характеристики по категориям (базовые/желаемые/восхищающие/индифферентные).
Неделя 4: пересмотреть приоритеты бэклога с учётом классификации — гарантировать базовые, инвестировать в желаемые, искать восхищающие.
Далее: повторять опрос раз в 1-2 года, отслеживая миграцию характеристик из восхищающих в базовые.
Как реализовать этот план с помощью фрейма Kano Model в OrgDevTools
Фрейм «Модель Кано» построен как сетка из четырёх карточек — ровно четыре категории классификации характеристик продукта: «Базовые (must-be)» (отсутствие бесит, наличие не радует), «Желаемые (performance)» (чем больше/лучше — тем выше удовлетворённость, линейная зависимость), «Восхищающие (delighters)» (клиент не ждал — и был приятно удивлён), «Индифферентные» (не влияют на удовлетворённость — сюда же логически относятся и обратные характеристики, чьё наличие снижает удовлетворённость).
Каждая карточка — свободный список конкретных характеристик продукта, отнесённых к соответствующей категории по результатам опроса Кано (недели 1-3 плана внедрения). Вердикт фрейма явно требует заполнения всех четырёх категорий одновременно — без распределения фич по всем четырём приоритизация бэклога остаётся произвольной, интуитивной (прямая иллюстрация Ошибки 1 из блока Типовых ошибок). Кнопка задачи создаёт задачу на реализацию доработки по приоритету конкретной категории Кано.