Среди разработчиков есть люди, которые хотят, чтобы их продукт использовали.
Но что, если продукт все еще находится в разработке? Или он разработан, но первых пилотных клиентов нет? В обоих случаях необходима обратная связь, чтобы понять, какие функции продукта востребованы рынком, а какие нет. А что, если все это осложняется сложностью представления результатов работы нетехнам? Ну и самое сложное, а что, если продукт нужно продать внутри компании, прежде чем его можно будет продать покупателям? Как наша команда решала эти вопросы под катом.
Несколько слов о продуктах команды
Мы делаем backend-решения для разработчиков игр, чтобы они могли сосредоточиться на игре, а не на том, как организовать магазин в игре или работать с предметами в инвентаре игрока.
Зачем нужна обратная связь?
В компании много продуктовых команд и почти все они работают по Scrum. Одна из особенностей Scrum — постоянный сбор обратной связи: команде важно, чтобы то, что они делают, было ценным и решало проблемы клиентов; дальнейшая работа корректируется на основе этой обратной связи.
Показать результаты?
В Scrum есть специальный ритуал — обзор результатов спринта (презентация результатов работы команды за определенный период времени), — который нужен для получения обратной связи.В какой-то момент команда поняла, что объяснить, что было сделано, недостаточно и начала экспериментировать с вариантами того, как продемонстрировать результаты работы.
Возьми и расскажи!
Идеальный вариант — когда команда небольшая и можно напрямую общаться с клиентами, но это не наш случай.К сожалению, по мере роста компании команда не всегда может напрямую общаться с клиентами, поскольку на кону могут быть репутационные риски.
В этом случае обратную связь команде дают люди, которые общаются с клиентами — интеграторы и аккаунт-менеджеры.
Так уж получилось, что у этих людей может не хватить технических навыков, чтобы из 15-20-минутного объяснения и пары фотографий было понятно, что было сделано и как это работает. Все просто, если у продукта есть визуальная составляющая — покажите продукт такой, какой он есть, как им пользоваться.
Наглядно и понятно.
Никаких дополнительных действий со стороны команды разработчиков для начала показа продукта клиентам не требуется.
Сложнее становится, когда у продукта нет визуальной составляющей — backend-продукта.
Это своего рода API-сервисы, которые предоставляют скрытый под капотом функционал.
Как в этом случае мы можем показать, как работает продукт, и так, чтобы это было понятно?
Давным давно
Времени на подготовку было мало и команда решила — давайте откроем Postman (cUrl/Fiddler) и покажем запросы.
Для команды все ясно: вот запрос, вот ответ. Вы также можете показать журналы того, что данные в базе данных изменились.
Для команды разработчиков затрачено минимальное количество времени и все понятно.
Но тем, кто общается с клиентами, было непонятно, что именно делала команда, как они будут это использовать и зачем это вообще нужно.
Не так давно
Один из разработчиков по собственной инициативе создал сайт. Визуально и концептуально просто — данные поступают из API, мы рисуем их на сайте, отображаем несколько кнопок и по нажатию на них выполняются запросы.
Стало намного понятнее, как работает продукт. Демонстрировать новый функционал стало проще, но только внутри компании, потому что решение выглядит не презентабельно.
Поддержать такую демо-страницу, разместить ее на локальном ресурсе и показать не заняло много времени.
Сейчас
Команда хочет, чтобы продуктом пользовались, а это значит, что его нужно продавать клиентам.
Чтобы было проще продемонстрировать функционал конечным пользователям, мы решили реализовать полноценный демонстрационный стенд. Мы взяли за основу концепцию нашего арт-директора, который увлечен нашим продуктом так же, как и команда.
Не знаю как вам, а нам результат понравился.
Получилось красиво, наглядно и привлекает внимание.
Одна из проблем заключается в том, что поддерживать демо-версию в актуальном состоянии стоит дорого: вы хотите постоянно демонстрировать новые функциональные возможности серверной части, а добавить их во внешний интерфейс может быть так же сложно, как разработать их на серверной части.
Большой плюс в этом — у разработчиков развиваются frontend-компетенции.
Этот сайт позволяет собирать качественную обратную связь, но не каждый функционал на нем можно продемонстрировать.
Будущее
В команде много людей, которые хотели делать игры.
Есть даже те, кто их сделал.
Мы решили, что пришло время сделать что-то свое, куда можно было бы интегрировать продукты.
В рамках личной инициативы мы решили сделать небольшую игру, в которую будут интегрированы основные возможности наших продуктов.
Самое сложное здесь — создать базовый функционал игры, а расширение его возможностями продукта должно происходить так же, как и при добавлении его в текущую версию демо-стенда.
Мы только начали, потому что это дело не быстрое, но знаем, что в ближайшее время функционал будет показан в реальной игре.
Вместо вывода
Мы прошли долгий путь: от отсутствия обратной связи до возможности продемонстрировать функциональность наших продуктов не только внутри компании, но и за ее пределами, чтобы сделать получение обратной связи быстрым.Главное, что мы поняли — чтобы обратная связь была по-настоящему полезной, нужно демонстрировать результаты так, как будто клиент использует этот функционал.
Теги: #игры #ИТ-компании #ИТ-компании #Управление продуктом #бэкенд #Презентации #agile #scrum #демонстрация продукта
-
Заработок На Статьях: С Легкостью
19 Oct, 24 -
Помощь С Приложениями Xp Pro
19 Oct, 24 -
Android + Arduino + 4 Колеса
19 Oct, 24 -
Бета-Версия Surfingbird Для Ios 2.0
19 Oct, 24
