Среди разработчиков есть люди, которые хотят видеть, что их продуктом пользуются. Но что делать, если продукт еще в разработке? Или разработан, но нет первых пилотных клиентов? В обоих случаях нужна обратная связь, чтобы понимать, какие возможности продукта востребованы рынком, а какие нет. А если всё это осложняется трудностью представить результаты работы для не-технарей? Ну и самое сложное — если продукт нужно продать внутри компании, чтобы его начали продавать клиентам?
Как наша команда решала эти вопросы под катом.
Пара слов о продуктах команды
Мы делаем backend решения для игровых разработчиков, чтобы они могли сосредоточиться на игре, а не на том, как организовать магазин в игре или работу с предметами в инвентаре игрока.
Зачем нужна обратная связь?
В компании много продуктовых команд и почти все работают по Scrum. Одной из особенностей Scrum является постоянный сбор обратной связи: команде важно, чтобы то, что они делают, было ценным и решало проблемы клиентов, на основе этой обратной связи корректируется дальнейшая работа.
Показывать результаты?
В Scrum есть специальный ритуал — обзор итогов спринта (презентация итогов работы команды за период времени) — который нужен для получения обратной связи. В какой-то момент команда поняла, что объяснений, о том, что было сделано, недостаточно и начала экспериментировать с вариантами, как демонстрировать результаты работы.
Берешь и рассказываешь!
Идеальный вариант, когда команда небольшая и можно общаться с клиентами напрямую, но это не наш случай.
К сожалению, с ростом компании, команда не всегда может напрямую общаться с клиентами, ведь на кону могут быть репутационные риски. В таком случае обратную связь команде дают люди, которые общаются с клиентами — интеграторы и аккаунт-менеджеры. Так уж вышло, что эти люди могут не обладать достаточными техническими навыками, чтобы из 15-20 минутного объяснения и пары картинок было понятно, что было сделано и как это работает.
Всё просто, если продукт обладает визуальной составляющей — показать продукт как есть, как им пользоваться. Наглядно и понятно. Не требуется никаких дополнительных действий со стороны команды разработки, чтобы продукт начали показывать клиентам.
Становится сложнее, когда у продукта нет визуальной составляющей — backend-продукт. Это какие-то API-сервисы, которые дают функционал, скрытый под капотом. Как в таком случае показывать работу продукта, да ещё и так, чтобы было понятно?
Давным давно
Времени на подготовку было мало и команда решила — откроем Postman (cUrl/Fiddler) и покажем запросы. Для команды всё понятно: вот запрос, вот ответ. Ещё можно логи показать, да что данные в базе изменились.
Для команды разработки минимум временных затрат и всё понятно. Но тем, кто общается с клиентами оказалось не понятно, что конкретно сделала команда, как этим будут пользоваться и зачем это вообще нужно.
Не так давно
Один из разработчиков, по личной инициативе, сделал сайт. Визуально и концептуально простой — данные приходят из API, их отрисовываем на сайте, показываем несколько кнопочек и по нажатию на них выполняются запросы.
Стало намного понятнее как продукт работает.
Демонстрировать новый функционал стало проще, но только внутри компании, потому что решение не выглядит презентабельным. Времени на поддержку такой демо-страницы много не требовалось, выложил на локальный ресурс, да показывай.
Сейчас
Команда хочет, чтобы продуктом пользовались, а значит его нужно продавать клиентам. Чтобы было проще демонстрировать функционал конечным пользователям, решили реализовать полноценный демо-стенд. За основу взяли концепт нашего Арт-директора, который болеет за наш продукт не меньше команды.
Не знаю, как вам, а нам понравился результат. Вышло красиво, наглядно и привлекает внимание. Одна проблема — поддерживать демо-стенд в актуальном состоянии дорого — новый backend функционал хочется демонстрировать постоянно, а добавлять его на frontend бывает также сложно, как и разрабатывать его на backend. Большой плюс в этом — разработчики качают frontend компетенции.
Этот сайт позволяет собирать качественную обратную связь, но не каждую функциональность можно демонстрировать на нем.
Будущее
В команде много людей, которые хотели делать игры. Есть даже те, что делали их. Решили, что пора сделать что-то своё, куда можно интегрировать продукты. В рамках личной инициативы, решили сделать небольшую игру, в которую будут интегрированы основные возможности наших продуктов. Самое сложное здесь — сделать базовый функционал игры, а расширение продуктовыми возможностями должно происходить также, как при добавлении его на текущий вариант демо-стенда.
Мы только начали, потому что дело это не быстрое, но знаем, что в ближайшем будущем функционал будет показываться в настоящей игре.
Вместо вывода
Мы прошли длинный путь, от отсутствия обратной связи, до возможности демонстрировать функционал наших продуктов не только внутри компании, но и снаружи, чтобы сделать получение обратной связи быстрым.
Главное, что мы поняли — чтобы обратная связь была действительно полезной, демонстрировать результаты нужно так, будто клиент пользуется этой функциональностью.
