В продуктово-исследовательском мире есть 2 проблемы
1. Хаотично пополняющийся бэклог исследователя
2. ТТМ (Time to market) продукта, которому необходимо сократить этап discovery (поиска и анализа)
Продукт приходит с просьбой провести исследование "надо вчера, возьмите в работу, ну пожалуйста", а исследователи уже загружены “по полный скворечник” и начинается перебрасывание задач.
Для лечения таких проблем можно использовать разные инструменты. Например, можно обучить команду самостоятельной проверке небольших гипотез. Можно и нужно взращивать исследовательскую культуру. Можно диктаторски ввести жесткие правила по срокам. Но всё это не очень работает, если не налажен процесс планирования исследовательского бэклога и оценки критичности задач на исследования. С этого и начнем.
Почему так как сейчас — не работает? Ретро
Прежде чем выстраивать процесс планирования, проведите ретроспективную встречу (ретро) с продуктом на тему "почему так как сейчас — не работает". Предположим, вы уже провели ретро с продуктом, вы даже поругались, кидая друг другу претензии, но тут важно услышать:
в какой парадигме и каких инструментах живет продукт;
(где команда планируется и ставит задачи, так как их основной их фокус и приоритеты там)какие у него цели;
что ему непонятно, неочевидно и сложно в ваших процессах и артефактах;
что совершенно не совпадает в ваших процессах с процессами продукта;
где продукт и где вы можете пойти на встречу друг другу.
Внимание! Очень важно зафиксировать всё это, договориться, как будете исправлять, кто и что делает к какому дедлайну.
В нашем случае, мы выяснили, что продукт живет в таск-трекере — целиком и полностью: формирует OKR (objective key results), планирует бэклог, ставит задачи, смотрит аналитику по ним и т. п., а мы ведем свой бэклог и нагрузку в таблицах. Из этого подтянулись две проблемы:
Не помню/понимаю, где посмотреть задачу или как добавить задачи на исследования = не знаю какая очередь и пишу запросы в личку ASAP.
Работаю в таск-трекере = веду задачи там, все тригеры о том, что надо своевременно завести задачу на исследование тоже там. Нет задачи - Нет работы.
Поэтому решение о переезде с “табличек” в таск-трекер стало безоговорочным (кстати, если вы ещё не там — зря, зря, зря, очень удобно).
К тому же продукту не всегда понятно, когда надо заходить за исследованием, а когда нет, и какая исследовательская команда нужна под задачу — UX*, маркетинг, стратегия, аналитика. В нашем случае, это все отдельные исследовательские команды с разными зонами ответственности. Тут решений появилось сразу несколько:
Завели гейты (обязательные этапы) на исследования в продуктовом бизнес-процессе трекера задач на этапах Discovery и Post Launch.
К имеющимся описаниям на Confluence решили записать отдельно онбординг-обучение по исследовательским командам (кто чем занимается) на внутренней образовательной платформе.
Стали заходить на продуктовую защиту бэклога, где мы подсвечиваем потенциальные задачи на исследования и защищаем свой бэклог.
* UX-исследования в Rustore представлены двумя ветками — discovery и delivery, но это кейс для отдельной статьи. Для контекста:
Discovery — если нужно изучить потребности и ожидания пользователя; найти новые идеи для развития продукта или фичи; понять ценность конкретных идей для пользователя; понять, как реализовать продуктовое решение; после запуска собрать обратную связь и потребности, если видно из аналитики, что реализованная фича не решает задачу пользователя. В основном в discovery research обращаются, если еще нет готового интерфейса. Но могут быть запросы и с использованием интерфейса, если цели исследования предполагают поиск лучших практик, оценку важности и актуальности фич, дальнейшее развитие продукта.
Delivery — если нужно проверить, насколько готовый дизайн/прототип решает задачи пользователя; оценить экспертно готовый дизайн до разработки в случае сжатых сроков; выбрать, какое из нескольких интерфейсных решений эффективнее; посмотреть динамику после доработки интерфейса; понять причины, по которым пользователи уходят, не совершив целевое действие в интерфейсе. Delivery research работает исключительно с интерфейсом и может привлекаться как до разработки фичи, так и после ее запуска.
Ок, починились, но рельсы все равно стелим под несущийся поезд
Переехали в таск-трекер, создали исследовательский проект.
При заведении таски на исследование стейкхолдер указывает месяц, в который желательно получить исследование и приоритетность (высокий, средний, низкий), насколько критично провести исследование. В итоге мы женим сроки с критичностью и выстраиваем очередь. И, вроде бы, вагончик уже тронулся по рельсам, но все время возникали вопросы или все равно влетали ASAP-запросы:
"Как мне оценить, насколько важно завести задачу на исследование?"
"По какому принципу построена ваша очередь? Я ведь первый завел таску!"
Здесь мы предложили в помощь 3 шага:
Оценить, соотносится ли задача со стратегическим вектором продукта.
Проверить, касается ли запрос ключевого пользовательского сценария.
Подсчитать RICE (фреймворк приоритизации бэклога).
Стратегический вектор и критичность пользовательского сценария
Со стратегией все относительно понятно. Стратегический вектор идёт от задач бизнеса. Чтобы оценить, соотносится ли задача со стратегическим вектором продукта надо задаться, как минимум, двумя вопросами:
Насколько стратегически важной является задача с точки зрения развития бизнеса и продукта?
Повлияет ли задача на значимые улучшения ключевых целей бизнес-юнита?
С критичностью не всё так однозначно, поэтому мы снова вернулись к совместной проработке процесса с продуктом.
В первую очередь мы составили список всех ключевых пользовательских сценариев и подсценариев продукта и вывели оценку их критичности на пересечении UX и бизнеса от 0 до 1 (0 - не критичный сценарий, 1 - критичный): UX оценивает сценарий с точки зрения пользовательских задач и их сензитивности, бизнес опирается на продуктовые метрики и стратегический вектор.
Условно:
Авторизация в нашем магазине приложений с точки зрения UX — не самый критичный сценарий: приложением можно пользоваться без неё, но при этом не будет возможности совершать покупки. То есть задачу "пользоваться приложением, искать приложения, скачивать бесплатные" этот сценарий не блокирует, но блокирует другие задачи. Поэтому мы оценили сценарий на 0.8 из 1. Бизнес оказался солидарен с нами в этой оценке: хоть сценарий и не блокирует описанные задачи, он блокирует другие — приносящие нам выручку или аудиторию.
Поиск приложений — наш ключевой сценарий: пользователь не может решить задачи в контексте этого сценария или сталкивается со сложностями, ценность нашего продукта для него исчезает. Поэтому балл - 1.
Оплата — всегда чувствительный сценарий. Проблема в интерфейсе, логике = фаталити пользовательского опыта и доверия к продукту. Тут тоже единогласно с продуктом - 1.
Онбординг — для UX низко критичный сценарий, мы его оцениваем на 0.2, зато для бизнеса он весит больше - 0.4, т.к. помогает продавать фичи.
UX ставит балл, бизнес ставит свой балл, выводим среднее.
Получается список пользовательских сценариев, из которых можно понять их критичность как для бизнеса, так и для пользователя. Это также позволяет понять важность фокуса внимания на изменениях в конкретных сценариях.
Спойлер — этот список можно использовать как чек-лист и для других задач и процессов.
Критичность исследования
Для определения критичности можно отталкиваться от принципов метода знакомого и понятного в продуктовом мире: RICE или ICE. Подойдет и другой, но именно RICE и ICE хороши тем, что команда обсуждает количественную оценку своего уровня уверенности в полезности разрабатываемой фичи или доработки. А именно это-то нам и надо — помочь продукту там, где он не уверен.
Reach (охват) — сколько пользователей получат пользу от функциональности за определенный период времени.
Скольких пользователей затронет функциональность, для которой необходимо исследование? Если мы говорим о том, что делаем фичу или вносим изменения для незначительного количества пользователей, это не значит, что в исследовании нет необходимости, но критичность его проведения сильно снижается. Если мы говорим о фиче или изменении для значительной доли пользователей, критичность проведения исследования повышается.Чем большего числа пользователей касается создание фичи или изменения в интерфейсе, тем выше критичность.
Impact (влияние) — какой вклад приносит эта фича продукту, насколько помогает достигать целей продуктовой команды.
Как сильно повлияет на пользователей вводимая/изменяемая функциональность, для которой необходимо исследование?Чем сильнее предполагаемое влияние, тем критичнее проведение исследования.
Confidence (уровень уверенности в оценках) — чем подкреплены оценки этих параметров.
Насколько мы уверены, что вводимая функциональность будет полезна или не испортит пользовательский опыт? Выполненные ранее исследования, например, как раз повышают нашу уверенность.Чем ниже уверенность, тем выше критичность проведения исследования.
Effort (усилия)— сколько итераций, недель, сторипоинтов или трудозатрат в другой форме понадобиться для запуска.
Сколько времени и сил уйдет на разработку функциональности или изменений, для которой требуется исследование? Гораздо дешевле провести исследование и понять, что функциональность не нужна или изменения не принесут пользы, чем потратить ресурсы разработки и понять это.Чем больше трудозатрат требуется на разработку, тем выше критичность проведения.
Может оказаться так, что RICE оказался высоким, но исследование не горит.
В таком случае, при заведении задачи руководствуемся сроками, когда необходимо получить результаты исследований.
Почитать подробнее про эти методы приоритезации можно в статье RICE и ICE Scoring: простые техники приоритизации для продвинутых менеджеров продукта.
Скользим по рельсам и почти не ругаемся
Сейчас мы наладили процесс, положили рельсы и наш поезд по ним скользит практически бесшовно. Понятно, что продукт и процессы живут довольно гибко — невозможно зафиксироваться и ожидать, что теперь всё всегда будет ровно так, но тем и интереснее. А пока наш процесс пополнения бэклога, чтобы долго в нем не стоять, выглядит так:
Очередь на исследования формируется сразу за планированием продуктового бэклога (в нашем случае в первые две недели каждого квартала).
При заведении таски* стейкхолдер заполняет 3 поля, которые нам необходимы для построения очереди:
месяц, в который должны быть получены результаты в названии таски (plan start plan end уже выставит исследователь на формировании очереди);
квартал (в поле "Исправить в версии");
приоритет (высокий, средний, низкий);
для определения приоритетности и необходимости учитывает: стратегический вектор продукта, оценку критичности пользовательского сценария, RICE
*В таске стейкхолдер также:
- указывает продуктовое направление, для которого требуется исследование;
- даёт краткое описание задачи, чтобы мы понимали её контекст (сам бриф будет позже);
- помечает задачу как discovery или delivery;
- вкладывает эпик, в рамках которого проводится исследование, и/или связи с другими исследованиями.
Дальше мы переходим к формированию очереди.
Первый этап
Список претендентов на квартал ранжируется по перечисленным выше критериям:
от наиболее срочных с высоким приоритетом
→ к наименее срочным с наименьшим приоритетом.
Второй этап
Исследователи уточняют запросы из тасок и могут объединять их в группу (если в запросах одна ЦА и близкие сценарии). То есть исследователь определяет, сможет ли взять в работу одновременно несколько запросов, которые уместно объединить в один по целевой аудитории, сценариям и таймингу. Такое объединение тасок помогает нам охватить больше запросов и сэкономить ресурсы команды.
После этого очередь корректируется по тому же принципу, что и на первом этапе. Так, задачи с меньшим приоритетом или менее срочные могут подняться вверх по очереди:
от наиболее срочной с наиболее высоким приоритетом таски в группе
→ к наименее срочным с наименьшим приоритетом таскам или группам тасок.
Третий этап
Защита бэклога: финально согласовывается очередь на квартал.
Её можно посмотреть в структуре проекта в трекере.
У нас это выглядит примерно вот так:
Актуализация
В течение квартала планы продукта могут меняться: исследования отменяются или переносятся. В таких случаях мы можем либо поднять в очереди следующее исследование, либо взять в работу исследование вне плана.
Бонусный контент
После переезда в трекер задач и проработки процесса приоритизации задач, нам удалось не только ставить исследования на поток, но и стать прозрачнее для команды. Мы можем подсветить:
вместимость задач в исследовательский бэклог (этим можно обосновать необходимость ресурсов для команды);
в каких этапах и коммуникациях есть сложности между продуктом и исследователями (например, долгая подготовка прототипов, вытекающая из согласований с продуктом).
Ключевые сценарии и их критичность, которые мы сформулировали для одной конкретной задачи, могут быть использованы для:
Оценки размера UX-долга, который необходимо взять в работу.
Пример.
N-доля критических проблем в ключевых сценариях с оценкой критичности выше Х должна быть обязательно принята в работу.Привлечения к исследованию респондентов с ограниченными возможностями здоровья (accessibility-чек).
Пример.
К тестированию ключевых сценариев с оценкой критичности выше Х необходимо привлекать респондентов с особенностями визуального восприятия, например, астигматизмом или дальтонизмом.
Об этом опыте обязательно расскажем в следующих сериях.
Спасибо за ревью статьи перед публикацией Юлии Кожуховой (Head of research, TBC Uzbekistan x payme) и Олег Афанасьев (CPO, RuStore).
Екатерина Бессчётнова
Руководитель отдела UX-исследований RuStore
