Привет! Меня зовут Юлия Тарасенко. За 6 лет работы в Контуре я занималась созданием процессов в двух направлениях — в коммерческом продукте и в инфраструктурном направлении. Объединяет направления их масштаб — более 5 подкоманд, десятки заказчиков, а различает степень зрелости исследовательской культуры.
Я решила разобраться:
-
что включают в себя исследовательские процессы
-
какие из них можно и нужно выстраивать
-
нужно ли браться за все одновременно и в какой момент
-
какие из процессов наиболее важны.
В статье делюсь этими рассуждениями и своим опытом в выстраивании ключевых, на мой взгляд, процессов.
Исходные состояния команды
Когда мы говорим о создании нового процесса, важно помнить, что, как и в большинстве своих задач, нужно идти от потребности. На моей практике потребности продуктов, процессы, которые мне важно было наладить, и шаги, которые я предпринимала, зависели от стадии развития исследовательской культуры в команде.
Я выделила такие варианты исходного состояния исследовательской культуры в продукте:
-
У продуктовой команды появляется интерес к исследованиям, но ценность их не до конца понятна → нужно помочь продукту осознать необходимость в исследованиях и исследовательских компетенциях
-
В продукте проводятся исследования, но не системно, не всем и не всегда понятна ценность, не всегда применяются результаты → нужно систематизировать проведение исследований и популяризировать их
-
В продукте внедрены исследования и их ценность понятна, результаты применяются в развитии продукта → нужны новые процессы вокруг организации и планирования исследований и улучшение текущего подхода к ним
Далее, опираясь на свой опыт, расскажу, как можно подойти к выстраиванию процессов в зависимости от ситуации в продукте.
Продукт не понимает, нужны ли ему исследования, исследовательские компетенции, исследователь в команду
Шаг 1
Провести аудит состояния продукта, выявить боли и проблемные области, в которых нужны компетенции исследователя. В этом помогают интервью с разными ролями в команде, основные – продакты, аналитики, менеджеры разработки.
Примерные вопросы, которые я задавала:
-
Есть ли понимание, кто ваша целевая аудитория и пользователи, какие задачи решает пользователь в продукте?
-
Понимаете ли вы, как сегментировать пользователей? Важно ли это для вас и почему?
-
Понимаете ли вы, куда развивать продукт? Учитываете ли вы потребности пользователей при развитии продукта?
-
Как аналитики получают информацию о сценариях пользователей для написания постановок? Опираются ли на сценарии при решении задач?
-
Оцениваете ли вы реализованную функциональность, как вы понимаете, что сделали нужную фичу? Как вы понимаете, нужно ли ее развивать дальше?
-
Понимаете ли вы как пользователи оценивают ваш продукт, какие у них боли?
Можно сначала выслушать людей, узнать их трудности, а потом уже уходить в детали и проверять конкретные гипотезы.
Шаг 2
Оценить варианты решений, которые могут закрыть боли команды. Не стоит фокусироваться только на исследованиях. Как правило, вариантов решения может быть несколько. Важно учитывать наличие ресурсов у команды.
-
Выделить самые критичные направления, в которые готовы вкладываться и актуально это делать сейчас, а какие вопросы можно отложить
-
Как именно будете решать задачи: своими силами, готовы брать сотрудника в штат или точечно обращаться с запросами на исследования
Шаг 3
После аудита и приоритизации проблем переходим на следующий этап ⬇️
Подтверждено, что исследования в продукте нужны. Необходимо выстроить системный подход к проведению исследований и применению результатов
Шаг 1
Снова стартуем с аудита, но фокус здесь будет на другом — понять, как максимально лаконично встроить исследования в уже имеющиеся процессы.
Для этого нам важно определить два ключевых момента:
→ Как устроен процесс работы над задачей в команде?
→ На каком этапе и кто из ролей работает с высоким уровнем неопределенности?
Кто и как понимает, нужно ли делать фичу? Проверяют ли необходимость и как? Кто уточняет сценарии пользователей? Владеет ли аналитик знаниями про сценарии при написании постановки? Или ему нужно их собирать? Или пытается обходиться без них?
Шаг 2
Уделяем внимание донесению ценности и обучению исследованиям людей, которые работают с неопределенностью на разных уровнях – рассказываем:
-
Для чего нужны исследования
-
На каких этапах их проводить
-
Как работать с результатами исследований
Шаг 3
Работаем над донесением ценности изменений. Анализируем задачи и не боимся приводить в примеры фичи, реализованные без исследований, и последствия этого. Например, сделали фичу, которую никто не использует, а мы не понимаем причины или после релиза получили поток негативной ОС. Разбираем эти кейсы совместно с командой.
Шаг 4
Если в продукте решили проводить исследования, значит, кто-то видит в них ценность – ищем таких людей и заручаемся их поддержкой.
Это может быть лид аналитиков – он поможет запустить серию обучений для аналитиков.
Или, например, продакт, опирающийся на результаты исследований, может транслировать ценность такого подхода в своем сообществе.
Нормально, если в начале вы сможете построить строго формализованный процесс – договариваемся о правилах «делать так», и все их соблюдаем. Исследователь может как эксперт подключаться к ревью задач, чтобы помочь определить, нужно ли исследование.
Например, я подключалась на квартальное планирование задач и по каждой задаче разбиралась с фичалидом, нужно ли проводить исследование, для чего и какое.
Со временем необходимость контролировать процесс может отпасть – роли, заинтересованные в результатах, получат опыт и поймут, в каких ситуациях стоит подключать исследователя.
Шаг 5
Важно не только проводить исследования, но и следить за тем, чтобы на их основании были приняты решения. Как это можно делать:
-
Обучать команду работе с результатами исследований
-
Обогащать исследование выводами и рекомендациями
-
Не оставлять команду один на один с результатами, подключаться к дальнейшему процессу работы
-
Организовывать встречи-мозгоштурмы для обсуждения
В продукте регулярно проводятся исследования, команда понимает их ценность
Если всё идет хорошо и предыдущие шаги успешно пройдены, со временем вы можете прийти к созданию и оптимизации всевозможных иных процессов вокруг исследований.
Какие исследовательские процессы могут быть необходимы в дальнейшем:
-
Корректировка существующих подходов к исследованию
Например:
В продукте есть исследования, они проводятся давно, им доверяют, но так как ресурсы ограничены:
→ Упор на проверке проблемных гипотез
→ Интерфейсные решения не проверяются
В результате команда перестает понимать, насколько понятные решения мы реализовали. Если вы постоянно мониторите сложившиеся подходы к исследованиям, выявить такой перекос несложно.
-
Масштабирование существующих подходов на другие подкоманды, если их несколько
-
Управление исследовательским бэклогом и планирование задач
С ростом популярности исследований и объема задач приходится выстраивать порядок взятия задач в работу и приоритеты.
Например:
На старте поток задач был небольшим, удавалось индивидуально договариваться с заказчиками о комфортных сроках. С ростом объема задач они начали конфликтовать между собой — стало необходимо договариваться о способах приоритизации и придерживаться одного подхода во всех ситуациях.
-
Демократизация исследований
Обучение и передача части исследовательских задач другим членам команды особенно уместна и значима тогда, когда вам удалось добиться такой популярности исследований, что вашего ресурса уже не хватает.
-
Создание процесса работы с обратной связью от пользователей
Максимально необходимо, когда поток обратной связи становится настолько большим, что её невозможно отслеживать и учитывать в работе без систематизации.
-
Выстраивание процесса оценки качества реализованных фич
Потребность сильнее проявляется на этапе, когда:
-
Поток исследований большой, недостаточно ресурса исследовать обратную связь после всех значимых фич
-
Продукт развитый, основным фокусом становится не только создание новой ценности / функциональности, но и улучшение существующей
В заключение
Процессов, связанных с организацией и проведением исследований, множество. Каждый перечисленный в последнем блоке имеет свою ценность, варианты реализации и заслуживает отдельной статьи.
Не стоит пугаться этого объема и пытаться наладить сразу все. План и шаги, описанные в статье, помогут выбрать начальную точку движения. Дальше важно регулярно анализировать меняющиеся потребности продукта и фокусироваться на значимых в вашей конкретной ситуации. Дерзайте.
Написано автором телеграм-канала про исследования с вкусным названием «Сдоба».
ссылка на оригинал статьи https://habr.com/ru/articles/885632/
Добавить комментарий