Как цифровизация меняет банковскую сферу. Кейс Jusan Bank
Технологии и скорость их внедрения — ключевой фактор успешности банковского бизнеса. 14 декабря, в рамках Demo Day Jusan Business, были представлены актуальные доступные казахстанцам продукты. В этот день подразделения, курирующие направление для бизнеса, провели демонстрацию работы онлайн-банкинга для предпринимателей за последние 6 месяцев. 17 команд рассказали о достижениях и планах по своим направлениям.
Редакция bluescreen.kz поговорила с Асланом Мырзагалиевым, Product Owner Jusan Business Core, представителем внутреннего подразделения банка, которое поддерживает здоровье систем и предоставляет удобную и безопасную платформу разработки, доставки и мониторинга для продуктовых команд.
"Core — это техническое решение и использование лучших практик, которые есть в целом на рынке. Первичная наша задача — это стабилизация процессов при разработке продукта. Чтобы эти процессы работали правильно, мы проводим различные мониторинги.
Основная зона ответственности — это, так называемая, "подкапотная" работа. Если продуктовые команды зарабатывают деньги, показывая свои достижения, то нашу работу не видит конечный клиент — больше чувствует. Например, раньше клиент заходил в приложение и видел свои продукты после 10 секунд, а теперь после 5 секунд.
Мы занимаемся релизами ПО и отвечаем за то, чтобы конечному клиенту доходила последняя версия приложения. Чтобы клиент вовремя получал обновление и "доставку" на свой смартфон какой-то новой фичи, которую интегрировали мы.
У нас есть возможность управления доступности функционала со стороны клиента — feature flags. Мы можем как включить какие-то фичи, так и выключить. Вот, к примеру, вы скачали приложение, смотрите, но ничего нового не появилось. Но через какое-то время, когда "подкапотная" работа проведена, мы можем их подключить для вас. Вам не нужно обновлять приложение, скачивать еще ~100 мегабайт, апгрейд будет виден и без этого.
Были такие инциденты, когда после релиза у пользователей не работала какая-то функция. Клиент в таком случае начинает нервничать: почему у меня не получается это сделать? Подобные кейсы не только влекут негатив с клиентской стороны, но и сильно нагружают систему. Кроме того, сильно ломаются метрики, искажается картина аналитики.
Чтобы снизить градус негатива и не показывать пользователю страницу "сервис временно не доступен" мы просто её отключали.
Jusan Business использует для маркетинговой аналитики Apps Flyers и для продуктовой аналитики Amplitude. Продукт должен постоянно улучшаться и дорабатываться, и именно для этого мы собираем информацию и анализируем данные пользовательского поведения. Это помогает продуктовой команде принимать какие-то дальнейшие стратегические решения.
Анализ детальных шагов пользователя даёт возможность анализировать пользовательские потребности. Например, почему пользователь не перешел на страницу с помощью кнопки.
Отдельная история про релизы. Это определенный процесс, на котором строится дальнейшая работа. Существует определенный цикл: 17 команд участвует в разработке продуктов Jusan Business, и все эти команды должны встроиться в процесс обновления. Это как поезд, когда он отправляется — звонит колокольчик, и до этого звонка все должны запрыгнуть в свой вагон. Так и все команды должны успеть залить свои реализованные изменения до релиза. Так вот, этот поезд с релизами отправляется каждый девятый день спринта. В среднем за квартал мы выкатываем 20 релизов для web-версии, iOS и Android.
Как вы думаете, 17 команд не мешают друг другу? Нет, команда Core должна организовать процесс, в котором у разработчиков нет конфликтов на уровне слияния кода. Процесс внедрения фич проверяется по специальному чек-листу.
Далее идет процесс регресса, когда подключаются QA-инженеры с проверкой: начиная с дизайна и заканчивая функционалом. Если мы получаем апрув, то можно запускать релиз данной версии для клиента. В итоге, изменения для клиента — это нажать кнопочку "Обновить" в магазинах приложения, а для команды — огромная воронка процессов.
Есть еще мониторинг стороны клиента. Существует процедура градации обновлений. Например, для Android мы изначально позволяем обновиться только 7% пользователей, на iOS — 10%. Если всё ок и нет крашей, то открываем скачивание обновлений на все 100%.
Сам процесс обновления происходит постепенно. Грубо говоря, клиент не сразу видит изменения. У кого-то обновился банкинг, а кто-то еще не видит обновления. Этот механизм называется "Поэтапное внедрение обновления", при котором crash-аналитика позволяет своевременно реагировать на поломки. Если мы замечаем более одного краша, это означает, что нужно срочно останавливать процесс обновлений и разбираться в причинах. Для этого мы используем Firebase, где мы видим точную информацию о баге. Устраняем, заливаем и снова тестируем. Такая своевременная реакция позволяет минимизировать количество багов, для того чтобы этот баг увидел только один клиент, вместо десяти".