Привет! Меня зовут Олег Борискин, я менеджер по продукту мессенджера МТС Линк Чаты. Каждый день нам приходят десятки запросов от пользователей — от связи в мессенджере через спутник до округления иконок на два пикселя. Все это мы собираем, анализируем и используем в работе. В статье расскажу, как устроен процесс, где мы собираем запросы и на каких этапах работы используем (спойлер: практически на всех). 

Что нам дают пользовательские запросы

Пользовательские запросы — это то, что клиенты хотят видеть в продукте. Это могут быть как сформированные требования, так и идеи, отзывы и предложения. Вот пара примеров таких запросов:

• «было бы неплохо сделать быструю реакцию с помощью Force Touch на макбуках»;

• «сделайте ввод текста при движении глаз по клаве»;

• «нужна коробочная версия под Linux».

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

Запросы можно где-то собирать, чтобы учитывать только самые высокочастотные — это неплохой способ, но публичным сервисом пользуется разная аудитория. Частота далеко не самый важный параметр. Даже если это b2b-продукт для руководителей среднего звена, то в этой группе у всех будет разный опыт. Есть риск выпустить часто запрашиваемую фичу, которая решит проблему лишь у части пользователей (или вообще ничего не решит — такое тоже бывает).

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

Как собирать пользовательские запросы

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

Мы в МТС Линк Чатах используем такой порядок:

• пользователи делятся идеями с поддержкой или менеджерами по работе с клиентами;

• поддержка складывает запросы в базу данных;

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

Как обрабатывать пользовательские запросы

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

Чтобы обрабатывать эту схему, мы пробовали таблицы — не советуем ?. В них сложно систематизировать и связывать запросы с фичами в сервисе. В итоге остановились на сервисе Productboard: здесь можно совместно обрабатывать, хранить и классифицировать запросы. Либо это можно реализовать в Notion (и других сервисах для построения баз знаний) с помощью тегов и саб-тасок. Вот как все устроено:

Карточки. Каждый запрос — это отдельная карточка, у которой есть:

• клиент — от кого пришел запрос;

• содержание — текст запроса; 

• связи — заведенные в базу фичи, с которыми связывается запрос.

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

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

Запросы можно приоритизировать. В Productboard можно поставить степень важности фичи, а из нее посчитать User Impact Score — рейтинг пользовательских запросов. Вы можете заложить идею градации в свой подход к разработке, чтобы учитывать серьезность запроса:

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

• какая компания или клиент сделали запрос;

• к какой фиче относится запрос;

• насколько важен запрос по нашей внутренней оценке;

• как запрос соотносится с планом разработки фичи.

Как использовать пользовательские запросы в ежедневной работе

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

Учитывать контекст запросов в создании фичей

Связывая запросы с клиентами, вы лучше понимаете контекст. Этот контекст необходим для проработки стори — корневой задачи, которая пойдет в разработку.

Например, в мессенджере есть уведомления. Когда менеджер по продукту думает, куда дальше развивать эту функцию, он может зайти в базу данных и отследить, кто про нее спрашивал. Эта информация поможет ему в проработке фактуры для задачи. Например, уведомления для пиарщика и бухгалтера — это два разных кейса. Первого часто упоминают, каждый день он может принимать участие в десятке бесед, у второго такие ситуации редки. Учитывая контекст, менеджер по продукту будет лучше понимать, какое решение ждут пользователи: единую панель настройки уведомлений или индивидуальные плашки для каждого чата.

Использовать данные запросов при планировании и приоритизации фичей

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

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

Выделять ресурсы туда, где пользователи действительно ждут улучшений 

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

В своей работе я использую данные запросов на каждом уровне: когда пишу сторю, планирую дату релиза фичи и организую ресурсы команды на разработку. Общая схема в итоге выглядит вот так: можете открыть ее в МТС Линк Досках и рассмотреть.

Пара слов в финале

Работа с пользовательскими запросами — это обязательная практика, когда вы разрабатываете продукт для разнообразной аудитории, а не для себя или одного крупного клиента. В то же время обратная связь — это не панацея: нельзя слепо опираться только на эти данные при построении продукта с нуля. Кроме запросов, есть еще масса факторов: конкуренты и рынок, стратегические цели, сложность разработки, архитектурные ограничения. 

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