Вибачте, ми запускаємо новий продукт

Інколи приходить час зупинитися і поглянути по-новому на те, що ти робиш. Якщо колишні рішення колись здавалися вірними, а тепер створюють проблеми? Наберіться хоробрості і почати з чистого аркуша. А я тим часом розповім, як 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 — one time password.

Шахраї швидко навчилися обманювати користувачів, вишукуючи бажану смску, тому ОТР включали тільки для перевірених партнерів з великим оборотом і без опції виводу коштів. Також для сценарію з ОТР значно спростилася реєстрація нових користувачів, вимагала тільки введення смс і згоди з офертою.
Ще ми скоротили зайві сторінки і додали трохи розуму. Виходячи із суми рахунку сервіс став визначати, який з методів оплати буде зручний користувачеві: якщо у нього був баланс на гаманці, то до оплати залишався лише один клік. В цей же момент спільно з командою, відповідає за оплату по картках, зробили оплату з введенням реквізитів картки на сторінці без попередньої прив'язки.
За 3 місяці всі зміни були реалізовані і оборот пішов вгору разом з конверсією. Проте сторінка оплати раніше входила в один додаток з сайтом, тому статистику було неможливо порахувати коректно, а технологічний борг зашкалював. Також було складно гарантувати стабільність роботи в моменти акцій у партнерів і синхронізувати зміни в продуктах. Прийшов час взятися за апгрейд сервісу.
Чудовий новий світ, або SPA зона
У 2015 році в QIWI стали переходити на микросервисную архітектуру. Кращим кандидатом на перебудову виявилася сторінка оплати. Було вирішено зробити окремий Java-сервіс, який реалізує REST API і веб-додаток. Добре, що індексація пошуковими системами не була потрібна.
Досвіду створення веб-додатків (SPA — single page application) на React JS у компанії тоді ще не було. Потрібен час, щоб найняти фронтенд-розробника, а також освоїти нові підходи: вивчення інструментів, вибір стека розробки, настройки безперервних збірок в TeamCity і внутрішнього npm-репозиторію, вибір методики тестування.
До моменту початку розробки був готовий UX-прототип, який пройшов тести, що дозволило спростити проектування API. Звичайно, команді довелося розгорнути великий пласт спадщини, іноді підставляючи милиці, т. к. стара архітектура не припускала такого варварства.
Для розуміючих React JS
На момент початку розробки рішення як redux, були не так популярні, як зараз. Тому використовували підхід вами-state. Спочатку ми використовували baobab, але на той момент у нього було погано опрацьований Computed state, і ми перейшли на власне аналогічне рішення, т. к. був необхідний dependency injection в якості клею для компонент. На діаграмі показано розподіл компонент програми на шари. Від звичайних схем роботи flux або redux відрізняється ефектами — діями завантаження даних і модифікацій стану, які виконуються при ініціалізації компонента (componentDidMount). Також тут є обчислювані стану (Computed) і кешируемые завантажувачі даних (Loader).
Аналізуй це
За півроку ми зробили і підготували до запуску перший микросервис в компанії. Але не все йшло гладко. Грудень — не найкращий час для обкатки нових рішень, що впливають на оплату. Забавно, що першими новий продукт отримали партнери з невеликим оборотом. Ми запускали продукт, поступово контролюючи коливання обороту, конверсії і помилки.
За грудень налагодили отримання основної статистики за активним партнерам, користувачам, загальною конверсії, виправили ключові проблеми, але на січневі свята майже всіх повернули на старе додаток.
У січні почався масовий запуск, який тривав 3 місяці, оскільки постійно виникали несподівані помилки. Приміром, частина партнерів робила POST переадресацію на сторінку, хоча в протоколі описана тільки GET. Був великий партнер, який відкривав сторінку в браузері Adobe Air, де зі стандартами все дуже погано.
Ну і звичайно, партнери, які використовували старі протоколи або просто ігнорували всю документацію і не відкривали сторінки входу, а щось, що їм здалося доречним. Тому в новій версії продукту ми робили упор на аналітику, а саме на пошук проблемних показників. Вони допомогли нам зробити безліч несподіваних відкриттів. Коли відділили продукт, стали вибудовувати воронки по кожному методу оплати в поєднанні з типом провайдера і валютою, за якою він працює. Проблеми, які губилися в загальному графіку обороту і конверсії вийшли на поверхню.
Ще ми з подивом побачили, що багато хто, навіть великі партнери, не відправляють клієнта на сторінку оплати, а лише кажуть, що рахунок виставлений і його можна оплатити десь в QIWI. Якщо використовуєте Pull-протокол, перевірте, що переадресуете на bill.qiwi.com інакше ускладнюєте клієнтам життя і втрачаєте до 30% конверсії.
Ці та інші проблеми з-за нестандартного поведінки ми навчилися підтримувати в новому продукті.

