Как продавать backend продукт внутри компании

    image


    Среди разработчиков есть люди, которые хотят видеть, что их продуктом пользуются. Но что делать, если продукт еще в разработке? Или разработан, но нет первых пилотных клиентов? В обоих случаях нужна обратная связь, чтобы понимать, какие возможности продукта востребованы рынком, а какие нет. А если всё это осложняется трудностью представить результаты работы для не-технарей? Ну и самое сложное — если продукт нужно продать внутри компании, чтобы его начали продавать клиентам?


    Как наша команда решала эти вопросы под катом.


    Пара слов о продуктах команды


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


    Зачем нужна обратная связь?


    В компании много продуктовых команд и почти все работают по Scrum. Одной из особенностей Scrum является постоянный сбор обратной связи: команде важно, чтобы то, что они делают, было ценным и решало проблемы клиентов, на основе этой обратной связи корректируется дальнейшая работа.


    Показывать результаты?


    В Scrum есть специальный ритуал — обзор итогов спринта (презентация итогов работы команды за период времени) — который нужен для получения обратной связи. В какой-то момент команда поняла, что объяснений, о том, что было сделано, недостаточно и начала экспериментировать с вариантами, как демонстрировать результаты работы.


    Берешь и рассказываешь!


    Идеальный вариант, когда команда небольшая и можно общаться с клиентами напрямую, но это не наш случай.


    К сожалению, с ростом компании, команда не всегда может напрямую общаться с клиентами, ведь на кону могут быть репутационные риски. В таком случае обратную связь команде дают люди, которые общаются с клиентами — интеграторы и аккаунт-менеджеры. Так уж вышло, что эти люди могут не обладать достаточными техническими навыками, чтобы из 15-20 минутного объяснения и пары картинок было понятно, что было сделано и как это работает.


    Всё просто, если продукт обладает визуальной составляющей — показать продукт как есть, как им пользоваться. Наглядно и понятно. Не требуется никаких дополнительных действий со стороны команды разработки, чтобы продукт начали показывать клиентам.


    Становится сложнее, когда у продукта нет визуальной составляющей — backend-продукт. Это какие-то API-сервисы, которые дают функционал, скрытый под капотом. Как в таком случае показывать работу продукта, да ещё и так, чтобы было понятно?


    Давным давно


    image


    Времени на подготовку было мало и команда решила — откроем Postman (cUrl/Fiddler) и покажем запросы. Для команды всё понятно: вот запрос, вот ответ. Ещё можно логи показать, да что данные в базе изменились.


    Для команды разработки минимум временных затрат и всё понятно. Но тем, кто общается с клиентами оказалось не понятно, что конкретно сделала команда, как этим будут пользоваться и зачем это вообще нужно.


    Не так давно


    image


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


    Стало намного понятнее как продукт работает.


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


    Сейчас


    image


    Команда хочет, чтобы продуктом пользовались, а значит его нужно продавать клиентам. Чтобы было проще демонстрировать функционал конечным пользователям, решили реализовать полноценный демо-стенд. За основу взяли концепт нашего Арт-директора, который болеет за наш продукт не меньше команды.


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


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


    Будущее


    image


    В команде много людей, которые хотели делать игры. Есть даже те, что делали их. Решили, что пора сделать что-то своё, куда можно интегрировать продукты. В рамках личной инициативы, решили сделать небольшую игру, в которую будут интегрированы основные возможности наших продуктов. Самое сложное здесь — сделать базовый функционал игры, а расширение продуктовыми возможностями должно происходить также, как при добавлении его на текущий вариант демо-стенда.


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


    Вместо вывода


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


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

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 8

      +1
      В компании много продуктовых команд и почти все работают по Agile.

      «Работают по Scrum», судя по контексту, наверное, корректнее будет сказать?

      Agile можно следовать, так как это манифест+набор принципов. А Scrum — это уже конкретный подход к работе, фреймворк. Интерфейс и его реализация, если позволите так выразиться.

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

      А как быть с необходимостью, например, рефакторинга или обоснованием расширения срока под ту или иную технологию? Ведь этот самый интерфейс пользователя никак не поменяется.
        0
        А как быть с необходимостью, например, рефакторинга или обоснованием расширения срока под ту или иную технологию?

        Ну так рефакторинг закладывается на оценке задачи. Все, кроме вас на покере выдают оценку 3, а вы — 6. Вас спрашивают почему. Вы говорите «ну вот тут надо переписать». Начинается обсуждение, в котором вопрос всесторонне рассматривается. Проводят следующий раунд, и или вы с командой соглашаетесь и показываете оценку 3. Или команда с вами и выдает оценку 6. Или все сойдутся на оценке 4.
          0
          Как мне показалось, эта статья больше про то, как продавать бэкенд его клиентам, в числе которых явно не только люди, участвующие в покере. Таким образом, может получиться ситуация, что и оценку 4 тоже надо продать, так как клиенты спросят «А чего так долго?».
            0
            Статья-то да. А вопрос, на который я отвечал — нет.

            А чего так долго?

            Ну, вы же все предыдущие итерации укладывались в оценки. И с чего бы в этой они вам не будут доверять?
              0
              Хорошо, в такой ситуации — ОК. Но предположим, что этот процесс внедряется в команде, где пока оценка ставится под сомнение. И мой вопрос касается как раз такого расклада.
                0
                Ну и обоснуете тогда.

                Вы просто сами себя в заблуждение ввели вопросом. Задачи оцениваются в стори-поинтах. Долго/не долго — это уже станет понятно после нескольких итераций. И там уже к ответу на вопрос «чего так долго?» у вас будет шанс подготовиться на ретроспективе. Вы там обсудите, «чего так долго?» и договоритесь о конкретных мерах, чтобы стало быстрее.
          +1
          «Работают по Scrum», судя по контексту, наверное, корректнее будет сказать?

          Да, действительно. Спасибо!

          А как быть с необходимостью, например, рефакторинга или обоснованием расширения срока под ту или иную технологию? Ведь этот самый интерфейс пользователя никак не поменяется.

          Если говорить про вариант «Не так давно», то он делался на коленке и команда не рассматривала рефакторинг этого кода, как нечто необходимое
          Если же говорить про текущий вариант, то да, как выше отметили, мы либо закладываем это в оценку задачи, либо убеждаем продуктовый офис вынести это отдельной задачей, обычно они идут нам навстречу.
            0
            Это хорошо, что продуктовый офис идёт навстречу. Ведь нередки случаи, когда этот самый офис говорит: «Да, рефакторинг — это круто. Но нам надо быстренько...».

            А вообще, подход классный!

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое