Feature request (запросы функций) – важный инструмент взаимодействия между командой разработки и конечным пользователем. Запросы позволяют более здраво рассмотреть продукт с точки зрения пользователя и определить пути улучшения его опыта при работе с продуктом.
Здравствуйте! Меня зовут Ирина, я менеджер продукта в компании Bimeister, и хочу вам рассказать о нашем опыте управления Feature requests в продукте для B2B сегмента.
Проблема
По мере развития нашего продукта и увеличения количества клиентов, а как следствие пользователей, возникает проблема роста числа замечаний, запросов на улучшение и добавления нового функционала в продукт. При этом, такие запросы могут быть очень специфичны и иметь формулировку от «переименуйте кнопку на…» до «интегрируйтесь с нашей ERP-системой». И хотя многие из таких запросов могут показаться бесполезными, а ответы на них отнимают большое количество времени, при правильном управлении они могут оказать чрезвычайно положительное влияние как на продукт, так и на отношения с пользователями.
Независимо от того, реализуете ли вы идею или нет, если вы должным образом ответите на запрос, вы укрепите свою связь с клиентами. И, конечно же, если запрос касается функции, о которой вы ранее не думали, и которая идеально соответствует целям и стратегии вашего продукта, это может в итоге значительно улучшить ваш продукт.<o:p>
В сухом остатке статья про то, как мы выбросили из своей жизни автоотбивку «Спасибо, нам важно ваше мнение». Поехали :)
Немного о категоризации
Общепринятая категоризация запросов выглядит следующим образом:
Сообщение об ошибках (они же баги): когда клиент замечает, что что-то не работает должным образом в вашем продукте
Запрос на улучшение: предложение, которое может сделать текущую функцию немного лучше
Запрос новых функций: идеи для совершенно новых функций, которые могут быть добавлены в ваш продукт по мнению клиента
Важно помнить о трех этих категориях запросов для выбора правильного пути их обработки.
Прием запросов
Первым шагом для правильного построения системы обработки запросов – является определение единой точки сбора запросов. И здесь необходимо немного раскрыть этот тезис. Когда мы пытались выявить все потенциальные источники данных запросов у нас получился следующий набор:
Запросы от активных пользователей
Запросы от команды разработки/внедрения продукта, которым небезразличен их продукт (а у нас такие все)
Запросы по результатам проведения демонстраций для потенциальных клиентов, осуществляемого совместно с нашим отделом Sales&Marketing
Оказалось, что даже при таком количестве источников, формулировки запросов разительно отличаются и зависят, в том числе, и от рода деятельности автора запроса. Проще говоря, каждый смотрит на продукт «со своей колокольни» и не всегда способен правильно донести свою потребность в понятном для команды разработки виде.
Соответственно, стало очевидно, что первым шагом для нас будет создание единой точки сбора запросов и стандартизация их описательной формы.
Тут нам очень помогают наши коллеги из отдела технической поддержки, стоящие на первой линии обороны. Совместно с ними мы создали единую форму на нашем онлайн портале, которую должен заполнить пользователь при формировании запроса. Она содержит следующие основные поля:
Поле | Тип поля | Обязательно для заполнения? | Правила заполнения |
Тема | Строка | Да | Краткое наименование проблемы, отвечает на вопросы "Что? Где?" |
Автор | Пользователь | Да | Указывается специалист поддержки, который обработал заявку и завел задачу типа "Предложение по улучшению" |
Проект | Выбор из списка | Нет | |
Приоритет | Выбор из списка | Да | |
Продукт | Выбор из списка | Да | Заполняется при наличии актуального списка функциональности проекта |
Раздел | Выбор из списка | Нет | |
Роль в системе | Строка | Нет | Роль в системе, для которой предлагаются изменения |
Должность | Строка | Нет | Должность пользователя, предложившего изменения |
Описание проблемы | Текст | Да | |
Предложение по улучшению | Текст | Да |
Категоризация запросов
После получения запросов в описанном формате, у технической поддержки уже достаточно информации, чтобы определить их категорию.
Сообщения об ошибках сразу поступают в бэклог ошибок для устранения, в соответствии с регламентными сроками.
Другие категории запросов передаются в продуктовую команду для анализа.
Анализ запросов
Анализом запросов в моей команде занимаются бизнес-аналитики. Они проводят уточняющие исследования для того, чтобы определить следующие параметры:
Достаточность информации в запросе. При необходимости мы связываемся с коллегами из технической поддержки/ с автором запроса для уточнения более детальной информации
Категория: улучшение или добавление новой функциональности
Наличие в дорожной карте (в целом открытая дорожная карта позволяет клиенту понимать в каком направлении движется наш продукт и помогает формулировать более целенаправленные запросы, которые соответствуют целям продукта, а не случайные идеи, которые вызывают перегрузку)
Частота запроса конкретной функциональности для определения ее востребованности
Уровень разрыва с текущим состоянием (тут на помощь приходит классический fit-gap анализ)
Оценка трудозатрат на реализацию
Влияние на основные метрики
Затем, вся эта информация передается менеджеру продукта, для окончательного решения по запросу.
Нужно отметить, что в нашей практике указанный анализ не занимает много времени. В среднем по продукту нам поступает 15 запросов на улучшение или новую функциональность в неделю, на обработку которых тратится примерно 3 чел.-часа.
В результате мы готовим честным ответ автору запроса, где указываем приблизительные сроки реализации, если функциональность соответствует дорожной карте или мы решили добавить ее туда. В противном случае мы также честно отвечаем, что не готовы реализовать запрос.
Заключение
В заключении хотелось бы привести небольшую статистику:
всего за год получено 720 запросов на улучшение или новую функциональность;
после группировки схожих запросов осталось 305;
из них по 149 был передан отрицательны ответ автору запроса;
для 113 были найдены соответствия в дорожной карте;
43 были добавлены в беклог для отработки гипотез по продукту.