Привет, я Никита Крицкий, продакт-менеджер в Kaiten. В этой статье подробно расскажу, как собирать, анализировать и использовать обратную связь от пользователей для создания продукта, за который пользователи готовы платить. Поговорим об этапах работы, методах сбора обратной связи и конкретных примерах реализации в компании Kaiten.
Далеко не всегда внутренние специалисты разработки досконально знают сферу и нюансы работы в ней. Часто они не понимают, какие минусы есть у продукта и как его улучшить, ведь они — нецелевая аудитория и не пользователи продукта.
Именно поэтому нужно регулярно общаться с пользователями — это помогает понять их реальные потребности. С помощью обратной связи проще понять, что именно нужно аудитории, как развивать продукт и как делать так, чтобы клиенты были готовы за него платить.
Развитие продукта на основе обратной связи помогает компаниям:
Собирать обратную связь от реальных пользователей необходимо, если вы хотите совершенствовать свой продукт и выжимать максимум для своего бизнеса. Возможно, это не всегда напрямую развивает продукт с точки зрения функциональности, но делает его более стабильным.
Важно научиться комбинировать разные методы сбора обратной связи, чтобы получить полную и объективную картину. Для этого анализируйте информацию и используйте ее для принятия решений по развитию продукта и улучшению клиентского опыта.
CustDev помогает изучить целевую аудиторию и понять, что необходимо развивать в продукте. С его помощью также можно увидеть сценарии решения проблем пользователями и научиться встраивать продукт в эти сценарии.
Одна из частей CustDev — глубинное интервью с пользователями, где индивидуально обсуждаются его потребности и то, каких можно решить их нашим продуктом. С его помощью можно получить подробную информацию, понять проблемы и причины определенного поведения пользователей.
Когда стоит использовать интервью и CustDev:
На этом же этапе нужно провести UX-созвон — посмотреть, как человек в режиме реального времени пользуется продуктом, изучить его опыт и на основе этого скорректировать разработку. Такой метод дает понимание, что пользователь делает не так, как он решает свои задачи, а также помогает выявить паттерны поведения.
Например, во время разработки сайтов дизайнеры и верстальщики тестируют разные варианты кнопок. Во время очередного тестирования они обнаружили, что есть область, на которую пользователи не обращают внимания. Во время глубинного интервью можно посмотреть, в чем причина такого поведения пользователя. То есть, можно отследить паттерны поведения аудитории, и потом эти наблюдения использовать для улучшения продукта.
Еще один способ получить информацию от пользователей — провести онлайн- или офлайн-анкетирование. Так вы быстро и недорого соберете максимум данных, а полученную информацию будет легко анализировать по ответам.
Проблема этого метода — в поверхностной информации от пользователей. По опросу вряд ли получится определить глубинные мотивы и причины появления проблем у пользователя. Человек может не так понять формулировку вопроса или некорректно на него ответить.
Когда стоит использовать опросы:
Хорошо, если пользователи сами заинтересованы в том, чтобы оставить обратную связь, например, на сайте. Это можно реализовать через специальное окно, телеграм-бота или в комментариях к странице. Любые обращения, которые вы получаете таким образом, можно поделить на 2 категории — отзывы и идеи/запросы на улучшение.
Отзыв — мнение пользователя о сервисе и его работе. Из содержательных отзывов можно почерпнуть идеи для улучшения продукта и работы команды.
Запрос на изменение — сообщение с просьбой добавить/изменить возможности сервиса. Такие обращения обычно рассматривает продуктовая группа, проектный менеджер и разработчики.
Например, есть российский аналог Miro, в котором минимум функций. При попытке добавить какие-то еще инструменты сервис предлагает написать разработчикам. Так программа развивается, отталкиваясь от потребностей ЦА. Более того, на сайте программы есть открытые голосования по разработке новых функций.
Таким образом они анализируют просьбу от пользователя и определяют, насколько это уместно — внедрять будут не все, о чем просит аудитория.
Поддержка — это не только способ решить сложности клиентов с продуктом или ответить им на все вопросы, но и метод получения обратной связи.
Все обращения, которые поступают в отдел поддержки, нужно систематизировать. Это постоянный поток информации от клиентов об их опыте использования продукта, затруднениях и проблемах, с которыми нужно помочь. Крупные компании присваивают теги каждому обращению, чтобы распределить их по категориям, а потом — проанализировать и взять в работу подходящие.
Когда стоит использовать метод:
В отличие от CustDev, поддержка получает запрос, когда проблема уже есть. То есть, это не способ предотвратить какие-то баги или недочеты — скорее, получить информацию о том, какие ошибки разработка уже допустила.
.avif)
Обратите внимание. Пользователи часто пишут в поддержку с негативом и раздражением. Но это не значит, что у вас плохой продукт. Просто хорошие отзывы люди оставляют намного реже, а в поддержку с ними обращаются единицы.
Менеджеры по продажам могут регулярно собирать информацию о возражениях, вопросах и потребностях потенциальных клиентов. Так мы понимаем, что удерживает клиентов от покупки, какие есть сомнения и чего им не хватает для покупки или перехода на сервис.
Когда стоит использовать метод:
Команда продаж собирает запросы от новых пользователей и тех, кто пока не купил сервис. Например, банк может прислать документ на 200 страниц с требованиями, которые нужны им для работы в программе. Команда изучит, насколько продукт соответствует этим требованиям. Если он на 80% соответствует, то на оставшиеся 20% можно доработать функционал. Но если большая часть требований невыполнима — то стоит занести что-то в бэклог и реализовывать в момент, когда появится необходимость и ресурсы.
Обратите внимание. Информация может быть субъективной и не всегда отражать реальные потребности пользователей.
Аккаунт-менеджеры всегда на связи с текущими клиентами. Периодически они проводят внутренние опросы или к ним приходят сотрудники с жалобами на конкретные инструменты.
Менеджер собирает список запросов на изменение у клиентов и отправляет его в продуктовый отдел. Все обращения разбирают по приоритетам — насколько это выполнимо, на какое количество людей влияет инструмент, насколько это критично и нужно срочно взять в работу.
Когда стоит использовать метод:
Обратите внимание. Нужно собирать информацию от всех пользователей, чтобы она не оказалась ограниченной потребностями только некоторых или ключевых клиентов.
Например, клиент просит добавить кнопку без пояснений, что его не устраивает в текущем функционале. Это — не повод начинать все переделывать под его запрос. Аккаунт-менеджеру стоит сначала уточнить напрямую у клиента, что именно его смущает в нынешнем функционале и зачем нужно внедрять кнопку на сайт. И уже после сбора этих данных — передавать информацию в продуктовый отдел для работы.
.avif)
Пользователи могут предлагать неожиданные решения и перспективы, которые команда даже не рассматривала. Нужно собрать все запросы из разных каналов связи с аудиторией и объединить их, а затем весь полученный фидбэк приоритизировать и составить из него список.
Для распределения задач по приоритетам есть много разных методов. Например, можно использовать метод MoSCoW, который легко адаптировать под любые задачи и проекты.
Все задачи можно разделить на 4 категории:
.avif)
Когда все задачи распределены — можно приступать к их реализации согласно каждой категории.
Чтобы распределить задачи по приоритетности в Kaiten, мы используем систему взвешиваний. Берем набор из критериев и каждому присваиваем вес:
После приоритизации идеи размещаются в бэклоге — перечне задач, которые нужно выполнить, и списке инструментов/функций, которые хотят получить пользователи.
Сам бэклог в Kaiten можно выстроить с учетом приоритетов — например, создать колонку «Бэклог», в которой будут все запланированные работы, и отдельные колонки для срочных и повседневных задач. Также в Kaiten можно указать приоритеты для каждой карточки отдельно или выставить WIP-лимиты, чтобы в колонке не собиралось задач больше, чем может выполнить команда во время спринта.
Когда мы выбрали наиболее важные и «весомые» задачи — их можно распределять по календарю и планировать работы. Так мы получаем roadmap — график работы и визуализация шагов по достижении результатов. С помощью дорожной карты можно определить, кто и чем занимается на каждом этапе.
.avif)
Для построения дорожной карты в Kaiten можно использовать диаграмму Ганта. Так станет проще оценить необходимые трудовые, финансовые и временные ресурсы, а также спланировать движение к цели.
Когда одну из задач берут в работу, то двигаются по такому алгоритму:
Когда инструмент уже запущен, важно обратиться к пользователям и уточнить, решена ли теперь проблема. В идеальном мире нужно отслеживать обратную связь по каждому релизу. Это помогает понять, насколько правильно был разобран запрос пользователя и реализована функция.
Например, в Kaiten собрали 5 запросов от разных пользователей и реализовали их в одном инструменте. Затем получили обратную связь от клиентов — для 4 из них проблема была решена, а для 1 — ничего не изменилось.
В этот момент разработчики должны решить, добавить эту задачу снова в бэклог для работы или постараться исправить ошибку в ближайшем релизе.
Обратите внимание. Работа с обратной связью должна быть гибкой и динамичной. Новые вводные постоянно поступают, поэтому приоритизация задач может меняться вместе с поступлением нового критического замечания.
Существуют два основных подхода оповещение пользователей о релизах:
Редкие, крупные релизы. Обновления выпускают редко, раз в 2 недели или квартал. Чаще встречаются релизные циклы в 1-2 недели. Это всегда результат длинной работы над десятками, а иногда и сотнями изменений.
Перед выпуском или сразу после него пользователи получают подробный и обширный лог изменений – полный список всех новых функций, исправленных ошибок и прочих модификаций.
Частые, небольшие релизы. Это подход Kaiten и других компаний, которые работают по канбану в потоке непрерывного улучшения функций. Мы постоянно что-то обновляем, пробуем и тестируем.
Обновления происходят часто, иногда несколько раз в день. Каждый релиз включает небольшое количество изменений.
В этом случае пользователи получают оповещения одним из способов:
Раз в квартал или месяц можно отправлять дайджест в качестве обобщающего обзора. В нем будет сводка всех изменений, произошедших за этот период.
Выбор способа оповещений в компании будет зависеть от частоты и объемов релизов в каждом из них.
Сбор обратной связи — возможность приоритизировать запросы, планы и идеи по развитию продукта с учетом дефицита рабочей силы и времени. Это способ выбрать, что начать внедрять в первую очередь, когда еще нет большого штата разработчиков.
Если у команды не хватает ресурсов, очередь разработки переполнена и у продукта есть очевидные минусы, то сбор обратной связи может стать губительным.
Важно: проблема сбора обратной связи — управление ожиданиями клиентов. Когда они делятся своими переживаниями по продукту, то надеются, что именно их слова повлияют на улучшения и изменения сервиса. Но когда мы в третий раз за год приходим с опросом, и при этом за 12 месяцев не сделали ничего из запрошенного — это вызовет негатив и снизит лояльность клиентов.
Бывают и другие сложности, связанные с развитием на основе ОС:
Обратите внимание. Не всем пользователям понравятся изменения в продукте, даже если они основаны на обратной связи. Будьте готовы к критике и умейте ее конструктивно обрабатывать.
Можно рассмотреть на реальных примерах из нашей практики в Кайтен.
Детали запроса: для отдельных участников команды не все объекты доступны, а как получить к ним доступ — неясно.
Какое нашли решение. Сами пользователи предлагали такое решение этой проблемы — добавить подпись, кто администратор проекта или объекта. Так можно было напрямую обратиться к ответственному человеку и получить необходимые полномочия.
Как его в итоге реализовали в Kaiten. Команда Kaiten сделала кнопку для запроса доступа, и это решило проблему пользователей.
Проблема. В разделе «Личное» команда обнаружила баг, который можно было устранить только через изменение всего раздела. Разработчики оперативно внесли изменения, чтобы избавиться от проблемы.
Детали запроса. После исправления ошибки стали появляться жалобы от клиентов о том, что раздел стал неудобным, а отсутствие деления на срочные и несрочные задачи — важным недостатком.
Какое нашли решение. Служба поддержки собрала жалобы неудобства после изменений.
Как это решение реализовано в Kaiten. Команда еще раз обновила раздел, учитывая обращения аудитории.
Это правильный подход, но не стоит слепо реализовывать все, что просят пользователи.
Опирайтесь на 2 важных правила:
Например, у компании 1000 разработчиков и 10 клиентов. Даже в этом случае нельзя брать запрос от одного пользователя и выстраивать продукт под него. Единственный случай, когда стоит реализовать все, чего хочет клиент — если этот продукт создан только для него и под его потребности. Но даже в этом случае продумывайте реализацию на несколько шагов вперед, ведь клиент не может учесть все возможные противоречия.
Поэтому да — учитывать обратную связь необходимо, но без перегибов. Можно сравнить такой сбор с визитом к врачу. Хороший специалист не будет просто выписывать обезболивающее в ответ на «болит живот». Он разберется в причинах и выпишет соответствующее лечение. Так и с разработкой продукта — нужно разобраться и создать комплексное подходящее решение, которое устранит первопричины.
