Discovery: как сфокусировать команду и делать только нужные фичи. Опыт Kolesa Group

Один из самых эффективных инструментов достижения целей бизнеса – процесс Discovery. Он позволяет ускорить разработку и наладить работу продуктовой команды.

Из чего состоит Discovery и зачем учить разработчиков понимать бизнес-показатели — об этом для Digital Business рассказал product-менеджер Kolesa Group Олег Лебедев.

«День менеджера не должен превращаться в череду разъяснительных бесед»

Сейчас я работаю над продуктом Krisha.kz, ранее трудился над Market.kz, и почти всегда сталкивался с управленческими трудностями.

Одна из наиболее важных проблем – команда не всегда понимает процесс принятия решений. Как мы поняли, что это проблема? Когда ты как менеджер объявляешь: «Ребята, мы делаем эту задачу», а после к тебе по очереди подходят QA-инженеры, бэкендеры, фронтендеры и спрашивают: «Почему мы делаем этот функционал, а не другой?» Ты объясняешь. Потом приходят дизайнеры, аналитики, исследователи – и процесс объяснения повторяется.

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

Discovery – метод поиска проблем и точек роста в продукте или на рынке. Здесь собираются и анализируются данные, а также рождаются гипотезы, которые принесут наибольшую пользу пользователям и бизнесу.

Для менеджера Discovery – просто серия встреч с членами продуктовой команды, на которых находим проблемные места или точки роста в продукте и начинаем с ними работать.

Подробнее об этом процессе я рассказал в ролике «Что такое Discovery» в рамках бесплатного обучающего продукта Kolesa Upgrade по product-менеджменту.

«Встречи помогают снять вопросы и почувствовать сопричастность»

Discovery-процесс включает несколько встреч. Самая важная – планирование. Она помогает устранить непонимание процесса принятия решений. Общий принцип – начинаем с верхних уровней и спускаемся вниз.

Сначала занимаемся стратегией. Например, в этом году наше стратегическое направление – работа с тем, как пользователь ищет объявления. Дальше обсуждаем цели и KPI. На каждой встрече, когда планируем какую-то фичу, анализируем, соответствует ли она нашим глобальным целям и стратегии. Это помогает менеджеру фильтровать важные задачи. Команда также включается в процесс и приносит решения. Результат встречи по планированию – понятный список работ на ближайший период с конкретными сроками и исполнителями.

Второй тип встреч – мозговой штурм проблем или решений. Когда выделяем конкретное направление, в которое пойдем, можем штурмить конкретную проблему и решение. В итоге получаем список гипотез и точек роста, с которыми команда будет работать в ближайшее время.

Третий тип встреч – расстановка приоритетов для решений или проблем. Важно показать команде, как они принимаются. Инструмент приоритезации может быть любым. Например, я использую фреймворк RIСE.

Результат этого этапа – приоритезированный список гипотез и точек роста. Можно показать команде, что у нас есть несколько решений, каждое из которых получило оценку, и поэтому то или иное пошло в первую очередь. Берем в работу гипотезы с самой высокой оценкой.

Еще в Discovery важны демо-встречи. Там участники могут показать результаты своей работы. Например, аналитики и исследователи собирают и приносят данные о том, как пользователи взаимодействуют с продуктом. Вся команда знакомится с данными и начинает мыслить цифрами. Благодаря демо-встречам люди понимают, как принимаются решения, и чувствуют свою причастность.

На Discovery-встречах должны быть:

• менеджер как драйвер процесса;
• аналитик, потому что решения нужно принимать на основе данных, а не субъективных мнений;
• исследователь, который говорит с пользователями и передает их восприятие продукта;
• дизайнеры, которые проектируют интерфейсы для пользователей;
• тимлиды разработки и тестирования — они могут предложить технические решения на начальных этапах.

Если ваш продукт взаимодействует с другими отделами, например, с модерацией или сервисом, зовите и их на встречу. Они принесут полезные инсайты.

«Команда должна видеть не только цифры, но и пользователя за ними»

Если люди не понимают, на что повлияли их усилия, у них снижается мотивация и вовлеченность. Кроме того, вы с командой можете пропустить моменты, которые можно улучшить в продукте.

К примеру, мы запустили новый функционал – автомодерацию текста. До этой фичи люди вручную проверяли объявления. Новый процесс проверки запустили, протестировали, аналитики дали добро. Внедрили фичу и перешли к другим задачам.

Фото: Катерина Малама

Спустя некоторое время у команды начали возникать вопросы: «Мы работали над этим две недели, а какой результат?» Важно рассказывать, какие изменения принес внедренный функционал и как он отразился на бизнес-показателях. Мы собрали ребят и вместе посмотрели, на какие показатели повлияла наша работа:

• сократилось количество действий модераторов;

• уменьшилось среднее время обработки объявлений;

• повысилась удовлетворенность пользователей.

Плюс эта задача соответствует нашей стратегии – там был пункт об автоматизации рутинных процессов. Это важно донести до команды.

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

Фото: Катерина Малама

Пример: однажды при работе над продуктом Market.kz мы переделали карточку объявления и заметили, что после этого количество звонков снизилось. Попытались это исправить, предлагали тяжелые в разработке решения. Затем решили глубже разобраться в проблеме и провести CX/UX-исследование. Оказалось, что пользователи не понимали, куда нажимать. После этого дизайнер и фронтендер передвинули нужную кнопку, зарелизили изменения и метрики вернулись в норму.

«Собираем симптомы проблем, штурмим идеи, питчим решения перед руководством»

Мы приглашаем на Discovery-встречи всех, кто влияет на продукт и может принести полезные идеи. Содержание встреч укладывается в простой чек-лист:

• акцент на стратегии, в каком направлении движется продукт;
• объясняем, из чего складывается глобальный KPI;
• показываем, как работает аналитика, на какие цифры смотреть;
• знакомим с итогами CX/UX-исследований;
• рассказываем о результатах релизов, чтобы команда знала, как их работа влияет на продукт.

Напоследок хочу привести несколько советов, которые помогут эффективно строить процесс Discovery и избежать лишнего стресса:

1. Распределите роли на встрече. Выберите ответственных людей для каждой из задач.
2. Анонсируйте встречу заранее. Сообщите в чат, что там будет происходить, чтобы участники понимали цель и результаты. После встречи закрепите резюме в чат, чтобы не забыть обсуждаемое.
3. Фиксируйте весь процесс на доске (например, Miro). Записывайте путь от обсуждения до итогового решения, запуска фичи и анализа релиза. Это поможет вернуться и понять, почему приняли те или иные решения.
4. Проводите ретро-встречи. На них полезно обсуждать сложности и лучшие практики. Discovery – итеративный процесс непрерывного улучшения.

Читайте также: «Руководитель должен делать все, чтобы у команды было ощущение свободы». История тимлида отдела продаж Kolesa Group