Найбільше запуску були раді в AliExpress. Там давно чекали мобільного верстки на сторінці оплати. Цікаво, що число користувачів мобільної версії істотно зросло після появи зручного UI і досягла 40% і більше. У дні акцій на AliExpress частка користувачів з бездротовими інтерфейсами досягала 80%.
Оборот по картах взагалі вдалося підняти більш ніж в 2 рази низкою перевірок гіпотез! Багато що з цього стало можливим, оскільки проектний підхід з максимальним фокусом на запуск проекту змінився поетапним розвитком одного продукту однією командою. Радує, що після запуску активний розвиток триває, і незабаром ми поділимося хорошими новинами.
Особисте, программистское
Я працюю в QIWI 5 років, приходив програмістом на Flex-AS3. Командою розробляли програми для соціальних мереж. Потім були node.js і Angular JS і ресторанний стартап. Перехід в проектне управління на посаду аналітика/проектного менеджера з інтеграцією та запуском eBay-QIWI, закриттям старого ishopnew.qiwi.ru і переходом на ishop.qiwi.com, а також запуском нової сторінки оплати рахунку. Тепер я відповідаю за розвиток b2b-продуктів для e-commerce: сторінки оплати рахунку, ishop.qiwi.com і системи внутрішнього моніторингу провайдерів. Вийшло зібрати цікавий досвід роботи і в малій компанії і у великому бізнесі з декількох сторін: розробка, проектне управління, бізнес з розвитку продуктів.
Мені подобається, що зараз відбувається перехід до agile і невеликим продуктовим командам. Правда, можу відзначити, що не всім підходить такий стиль, т. к. на кожного учасника команди лежить велика відповідальність, а приміром, тимлиды, навпаки, повинні сприяти більшої самостійності розробників, які розподілені по командам. Однак це дозволяє великої компанії багато в чому ставати такою ж гнучкою, як і маленькому стартапу, а всій команді отримувати унікальний досвід.
Не так багато компаній, які самі створюють і розвивають продукти, і при цьому дійсно спрощують життя своїм користувачам. QIWI — одна з них. Запуск власного продукту змінює погляд на світ, тому в компанії це заохочують, але як ми знаємо, одиниці стартапів доростають до реального бізнесу. QIWI пропонує розвивати продукт, яким користуються тисячі, десятки або сотні тисяч користувачів — це можливість для зростання і надихаючий досвід.
Зараз ми готуємося до значного оновлення сайту підключення партнерів QIWI — ishop.qiwi.com. Поки він, м'яко кажучи, не ідеальний, але ми збираємося значно змінити підхід до роботи з партнерами, а для цього вкрай важлива нова архітектура з відкритим API.
запрошую Senior Java з досвідом написання REST API приєднатися до нашої команди і якісно перевернути світ для тисяч наших партнерів вже в цьому році.
В цілому ми в QIWI завжди будемо раді Java і JS (React JS) розробникам, т. к. цікавих напрямків розвитку дуже багато. Ще у нас є тиха година і регулярні хакатони. Приєднуйтеся!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.