‼️ Методология анализа требований: Kano Model ‼️ Привет, коллеги! Сегодня поговорим о методологии, которая помогает аналитикам эффективно приоритизировать функционал продукта. Речь пойдет о Kano Model — инструменте, который позволяет классифицировать требования на основе их влияния на удовлетворенность пользователей. За 10 лет работы системным аналитиком я не раз убеждался, что Kano Model — это не просто теория, а мощный практический инструмент для принятия решений. Модель Kano была разработана японским профессором Нориаки Кано в 1980-х годах. Она помогает понять, как различные требования влияют на удовлетворенность пользователей продуктом. Согласно модели, все требования можно разделить на пять категорий : ⭐️ Базовые требования (Must-be Quality) Это минимальные ожидания пользователей. Если они не выполнены, пользователи будут крайне недовольны. Однако их выполнение не вызывает особого восторга — это просто "должно быть". Пример: В мобильном приложении библиотеки базовым требованием может быть возможность поиска книг по названию или автору. Без этой функции приложение будет считаться неработоспособным. ⭐️ Требования производительности (Performance Quality) Эти требования напрямую влияют на удовлетворенность пользователей: чем лучше они реализованы, тем выше уровень удовлетворенности. Пример: Скорость загрузки страницы или удобство интерфейса. Чем быстрее работает приложение и чем проще им пользоваться, тем больше шансов, что пользователи останутся довольны. ⭐️ Требования привлекательности (Attractive Quality) Это "вау-эффект". Такие требования не являются обязательными, но их реализация вызывает сильную положительную реакцию у пользователей. Пример: Функция рекомендации книг на основе предпочтений пользователя. Она может стать уникальной фишкой вашего приложения. ⭐️ Неактуальные требования (Indifferent Quality) Эти требования не оказывают значительного влияния на удовлетворенность пользователей. Они могут быть полезны для бизнеса, но пользователи их либо не замечают, либо не ценят. Пример: Добавление сложной аналитики использования приложения, которая интересна только внутренним командам. ⭐️ "Вредные" требования (Reverse Quality) Иногда добавление новых функций может негативно сказаться на удовлетворенности пользователей. Это происходит, когда функционал усложняет использование продукта. Пример: Слишком много рекламы в бесплатной версии приложения может отпугнуть пользователей. ‼️ Как использовать модель Kano для приоритизации функционала? 📌 Определите список требований. 📌 Соберите все идеи и предложения от заинтересованных сторон (заказчиков, пользователей, команды разработки). 📌 Классифицируйте требования. 📌 Проведите опрос или интервью с пользователями, чтобы понять, как они воспринимают каждое требование. Например: Если функция отсутствует, как это повлияет на ваше восприятие продукта? Если функция есть, как она повлияет на ваше восприятие? 📌 Распределите требования по категориям. На основе ответов распределите требования по категориям Kano. Приоритизируйте. Сначала реализуйте базовые требования — без них продукт не будет работать. Затем сосредоточьтесь на требованиях производительности, которые напрямую влияют на удовлетворенность. Добавьте привлекательные требования , чтобы выделиться среди конкурентов. Отложите или исключите неактуальные и "вредные" требования. Практическое задание 👨‍🔧 Представьте, что вы работаете над мобильным приложением для библиотеки. Вот список возможных функций: 1. Поиск книг по названию, автору или жанру. 2. Возможность читать книги офлайн. 3. Персонализированные рекомендации книг. 4. Интеграция с социальными сетями для обмена цитатами. 5. Уведомления о новых поступлениях книг. 6. Возможность оставлять отзывы и ставить оценки книгам. 7. Голосовой поиск книг. 8. Анимации при перелистывании страниц. 9. Поддержка нескольких языков интерфейса. 10. Размещение рекламы внутри приложения. Задание: Распределите эти функции по категориям Kano (базовые, производительные, привлека