Приоритизация гипотез после исследования: как выбрать, за что браться

У меня был список на тридцать четыре пункта. Каждый пункт живой инсайт из интервью, каждый чинить хочется, и все ждут, что я скажу, с чего команда начнёт в следующем квартале. Я смотрел на этот список неделю. Взял в итоге тот, что кричал громче всех, и через два месяца выяснил, что он трогал шесть процентов пользователей. Вот с той истории у меня и началась приоритизация гипотез как отдельный навык, а не «на что глаз упал».

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

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

Почему после исследования наступает паралич

Кажется, что тяжёлая часть позади. Разговоры проведены, расшифровки разобраны, боли сведены и посчитаны. Осталось взять и сделать. А на деле команда встаёт именно тут.

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

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

Приоритизация гипотез стоит на четырёх признаках

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

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

Влияние. Что изменится, если это починить. Боль бьёт по деньгам, по удержанию, по конверсии, или это мелкое неудобство, которое человек и так терпит, не собираясь никуда уходить.

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

Уверенность. Насколько ты вообще веришь в остальные три цифры. Боль всплыла у восьмерых из десяти, тут уверенность высокая. Всплыла у двоих, и ты домысливаешь влияние из головы, тут уверенность низкая, и это надо честно учитывать.

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

RICE и ICE: считаем приоритет цифрой

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

ICE попроще. Impact (влияние), Confidence (уверенность), Ease (лёгкость). Каждый оцениваешь по шкале, обычно от 1 до 10, перемножаешь, получаешь балл. Чем выше балл, тем раньше берёшь. Метод грубый, зато его можно накидать за полчаса на салфетке, и для маленькой команды этого часто хватает.

RICE подробнее, его придумали в Intercom и описали в их инженерном блоге. Тут четыре множителя: Reach (охват, скольких людей затронет), Impact (насколько сильно повлияет на каждого), Confidence (уверенность в оценках), и Effort (усилия, которые уходят в знаменатель, потому что чем дороже, тем ниже приоритет). Формула выглядит так:

• Reach — Что означает: сколько людей затронет за период — Как оценивают: число: например, 400 пользователей в месяц
• Impact — Что означает: насколько сильно повлияет на каждого — Как оценивают: 3 огромно, 2 сильно, 1 средне, 0.5 слабо
• Confidence — Что означает: насколько веришь в свои оценки — Как оценивают: 100% высокая, 80% средняя, 50% низкая
• Effort — Что означает: сколько человеко-месяцев на решение — Как оценивают: число: например, 2 человеко-месяца

Считается как Reach × Impact × Confidence, всё это делённое на Effort. Итог, число, по которому выстраиваешь список. Штука в том, что RICE заставляет тебя проговорить каждый фактор вслух и обосновать, а не держать смутное «ну это вроде важное» в голове. Половина ценности метода не в самой цифре, а в споре, который случается, пока команда её выставляет.

Оговорюсь честно: цифры тут полу-выдуманные, и это все понимают. Impact «2 или 3» ты ставишь на глаз, Reach прикидываешь. RICE не даёт объективной истины, он даёт общий язык, чтобы спорить предметно, а не «мне кажется важнее». Я сам первое время относился к нему как к магии точных чисел, и зря. Это калькулятор для разговора, а не оракул.

Матрица impact/effort: когда считать лень

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

• Высокое влияние, низкие усилия. Это «быстрые победы», их берут первыми, тут и думать нечего.
• Высокое влияние, высокие усилия. Крупные проекты, их планируют осознанно, под них выделяют квартал.
• Низкое влияние, низкие усилия. Мелочь на потом, между делом, если руки дойдут.
• Низкое влияние, высокие усилия. Сюда лучше не лезть вообще, это ловушка.

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

Главная ошибка: берут громкое, а не частое

Расскажу, чем закончился тот список на тридцать четыре пункта, потому что урок оттуда я до сих пор ношу.

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

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

Есть и обратная оговорка, чтобы не впасть в другую крайность. Иногда боль всплыла всего у двоих, но это боль, за которую платят прямо сейчас, и она весит больше нытья восьмерых про мелочь, которую они и так терпят. Так что частота это не диктатор, а первый фильтр. Дальше к ней добавляешь влияние и смотришь, что человек СДЕЛАЛ из-за боли: искал решение, платил за костыль, городил обход. Поведение перевешивает и громкость, и частоту.

Вторая ошибка помельче, но встречается не реже: приоритизируют инсайт, а не связку «инсайт → решение → метрика». Об этом дальше.

Свяжи инсайт с решением и метрикой, иначе это не приоритет

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

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

Выглядит это примерно так:

Инсайт: 6 из 10 бросают отчёт из-за долгой выгрузки.
Решение: кэшировать последний отчёт, отдавать мгновенно.
Метрика: доля дошедших до экспорта, следим за ней после релиза.

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

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

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

Я делаю в два прохода. Первый грубый: прогоняю весь список через матрицу impact/effort и безжалостно выкидываю всё, что в квадранте «низкое влияние, высокие усилия», плюс отправляю в дальний ящик мелочь. От сорока обычно остаётся десять-двенадцать реальных кандидатов. И только эту короткую пачку прогоняю через RICE, где уже не жалко потратить время на аккуратные оценки.

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

Где в этом помогает Aski

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

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

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

Коротко

Приоритизация начинается там, где кончается анализ: выводы есть, а рук на всё нет. Сортируешь инсайты по четырём вещам, частота, влияние, усилия, уверенность, и прогоняешь через рамку. ICE для быстрой прикидки, RICE когда нужен общий язык для спора, матрица impact/effort когда считать лень и надо просто разгрести завал. Главная ошибка, брать самое громкое вместо самого частого: одна яростная история весит в голове больше восьми спокойных, а по данным всё наоборот. И приоритизируй не голый инсайт, а связку с решением и метрикой, иначе оценивать нечего. Фреймворки тут не оракулы, а калькуляторы для честного разговора, вся их польза в том, что они заставляют проговорить вслух то, что ты обычно решаешь на глаз.

FAQ

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

Что лучше выбрать, RICE или ICE? Зависит от масштаба. ICE проще, три множителя, накидывается за полчаса, его хватает маленькой команде и ранней стадии. RICE подробнее, добавляет охват и усилия отдельными числами, он полезнее, когда решений много и надо предметно спорить о ресурсах. Я обычно начинаю с грубой матрицы, отсеиваю балласт, а RICE достаю только для десятка спорных кандидатов в верхнем ряду.

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

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

С чего начать приоритизацию, если инсайтов набралось несколько десятков? Не ранжируй всё сразу, это невозможно честно. Первым проходом прогони весь список через матрицу impact/effort и выкинь то, что в квадранте «дорого и бесполезно», а мелочь отправь в дальний ящик. Останется десять-двенадцать кандидатов, и вот их уже прогоняй через RICE аккуратно. Делай это не в одиночку: чужие вопросы к твоим оценкам вскрывают подгонку под любимую идею.

Источники

• Как анализировать результаты интервью. Предыдущий шаг: как из расшифровок дойти до инсайтов с частотой, которые потом приоритизируешь.
• Отчёт по исследованию. Куда попадает приоритизированный список: раздел рекомендаций с разбивкой «чинить сейчас, взять в план, отложить».
• Как проверить гипотезу продукта. Про формулировку проверяемых гипотез, без которых приоритизировать нечего.
• RICE scoring: как приоритизируют в Intercom. Наш разбор первоисточника фреймворка RICE. Оригинал указан внутри пересказа.