Иногда пора остановиться и по-новому взглянуть на то, что вы делаете.
Что, если предыдущие решения когда-то казались правильными, но теперь создают проблемы? Наберитесь смелости и начните с нуля.
А пока расскажу, как 8 лет назад QIWI сделала коммерчески правильный выбор при запуске продукта, но в 2015 году ей пришлось многое изменить.
Как это все началось? Давным-давно, в далекой-далекой галактике, был 2008 год. Компания QIWI задумывается о предоставлении интернет-магазинам способа оплаты с электронного кошелька QIWI. Протокол, который уже использовался, предназначался для клиентов, имеющих учетную запись на стороне провайдера.
Например, клиент хочет пополнить баланс мобильного на 100 рублей – пожалуйста, 765 рублей – это тоже не вопрос.
В терминале или личном кабинете достаточно указать номер договора с провайдером и произвести оплату.
Этот протокол исторически назывался push. Если клиент покупает iPhone 3G в интернет-магазине за 22 999 рублей, он не может заплатить 20 000 или 25 000 рублей, ему необходимо перевести в магазин ровно 22 999 рублей, поэтому необходимо было разработать новый протокол.
Главным козырем компании на рынке были платежные терминалы, и чтобы использовать их по максимуму, необходимо было поддерживать отсрочку платежа.
Очевидно, что ближайшей реальной аналогией является выставление счетов.
Но как уведомить и как связать аккаунт с пользователем? Конечно, мы решили использовать номер телефона, потому что.
компания уже успешно использовала его в качестве идентификатора.
Так появился протокол работы со счетами (Pull), когда клиент выбирает товар в магазине и сообщает, что хочет оплатить его с помощью QIWI. Дальше он вводит номер телефона, сервер магазина выставляет счет через API, и счастливый пользователь идет платить в терминале, на qiwi.com или к партнерам.
В результате магазин получает уведомление об успешной оплате или отмене счета.
После того как API был разработан, его начали активно продавать.
Магазины выставляли счета и просили покупателей пройти к терминалу или на сайт qiwi.com. Через некоторое время стало очевидно, что нам нужна страница, которая красиво объясняла бы пользователю, как удобнее всего оплатить счет. Это было сделано и названо страшным словом «касса».
При этом была создана система подачи заявок на подключение и настройку протоколов – ishop.qiwi.com .
Эволевая деградация Изначальная логика платежной страницы была проста: авторизуйтесь и оплатите со своего баланса QIWI. Ввод номера телефона остался на стороне магазина, потому что это подразумевалось протоколом биллинга.
Уже тогда мы наступили на грабли ожидания разумности, решив, что протокол прост и понятен.Оказалось, что если что-то может пойти не так, то оно пойдет туда, но об этом позже.
Затем появились привязанные карты, мобильная коммерция, привязанные Webmoney и пробный запуск микрокредитования.
Все эти нововведения постепенно изменили страницу оплаты счетов, но без учета общего пользовательского опыта.
Например, мобильная коммерция не требовала входа с паролем, поэтому добавили страницу предварительного выбора способа оплаты, что усложнило оплату с баланса.
Помимо реализации разных способов оплаты, произошли и изменения, обусловленные внутренними требованиями, например, ужесточение правил смены паролей.
Все сделано логично и правильно с точки зрения бизнеса, но давайте посмотрим на сценарий оплаты пользователя к 2014 году.
Предположим, вы клиент, который когда-то пользовался QIWI, но прошло полгода.
За это время оператор мобильной связи мог передать номер другому человеку, поэтому кошелек был помечен как неактивный.
Вы вносите деньги через терминал, приходите в магазин, выбираете оплату через QIWI, вводите номер телефона и переходите на страницу оплаты счета.
Первая страница открывается с предварительным выбором способа оплаты, далее следуют страницы регистрации, подтверждения оплаты с выбором способа оплаты и смс-подтверждения операции.
В итоге для нового пользователя или пользователя, забывшего пароль, было до 8 шагов с адской логикой.
Вишенкой на торте была оплата банковской картой только после привязки ее к кошельку.
С момента своего основания QIWI больше напоминала стартап, чем банк, поэтому продукт разрабатывался в ходе реализации бизнес-проектов, например, интеграции с «Мегафоном», и приоритет отдавался скорости внедрения.
Подход очень эффективен, но иногда требуется тщательная очистка.
MVP на костылях Чтобы сделать процесс оплаты более удобным, мы составили план с полным редизайном всей платежной страницы.
Но стало ясно, что это долгий процесс.
Поэтому параллельно с работой над UX/UI мы отобрали наиболее важные изменения для текущего продукта.
Сначала мы решили авторизоваться с помощью одной СМС вместо пароля, то есть OTP — одноразовый пароль.
Мошенники быстро научились обманывать пользователей, выуживая нужные СМС, поэтому OTP включали только проверенным партнерам с большим оборотом и без возможности вывода средств.
Также для сценария OTP существенно упрощена регистрация новых пользователей: требуется лишь ввести СМС и согласиться с предложением.
Мы также вырезали ненужные страницы и добавили немного хитрости.
По сумме счета сервис стал определять, какой способ оплаты будет удобен пользователю: если у него есть баланс в кошельке, то оплата осуществляется всего в один клик.
В этот же момент вместе с командой, отвечающей за карточные платежи, мы произвели оплату, введя на странице данные карты без предварительной привязки.
За 3 месяца все изменения были реализованы и обороты выросли вместе с конверсией.
Однако страница оплаты по-прежнему была частью того же приложения, что и сайт, поэтому статистику правильно посчитать не удалось, а технологический долг зашкаливал.
Также сложно было гарантировать стабильность во время партнерских акций и синхронизировать изменения в продуктах.
Пришло время заняться обновлением сервиса.
О дивный новый мир, или СПА-зона В 2015 году QIWI начала переходить на микросервисную архитектуру.
Лучшим кандидатом на реструктуризацию стала платежная страница.
Было решено создать отдельный Java-сервис, реализующий REST API и веб-приложение.
Хорошо, что индексация поисковыми системами не потребовалась.
На тот момент у компании не было опыта создания веб-приложений (SPA — одностраничных приложений) с использованием React JS. Потребовалось время, чтобы нанять фронтенд-разработчика, а также освоить новые подходы: инструменты обучения, выбор стека разработки, настройку непрерывных сборок в TeamCity и внутреннем репозитории npm, выбор методологии тестирования.
К моменту начала разработки UX-прототип был готов и прошел испытания, что позволило упростить проектирование API. Конечно, команде пришлось расчистить большой пласт наследия, иногда используя костыли, потому что… старая архитектура не предполагала такого варварства.
Для тех, кто понимает React JS
На момент разработки такие решения, как redux, не были так популярны, как сейчас.
Поэтому мы использовали подход наблюдаемого состояния.
Изначально мы использовали баобаб, но на тот момент его Computed состояние было плохо проработано, и мы перешли на собственное подобное решение, потому что внедрение зависимостей было необходимо как клей для компонентов.
На схеме показано разделение компонентов приложения на слои.
От обычных схем работы flux или redux он отличается своими эффектами — действиями по загрузке данных и модификации состояния, которые выполняются при инициализации компонента (comComponentDidMount).
Существуют также вычисляемые состояния (Computed) и кэшируемые загрузчики данных (Loader).
Проанализируйте это За полгода мы создали и подготовили к запуску первый микросервис в компании.
Но не все прошло гладко.
Декабрь — не лучшее время для тестирования новых решений, влияющих на платежи.
Забавно, что первыми новинку получили партнеры с небольшим оборотом.
Мы запустили продукт, постепенно контролируя колебания оборотов, конверсий и ошибок.
В течение декабря мы отладили получение базовой статистики по активным партнёрам, пользователям и общей конверсии, исправили ключевые проблемы, но к январским праздникам почти всех вернули в старое приложение.
В январе начался массовый запуск, который длился 3 месяца, потому что.
Постоянно выскакивали неожиданные ошибки.
Например, некоторые партнёры делали POST-редирект на страницу, хотя в протоколе был описан только GET. Был крупный партнер, который открыл страницу в браузере Adobe Air, где стандарты были очень плохими.
И конечно партнеры, которые использовали старые протоколы или просто игнорировали всю документацию и открывали не страницы входа, а то, что им казалось подходящим.
Поэтому в новой версии продукта мы сосредоточились на аналитике, а именно на поиске проблемных показателей.
Они помогли нам сделать много неожиданных открытий.
Когда продукт разделили, стали строить воронки для каждого способа оплаты в сочетании с типом провайдера и валютой, в которой он работает. На поверхность вышли проблемы, которые терялись в общем графике оборота и конверсии.
Также мы были удивлены, увидев, что многие, даже крупные партнеры, не отправляют клиента на страницу оплаты, а лишь говорят, что счет выставлен и его можно оплатить где-то в QIWI. Если вы используете протокол Pull, обязательно делайте редирект на bill.qiwi.com, иначе вы усложните жизнь своим клиентам и потеряете до 30% конверсии.
Эти и другие проблемы мы научились решать благодаря нестандартному поведению нового продукта.
AliExpress был очень рад запуску.
Давно ждали мобильную раскладку на странице оплаты.
Интересно, что количество пользователей мобильной версии значительно выросло после появления удобного пользовательского интерфейса и достигло 40% и более.
В дни акций на AliExpress доля пользователей с мобильными интерфейсами достигла 80%.
В целом оборот по картам увеличился более чем в 2 раза за счет серии тестов гипотез! Во многом это стало возможным потому, что… проектный подход с максимальной ориентацией на запуск проекта был заменен поэтапной разработкой одного продукта одной командой.
Рад, что после запуска продолжается активная разработка, и вскоре мы поделимся хорошими новостями.
Персональный, программист Работаю в QIWI 5 лет, пришел программистом Flex-AS3. Команда разработала приложения для социальных сетей.
Потом были node.js, Angular JS и ресторанный стартап.
Переход на управление проектами на должность аналитика/менеджера проектов с интеграцией и запуском eBay-QIWI, закрытием старого ishopnew.qiwi.ru и переходом на ishop.qiwi.com, а также запуском новой оплаты счетов страница.
Сейчас я отвечаю за разработку b2b-продуктов для электронной коммерции: страниц оплаты счетов, ishop.qiwi.com и системы внутреннего мониторинга провайдеров.
Получилось собрать интересный опыт как в небольшой компании, так и в крупном бизнесе с нескольких сторон: разработка, управление проектами, бизнес по разработке продуктов.
Мне нравится, что наблюдается сдвиг в сторону гибких и небольших продуктовых команд. Однако могу отметить, что этот стиль подходит не всем, потому что… На каждом члене команды лежит большая ответственность, а например, тимлиды, наоборот, должны способствовать большей независимости разработчиков, которые распределены по командам.
Однако это позволяет крупной компании стать во многом такой же гибкой, как небольшой стартап, а всей команде получить уникальный опыт. Не так уж много компаний, которые сами создают и развивают продукты и при этом действительно упрощают жизнь своим пользователям.
Киви – один из них.
Запуск собственного продукта меняет ваш взгляд на мир, поэтому компания поощряет это, но, как мы знаем, лишь немногие стартапы перерастают в настоящий бизнес.
QIWI предлагает разработать продукт, которым будут пользоваться тысячи, десятки или сотни тысяч пользователей – это возможность для роста и вдохновляющий опыт. Сейчас мы готовимся к значительному обновлению партнёрского сайта подключения QIWI — ishop.qiwi.com. Он пока, мягко говоря, не идеален, но мы собираемся существенно изменить подход к работе с партнерами, и для этого крайне важна новая архитектура с открытым API.
Вот почему я приглашаю тебя Старший Java с опытом написания REST API присоединится к нашей команде и качественно изменит мир для тысяч наших партнеров в этом году.В общем, мы в QIWI всегда будем рады разработчикам Java и JS (React JS), потому что… Есть много интересных направлений развития.
А еще у нас есть тихое время и регулярные хакатоны.
Присоединяйся! В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Мы долго обсуждали, писать ли статью доступную или с резким уклоном для профи, и вот решили спросить у вас 60,78% Хотим более технический уклон 155 35,69% Больше информации о проблемах в разработке продукта и практических решениях 91 23,92% Мне нравится исторический взгляд и выявление больших проблем компаний 61 25,88% Хорошо, пишите больше 66 21,57% Читаю, бесполезно 55 Проголосовали 255 пользователей.
85 пользователей воздержались.
Теги: #Qiwi #оформление заказа #запуск нового продукта #запуск проекта #опыт #поиск сотрудников #разработка сайтов #платежные системы #программирование #Анализ и проектирование систем
-
Сообщество
19 Oct, 24 -
6 Инструментов Для Автоматизации Процессов
19 Oct, 24 -
Почему Закругленные Углы Легче Читать
19 Oct, 24 -
Архитектор Ie8 Придет В Рит!
19 Oct, 24 -
Подробно О Стрип-Сканерах В Аэропортах
19 Oct, 24 -
Как Odesk Теряет Фрилансеров
19 Oct, 24
