Как развивать продукт, если в команде один разработчик и два заказчика?

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



    Команда мечты


    Волею судеб мы с коллегой взяли ответственность за развитие сайта подключения b2b клиентов к QIWI (ishop.qiwi.com) и страницы оплаты счетов (bill.qiwi.com). В момент нашего великолепного пришествия в проект, команда мечты состояла из двух заказчиков (мы), одного JavaScript разработчика на удаленке и одного специалиста QA. Накануне, кстати говоря, из команды ушел серверный Java разработчик. Также в рабочей группе имелся новенький проектный менеджер, но решив, что 3 управленца на 1 разработчика — перебор — разошлись.

    Статистика Наглая ложь


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

    Единственно возможный план был начать выстраивать аналитику в поисках проблем. Поэтому, мы занялись перепроверкой основных статистических данных, которые собирались в агрегаты. Общая статистика по всем продуктам была правдоподобной. Посмотрели разрезы в наших и обнаружили, что местами данные не совпадают с реальностью от 2 до 10 раз. Аналитики, собиравшие общие агрегаты, к сожалению, были оторваны от продукта и разработки, поэтому не могли гарантировать их точность при дальнейших доработках. Предполагалось, что внешнее подразделение обеспечит независимую оценку. Однако если достоверные и объективные данные не нужны команде, то есть миллион и один способ ошибиться в подсчетах, даже случайно.

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

    Работа по развитию продукта напоминает исследование. Команда выдвигает гипотезу и всеми силами стремится её проверить, как можно быстрее и дешевле. Гипотез всегда больше, чем ресурсов на их проверку, так что аналитику мы возвели во главу угла, чтобы получать данные в режиме онлайн, даже для сырых прототипов. Ключевой метрикой всех изменений, как ни странно, стали деньги. Для этого пришлось многое сделать, в том числе написать свою систему бизнес аналитики продукта. Она позволила исследовать не только продуктовые изменения в реальном времени, но и видеть падения элементов системы, оценивая их в деньгах. Так появился еще один продукт и даже разработчик под него, но это уже совсем другая история.

    Первый стыд


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



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

    Судите сами, наши рассуждения выглядели так:

    Средний чек около 500 рублей;

    • Если клиент без нужного уровня идентификации пытался оплатить счет, то он, к сожалению, безвозвратно отменялся. Это, в теории, убивало бы конверсию и оборот;
    • Также мы 7 лет просили ограничивать сумму счета 15 000 рублей на стороне магазинов, поэтому неизвестно сколько из них сможет быстро поднять лимит;
    • Для небольших магазинов поднимать лимиты статистически бессмысленно, поэтому экспериментировать придется с крупными партнерами.

    Решили оценить время на версию с нормальным интерфейсом и правильным API. Оказалось, что потребуется три-четыре месяца и точно нужен серверный Java разработчик, которого у нас нет.
    Мы рискнули, подняв лимиты для части провайдеров с минимальным изменением интерфейса. Да, к сожалению, те пользователи, которые ничего не знали про идентификацию, получали неприглядную ошибку — счет отменен. Мы оценивали результаты в режиме онлайн, готовясь все вернуть в норму при первых признаках потери оборота. Конверсия в успешную оплату составила всего 20% и за неё стыдно. Оборот же за короткое время показал очень высокий результат и стало ясно — жизнь есть и еще какая!

    Костыли — это кошерно


    Жизнь есть, а ресурсов серверной разработки нет. Поэтому решили сделать форму, рассказывающую пользователю про уровни идентификации, если счет более 15 000 р., а пользователь аноним.
    Нашли запрос для проверки статуса идентификации и обрадовались. Осталось дело за малым: сравнить сумму счета с уровнем дозволенного для пользователя и можно идти получать лавры и зависть конкурентов… Однако, посмотрев на статистику, увидели, что существенную долю оборота занимают валютные счета. Без серверного разработчика узнать сумму валютного счета в рублях нельзя.

    К тому времени в QIWI был взят курс на микросервисы, так что мы пошли трясти, есть ли что-то у коллег. Оказалось, что да. В новеньком сервисе платежных форм нашелся запрос курса.

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

    Что делать? Правильно — небольшой костыль. Запросы на проверку отправляем только если счет больше $200. Несмотря на колебания курса, приняли решение, что $200 все-таки меньше 15 000р. Также даем возможность пользователю попробовать совершить оплату, если курс конвертации получить не удалось. (Все равно платежный процессинг не пропустит некорректные суммы.) Кстати, эта перестраховка нам очень помогла 11.11 в момент акции AliExpress. Даже с таким ограничением нагрузка была огромная и сервис с курсами упал, а страница оплаты устояла. А AliExpress акции устраивать умеет и это был реальный вызов для команды.


    AliExpress умеет удивлять!

    Выкладываем новую версию и наблюдаем почти удвоение оборота, а конверсия утроилась и пришла к 60%! Отличный результат, но нужно больше золота!

    Стоит вроде


    К сожалению, дальше двигаться в составе 4 человек было невозможно, поэтому показали лидерам отделов аналитику с результатами. И они поверили в продукт, а в команде появился специалист по здравому смыслу в интерфейсе (UX) и целый Java разработчик. Еще к нам присоединился аналитик, она же Scrum-мастер. Команда начала напоминать минимально необходимую для полноценного развития продукта. Очевидно, что был все еще большой перекос в менеджмент, поэтому мы продолжали копать в процессы и аналитику, ведь именно в ней скрывался весь основной рост оборота.

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



    Часть костылей была признана архитектурно полезными, к примеру, оставили запрос курсов через отдельный микросервис, начиная с суммы в $200.

    В итоге мы подняли конверсию до 90-95%. 90-95% — сногсшибательный результат. Это максимальный показатель, который мы видели в продукте! При этом, конверсию мы считаем честно, с учетом ухода пользователя со страницы по любой причине, в том числе отсутствия баланса. Получается, что дополнительный шаг с заполнение формы никак не влияет на желание совершить платеж для этого сценария. Оборот же возрос еще на 40%! Механика стала выглядеть очень понятно для пользователей и партнеров. Параллельно с доработками продукта договорились с отделом продаж о внедрении у крупных партнеров. Там процесс занимает гораздо больше времени, но ребята молодцы и за полгода удвоили оборот по счетам больше 15 000 р.



    Отсебятина


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

    Огромное спасибо команде, запускавшей платежи больше 15 000 рублей:
    JavaScript (React JS) Java QA
    Сергей Юферев Ладыгин Владимир Никольский Александр
    Аналитика и спринты UX Продуктовые менеджеры
    Медведева Ольга Момот Екатерина Коннов Георгий
    Брюзгин Сергей

    Конечно, улучшений и доработок было гораздо больше. Совместными усилиями команды и менеджеров по продажам получилось поднять оборот по продукту в пике на 30-40% в месяц! В нас верят, поэтому постепенно команда выросла до 14 человек.



    Появился даже маленькая продуктовая R&D команда где мы шалим на Node.js (TypeScript), Angular 2 и немного на golang, фокусируясь на быстром запуске прототипов сервисов. Скоро постараемся поделиться плодами его работы на github, что является отдельным маленьким, но вызовом.

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

    Сейчас мы приглашаем системного аналитика в команду перезапуска ishop.qiwi.com. Наша необычная команда будет рада тем, кто готов работу работать с фокусом на результат и горящими глазами, с остальным поможем и научим. :)

    P.S. React JS разработчикам и Java программистам в QIWI всегда рады во всех командах группы.
    О чем написать следующую статью?

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

    QIWI 84,30
    Ведущий платёжный сервис нового поколения в России
    Поделиться публикацией
    Комментарии 16
    • 0
      судя из голосования вас здесь «любят» :)
      • 0
        Да, от имени маленькой компании статьи воспринимались сообществом совсем иначе: Программист пытается продавать
        • +1
          видимо дело не в «большой и маленькой» ;)
          • 0
            В первой статье в комментариях вообще было бурление. :) И оно более чем объяснимо, но это не повод опускать руки. Сейчас многие команды в Qiwi делают классные и востребованные вещи, которые помогают людям.
            Наша команда — одна из них и мы стараемся честно делиться опытом, который может быть полезен другим и вставать на сторону пользователя.
      • 0
        Там процесс занимает гораздо больше времени, но ребята молодцы и за полгода удвоили оборот по счетам больше 15 000 р.

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

        Ну и как всегда минутка критики. Форма входа не отправляется при заполнении через KeeFox, на что поддержка сказала, что поддержка плагинов браузера у них не планируется. Не, ну а что? Зачем пользователям безопасность, мы лучше форму входа так обвесим яваскриптом, что он кроме как ввод пользователем ничего не примет.
        Ну а про навязчивость например вашей дружбы с мегафоном я молчу. В итоге тупо всех записали в согласившихся, и теперь я вижу вот такую картинку:
        image
        • +1
          Может это просто повлияло падение курса рубля, когда раньше на 15к можно было купить, к примеру, приличный смартфон, а сейчас нет?

          У многих крупных провайдеров было установлено ограничение на максимальную сумму в 15000 при оплате с кошелька. Снятие таких ограничений требовало доработок со стороны провайдера. Оповещением и согласованием доработок как раз и занимались менеджеры.
          Ну и как всегда минутка критики. Форма входа не отправляется при заполнении через KeeFox, на что поддержка сказала, что поддержка плагинов браузера у них не планируется. Не, ну а что? Зачем пользователям безопасность, мы лучше форму входа так обвесим яваскриптом, что он кроме как ввод пользователем ничего не примет.
          Сайт сейчас переходит на single page application + api, да. Там возможны проблемы с реализацией. Передал им. Спасибо. Кстати, а у нас на странице оплаты плагин работает?
          Ну а про навязчивость например вашей дружбы с мегафоном я молчу. В итоге тупо всех записали в согласившихся, и теперь я вижу вот такую картинку.

          Проектные менеджеры иногда излишне стараются причинить добро, знаю по себе. :) Извините.
          • +1
            Кстати, а у нас на странице оплаты плагин работает?

            Нет, цифры появляются в поле ввода, но при попытке отправить выводит «Неверный номер телефона» и сбрасывает на стандартные +7. Нужно как-то изменить JS детектирование заполнения поля ввода, или вообще выкинуть всю эту фигню и сверстать на чистом HTML+ CSS.
            Извините.

            Извиняю.
            • 0
              Жаль, спасибо, посмотрим что можно сделать. Скажу по секрету, что скоро на bill.qiwi.com можно будет забыть о паролях и регистрации.
              • 0
                неужели блокчейн? :)
                • 0
                  К сожалению, нет. Все будет проще, но гораздо удобнее для пользователей. Правда, для этого приходится менять то, что лет 7 не менялось.
        • –1
          Увольте проджект менеджера и наймите программистов. Я честно не совсем понимаю что делает проджект менеджер. Есть бизнес — тот кто знает как должен выглядеть продукт и являются его идеологами. Есть команда разработчиков во главе с лидом, которая умеет делать то, что говорит.
          • 0
            Менеджер по развитию продукта (Product owner) и есть бизнес, который «знает» как должен выглядеть продукт и отвечает за его развитие. А другой бизнес: менеджеры по продажам и сопровождению — продают то, что сделано или приходят с предложениями и проектами для крупных заказчиков. Только проектный подход работает гораздо хуже продуктового+проектного. Пример я приводил в статье "Извините, мы запускаем новый продукт" в разделе эволюционная деградация.
          • +1
            А для аналитики вы случайно ClickHouse не используете? (не путать с QlikView)
            • 0
              Веб-аналитика сейчас крутится на Vertica, а транзакционную мы собираем из Oracle и раскладываем в нужные разрезы в PostgreSQL. ClickHouse очень интересная, яндекс молодцы, но пока не использовали.
            • 0
              Как то не понятно, у вас кэш сервиса курса не справлялся с запросами, или у вас кэша не было?
              И не проще ли было курсы сразу отправлять со страницей пришедшему пользователю? ведь курс он такой, один на всех :)
              • 0
                Курс конвертации может зависить от суммы, валютных пар и у нас может меняться каждые несколько часов. Не уверен, что в том микросервисе для данного запроса прикручивали кеширование, тк это был побочный для них функционал и нагрузка обычно оставалась небольшой. У нас сейчас чистое js приложение, поэтому загружается статическая страница, а дальше запрашивает весь требуемый контекст по rest api.

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

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