Как не пилить фичи, которые никому не нужны? Модель Кано в разработке.

Вот и отпуск прошел, пора возвращаться к работе...

Сейчас я работаю над AG2 и пытаюсь make this project great again. В общем, составляем родмап для фич.

И в этом мне сильно помогает модель Кано, которую я изначально подсмотрел у Дорофеева. Максим в своей книге адаптировал 5 категорий "фич" под продуктивность. Но это только подтверждает состоятельность методолгии – ведь ее можно применять к любой области!

Итак, 5 категорий фич (задач) по Дорофееву (Кано):

🤩 1. Ублажители (Delighters)
Это те самые "вау-фичи". Их никто не ждет, но их минимальное наличие вызывает восторг.

- Пример: AI-ассистент в документации, который отвечает на вопросы. Или забавная анимация загрузки. FastStream, который сам генерирует документацию для сервиса.
- Суть: Пользователь не расстроится, если их нет (он их может даже не ожидать), но будет в восторге, если они есть. Хотя, может быть и сильным конкурентным преимуществом.

✅ 2. "Должно быть" (Must-be)
Это базовые, ожидаемые вещи. Если они работают хорошо, этого никто не замечает. Но если они сломаны — удовлетворенность пользователя падает до нуля.

- Пример: Кнопка "Сохранить" действительно сохраняет. pip install вашего пакета работает без ошибок. API отдает валидный JSON.
- Суть: Их наличие не радует, но их отсутствие или плохая работа — это катастрофа. Это фундамент, на котором все строится.

🚀 3. "Больше — лучше" (Performance)
Здесь все просто: чем лучше реализация, тем выше удовлетворенность.

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

🤷‍♂️ 4. Нейтральные (Indifferent)
Пользователям на них все равно. Вы можете потратить недели на их реализацию, но никто этого не оценит.

- Пример: 15-й способ кастомизации цвета кнопки в настройках, которым воспользуются 0.01% пользователей.
- Суть: Чистая трата ресурсов. Главная задача - научиться распознавать их до начала разработки.

🤬 5. Реверсивные (Reverse)
Фичи, наличие которых ухудшает пользовательский опыт. Да, и такое бывает.

- Пример: Обязательная регистрация для того, чтобы воспользоваться простейшей утилитой. Слишком сложный и запутанный UI там, где все могло быть просто.
- Суть: Это выстрел себе в ногу. Такие фичи не просто не приносят пользы — они вредят.

Как это применить на практике?

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

- Это "ублажитель", который можно сделать потом, или "должно быть", без которого все развалится?
- Мы сейчас улучшаем метрику "больше — лучше" или пилим "нейтральную" фичу, которая никому не нужна?
- А не создаем ли мы "реверсивную" фичу, которая только усложнит жизнь пользователю?

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

А теперь вопрос в зал: какая самая бесполезная или даже "реверсивная" фича, которую вам приходилось делать?🌚

#программирование #продуктивность #карьера #дорофеев