В Heads and Hands написали о приоритизации фич по модели Кано.

— Все фичи можно разделить на базовые, желаемые и восхищающие. Первые определяют жизнеспособность продукта, а остальные — его конкурентоспособность;
— Базовые фичи должны быть в продукте по умолчанию. Люди к ним привыкли, раздражаются и перестают пользоваться продуктом, если их нет. Например, отправка и получение электронных писем;
— Желаемые — повышают уровень сервиса и помогают выделиться среди конкурентов. Чем лучше они развиты, тем выше люди оценивают продукт и тем больше готовы платить. При этом они не перестанут пользоваться продуктом, если их нет. Например, облачное хранилище для документов из электронных писем;
— Восхищающие — вызывают вау-эффект и запускают сарафанное радио (92% клиентов доверяют ему больше, чем рекламе), люди не ожидают их увидеть. Например, встроенный сканер документов;
— Чтобы понять, какие фичи к какой категории стоит отнести, можно опросить представителей целевой аудитории (пример анкеты есть в статье);
— В первую очередь надо инвестировать в базовые фичи и доводить их до идеала. Далее надо выбрать и развивать несколько желаемых фич, чтобы продукт стал конкурентоспособным. Потом можно переходить к восхищающим;
— Важно помнить: восхищающие фичи завтра могут стать желаемым, а через несколько лет — базовым.

#prioritization

В 65pixels написали о модели Кано.

— В модели фичи можно разделить на 3 группы: «обязательные» — воспринимаются с безразличием, но пользователь расстроится, если их не будет; «желаемые» — основные функции, их отсутствие огорчает, а наличие радует; «воздействующие» — дополнительные фичи, без которых можно обойтись, но с ними потребитель испытает восторг;
— В первую очередь надо вводить обязательные функции;
— Что можно отнести к желаемым, зависит от целевой аудитории. Если убрать кружочки и стикеры из Телеграма, разочаруются молодые пользователи, которым важно многообразие средств выражения. Пользователи Вотсапа отнесутся к их появлению, скорее всего, спокойно;
— Воздействующие фичи могут набрать популярность и перейти в категорию желаемых, а затем и обязательных. Например, истории Снепчата, ставшие элементом сторителлинга;
— Они не обязательно должны быть частью основной функции продукта. Пример: туристические гайды на сайте Авиасейлс лишь косвенно связаны с покупкой авиабилетов;
— Выяснить, к какой категории относятся те или иные фичи, можно с помощью опроса. В статье есть пример вопросов, а также советы по обработке результатов;
— Опросы особо важны, если вы делаете продукт для групп людей, к которым сами не относитесь.

Ещё о модели Кано писали в Heads and Hands. И если я не ошибаюсь, в комментариях к этой записи доступны любые средства выражения, включая стикеры и кружочки 😉 #research #prioritization

Павел Шерер написал о подходе к приоритизации PoDPR.

— Формула: (Pain ÷ Difficulty) × Probability × Reversibility;
— Боль — выраженность проблемы для пользователя или бизнеса. Сложность — стоимость реализации. Чем больше боль и меньше затраты на её устранение, тем лучше;
— Probability — насколько вероятно, что изменение даст целевой результат. Должно основываться не на вере, а на данных, экспериментах и обратной связи;
— Reversibility — насколько легко откатить решение при провале. Чем выше обратимость, тем смелее можно проверять гипотезы;
— Формула прямо наказывает дорогостоящие, слабообратимые и плохо подтверждённые затеи;
— В статье есть критика других способов приоритизации (MoSCoW, RICE, ICE, Kano Model, WSJF, Value vs Effort Matrix, User Story Mapping, Impact Mapping) и советы, как дополнить их с помощью PoDPR;
— PoDPR не задумывался как жёсткая формула, его сила в способности адаптироваться под контекст компании;
— Например, если важно считать охват новых фич, как в RICE, то Pain можно разложить на Severity (серьёзность проблемы) × Frequency (частота возникновения) × Reach (охват);
— Если критично время, можно добавить аналог Time Criticality из WSJF. PoDPR = (Pain ÷ Difficulty) × Probability × Reversibility × Urgency;
— Если важно учесть масштаб возможного ущерба — коэффициент Blast Radius;
— Если важно выбирать устойчивые и лёгкие в поддержке решения (для платформенных изменений) — коэффициент Sustainability;
— Добавляя коэффициенты, важно задокументировать, кто оценивает, какие источники данных используются, какие артефакты должны подтверждать оценки;
— Возможные значения коэффициентов фиксируются в шкалах с описанием и примерами, какое значение выбирать. Например, для оценки Urgency должны быть конкретные критерии: срок до дедлайна, сезонность, ограниченность окна возможностей;
— Изменения в шкалах допустимы не чаще, чем раз в квартал, чтобы не превращать формулу в инструмент для политических игр.

#prioritization

Илья Безделев написал об одно- и двусторонних дверях при принятии продуктовых решений.

— В двустороннюю дверь можно войти, осмотреться и, если не понравилось, выйти обратно;
— В продукте это решения, которые не приведут к катастрофе и которые можно откатить назад;
— Односторонняя дверь, как турникет в метро, позволяет пройти только в одну сторону;
— Это решения, которые нельзя откатить вовсе, либо это слишком дорого с точки зрения ресурсов, PR, доверия пользователей и так далее;
— Аналогию с дверьми придумали в Амазоне, чтобы было понятно, когда можно быстро принимать решения, а когда важно внимание к деталям;
— Сотрудники, принимающие решения, должны понять, в какую дверь они собираются войти;
— Двусторонние решения принимают без консультации с руководством. Односторонние могут доходить до самого верха.

#prioritization