Материал статьи

Модель Кано помогает приоритизировать функции не только по стоимости и срокам, но и по тому, как они влияют на удовлетворённость пользователя. В базовой версии функции разделяют на обязательные, линейные, привлекательные, безразличные и нежелательные. Поэтому в бэклог попадает не просто список пожеланий, а гипотеза о реакции человека на наличие или отсутствие конкретного свойства.

Модель Кано: как приоритизировать функции продукта и сайта: основная иллюстрация

Визуальная схема ключевых элементов темы.

Оглавление

Модель Кано помогает понять, что именно произойдёт с восприятием продукта, если добавить или убрать функцию. Её ценность не в красивой классификации, а в паре вопросов о наличии и отсутствии свойства. Так команда отличает базовое ожидание от приятного сюрприза и не ставит все идеи в очередь только по громкости запроса. Для сайта это может быть сохранение формы, для сервиса — прозрачный статус заказа, для внутреннего продукта — история изменений.

Кано не заменяет оценку стоимости, риска, закона и бизнес-цели. Это способ получить гипотезу о пользовательской реакции и связать её с решением в бэклоге. Ниже — практический порядок: как выбрать функции, провести опрос, обработать противоречия, а затем соединить вывод с дорожной картой и проверкой после релиза.

Когда применять модель Кано

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

Кано плохо подходит для требований, которые нельзя обсуждать как вариант: обязательные меры безопасности, юридические условия и исправление критической ошибки должны пройти отдельный контур. Если функция нужна для соблюдения закона, низкая эмоциональная оценка не является основанием её отложить. Точно так же опрос не заменяет наблюдение, когда люди не могут точно описать привычное поведение.

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

Пять категорий пользовательской реакции

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

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

Сочетание функционального и дисфункционального вопроса

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

Не смешивайте в одном вопросе два результата. «Получать быстрый и подробный отчёт» объединяет скорость и содержание; по ответу нельзя понять, что именно важно. Разделите свойства, если по ним принимаются разные продуктовые или технические решения.

Как выбрать функции для исследования

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

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

Что зафиксировать до опроса

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

Как составить вопросы

Описывайте пользу и ситуацию, а не внутреннюю технологию. Вместо «включить GraphQL-кеш» спросите: «Как вы отнесётесь к тому, что список обновляется без повторной настройки страницы?» Сначала дайте короткий контекст, затем один функциональный и один дисфункциональный вопрос. Не подсказывайте оценку словами «современный», «удобный» или «необходимый».

Показывайте ограниченное количество карточек за один сеанс и проверяйте понимание формулировки на нескольких участниках. В конце оставьте поле для объяснения. Числовой выбор показывает направление, а комментарий может выявить скрытое условие: например, сохранение черновика нужно только при нестабильном соединении.

Модель Кано: как приоритизировать функции продукта и сайта: процесс работы

Последовательность работы и точки принятия решений.

Как собрать и обработать ответы

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

Победившая категория — ориентир, а не приговор. Сохраните доли ближайших вариантов, размер выборки, сегмент, дату и версию вопроса. Если ответы разделились, проверьте, не связана ли разница с частотой задачи, ролью или каналом использования. Участник, который раз в месяц выгружает отчёт, и оператор, который делает это каждый час, могут честно дать разные оценки.

Как читать неоднозначный результат

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

Как перевести результат в приоритет

Категория Кано не учитывает трудоёмкость, влияние на доход, операционные расходы и технический риск. Добавьте к результату отдельные поля: критичность сценария, доказательность проблемы, стоимость, зависимости, риск поддержки, способ проверки и требование к откату. Обязательное свойство может попасть в ближайший релиз из-за риска отказа, а привлекательное — в ограниченный эксперимент.

Пример: у формы заявки есть три идеи. Сохранение введённых данных классифицировано как базовое, подсказка по формату телефона — как линейное улучшение, а автоматический подбор отделения — как привлекательное. Если сохранение требует небольшой доработки и снижает риск потери заявки, его можно взять первым. Подбор отделения сначала проверяют на части трафика, потому что неверная подсказка создаст новый барьер.

Поля решения для бэклога

В карточке оставьте категорию, сегмент, аргументы, ограничение и следующий шаг. Формулировка «сделать функцию» недостаточна; лучше написать «проверить сохранение черновика на сценарии длинной заявки, измерить долю повторного ввода и пересмотреть решение после периода наблюдения». Так команда понимает, какая гипотеза проверяется и когда решение может измениться.

Что делать с сегментами и изменением ожиданий

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

Категории меняются из-за привычки, конкуренции, устройства, законодательства и роста сценария. Пересматривайте их после заметного изменения продукта, аудитории и рыночного контекста. Сравнивайте не только ответы, но и фактические признаки: время выполнения задачи, обходы, отказы, обращения и повторное использование.

Модель Кано: как приоритизировать функции продукта и сайта: проверка результата

Контрольные точки для проверки внедрения и результата.

Ошибки и рабочий пример

Первая ошибка — считать Кано рейтингом важности. Обязательная функция может не радовать, но её нельзя убрать. Вторая — спрашивать о решении вместо пользовательского результата. Третья — назначать приоритет по одной категории, игнорируя цену и риск. Четвёртая — выдавать результат небольшой или несопоставимой выборки за универсальную истину.

Для рабочего примера возьмите экран оплаты. Команда рассматривает автозаполнение реквизитов, понятное сообщение об отклонённой карте и новый декоративный переход. Сначала разложите свойства по отдельным карточкам и проверьте, кто сталкивается с ошибкой. Затем задайте обе части вопроса, сохраните комментарии и оцените технические зависимости. В решении укажите, что исправляется обязательно, что проверяется экспериментом, а что отложено без обещания эффекта.

Критерии готовности и повторная проверка

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

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

Частые вопросы

Можно ли применить Кано без большого исследования?

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

Обязательная функция всегда должна быть первой?

Не автоматически. Сначала учтите безопасность, закон, риск отказа, стоимость и зависимости. Кано объясняет характер ожидания, но не заменяет решение о последовательности работ.

Что делать, если у функции две почти равные категории?

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

Как часто повторять опрос?

После существенного изменения продукта, аудитории или рыночного контекста. Для стабильного сценария достаточно пересмотра по заранее выбранному сигналу, а не календарной процедуры ради самой процедуры.

Где модель Кано помогает при создании сайта?

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

Как обсуждать результат с командой

На встрече показывайте не только итоговую букву, но и исходный сценарий, формулировку вопроса, сегмент и ограничения. Попросите участника продукта описать, какое решение следует из данных, а инженера — какие зависимости меняют стоимость. Если команда не может связать категорию с действием, исследование ещё не закончено. В протоколе отделяйте факт, интерпретацию и дальнейшую гипотезу.

Полезно заранее подготовить три варианта: сделать сейчас, проверить малым экспериментом и отложить. Для каждого укажите, что должно произойти, чтобы перейти в другую колонку. Так обсуждение не превращается в голосование за любимую функцию. Критика формулировки также важна: если участник понял вопрос иначе, исправьте вопрос, а не объясняйте ему «правильный» ответ.

Решение после исследования

Итог встречи оформите так, чтобы участник, не знакомый с обсуждением, понял связь между ответами и действием. Укажите выбранную категорию, уверенность, ограничение выборки, стоимость проверки и дату пересмотра. Если функция зависит от другого изменения, это должно быть видно в карточке, а не всплывать на планировании. Такой формат защищает команду от повторного опроса без новой информации.

Похожие материалы