Feature request (запросы функций) – важный инструмент взаимодействия между командой разработки и конечным пользователем. Запросы позволяют более здраво рассмотреть продукт с точки зрения пользователя и определить пути улучшения его опыта при работе с продуктом.

Здравствуйте! Меня зовут Ирина, я менеджер продукта в компании Bimeister, и хочу вам рассказать о нашем опыте управления Feature requests в продукте для B2B сегмента.

Проблема

По мере развития нашего продукта и увеличения количества клиентов, а как следствие пользователей, возникает проблема роста числа замечаний, запросов на улучшение и добавления нового функционала в продукт. При этом, такие запросы могут быть очень специфичны и иметь формулировку от «переименуйте кнопку на…» до «интегрируйтесь с нашей ERP-системой». И хотя многие из таких запросов могут показаться бесполезными, а ответы на них отнимают большое количество времени, при правильном управлении они могут оказать чрезвычайно положительное влияние как на продукт, так и на отношения с пользователями.

Независимо от того, реализуете ли вы идею или нет, если вы должным образом ответите на запрос, вы укрепите свою связь с клиентами. И, конечно же, если запрос касается функции, о которой вы ранее не думали, и которая идеально соответствует целям и стратегии вашего продукта, это может в итоге значительно улучшить ваш продукт.<o:p>

В сухом остатке статья про то, как мы выбросили из своей жизни автоотбивку «Спасибо, нам важно ваше мнение». Поехали :)

Немного о категоризации

Общепринятая категоризация запросов выглядит следующим образом:

1. Сообщение об ошибках (они же баги): когда клиент замечает, что что-то не работает должным образом в вашем продукте

2. Запрос на улучшение: предложение, которое может сделать текущую функцию немного лучше

3. Запрос новых функций: идеи для совершенно новых функций, которые могут быть добавлены в ваш продукт по мнению клиента

Важно помнить о трех этих категориях запросов для выбора правильного пути их обработки.

Прием запросов

Первым шагом для правильного построения системы обработки запросов – является определение единой точки сбора запросов. И здесь необходимо немного раскрыть этот тезис. Когда мы пытались выявить все потенциальные источники данных запросов у нас получился следующий набор:

1. Запросы от активных пользователей

2. Запросы от команды разработки/внедрения продукта, которым небезразличен их продукт (а у нас такие все)

3. Запросы по результатам проведения демонстраций для потенциальных клиентов, осуществляемого совместно с нашим отделом Sales&Marketing

Оказалось, что даже при таком количестве источников, формулировки запросов разительно отличаются и зависят, в том числе, и от рода деятельности автора запроса. Проще говоря, каждый смотрит на продукт «со своей колокольни» и не всегда способен правильно донести свою потребность в понятном для команды разработки виде.

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

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

Категоризация запросов

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

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

Другие категории запросов передаются в продуктовую команду для анализа.

Анализ запросов

Анализом запросов в моей команде занимаются бизнес-аналитики. Они проводят уточняющие исследования для того, чтобы определить следующие параметры:

1. Достаточность информации в запросе. При необходимости мы связываемся с коллегами из технической поддержки/ с автором запроса для уточнения более детальной информации

2. Категория: улучшение или добавление новой функциональности

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

4. Частота запроса конкретной функциональности для определения ее востребованности

5. Уровень разрыва с текущим состоянием (тут на помощь приходит классический fit-gap анализ)

6. Оценка трудозатрат на реализацию

7. Влияние на основные метрики

Затем, вся эта информация передается менеджеру продукта, для окончательного решения по запросу.

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

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

Заключение

В заключении хотелось бы привести небольшую статистику:

• всего за год получено 720 запросов на улучшение или новую функциональность;

• после группировки схожих запросов осталось 305;

• из них по 149 был передан отрицательны ответ автору запроса;

• для 113 были найдены соответствия в дорожной карте;

• 43 были добавлены в беклог для отработки гипотез по продукту.