Будем честны, все спецы говорят, что запускать прототип надо как можно раньше. В теории это легко, но на практике, особенно для публичной компании, страх облажаться очень большой. Поэтому постараюсь открыто рассказать о нашем опыте развития продукта, в который мало кто верил.
Команда мечты
Волею судеб мы с коллегой взяли ответственность за развитие сайта подключения 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
