Новое банковское приложение: в 15 раз больше пользователей, на 80% быстрее тестирование
- Заказчик
- Крупный российский банк — входит в 25 крупнейших банков России по ключевым показателям деятельности (не называем заказчика по условиям NDA)
- Задача
- Перевести банк с коробочного решения на собственное, не останавливая работу мобильного банка.
У банка уже было приложение на базе коробочного решения. Но оно не позволяло быстро кастомизировать мобильный банк под потребности рынка. Поэтому банк обратился к команде Surf, чтобы создать собственное приложение.
Нам нужно было:
- Придумать новый дизайн и разработать с нуля мобильные приложения для iOS и Android со всеми возможностями, которые были у коробочного решения.
- Интегрировать приложения с существующим бэкендом.
- Обеспечить миграцию пользователей из старой версии в новую без перерывов в работе приложения.
- Внедрить пользовательскую аналитику, чтобы совершенствовать приложение на основе анализа аудитории.
- Развить новое приложение по дорожной карте и передать продукт внутренней команде банка.
В результате проекта банк:
- Полностью перешёл на собственные приложения и перестал зависеть от ограничений «коробки».
- Увеличил число пользователей в 15 раз в течение года.
- Реализовал дистанционные сервисы: открытие и закрытие счетов, платежи и переводы по СБП между физлицами, бизнесом и государством, оформление кредитов.
- Ведёт подробную пользовательскую аналитику и теперь может вносить изменения в продукт на основе данных.
- Получил свою команду для разработки приложений.
Параллельно работе с нами команда банка практически отказалась от коробочного бэкенда и перешла на собственный бэкенд на микросервисах.
Как работали над проектом: провели аудит и наладили процессы
На старте проекта наши бизнес-аналитики, дизайнеры и разработчики:
- Выявили технические возможности бэкенда и ограничения по реализации дизайна.
- Сформировали список необходимых API.
- Составили техническое задание.
- Описали логику работы приложения.
Это помогло избежать масштабных переделок по ходу проекта, увеличения сроков и сметы.
У банка не было сформированной ИТ-команды и устоявшихся процессов разработки. Поэтому в начале проекта мы договорились:
1. Составлять годовые, квартальные и ежемесячные дорожные карты проектов и разбивать их на релизные планы. Чтобы в каждый момент знать, над чем и когда будем работать.
2. Перейти на релизы каждый месяц, а не раз в три месяца. Так мы смогли сократить объем каждой сборки приложения и быстрее внедрять новые функции.
3. Брать в каждый релиз только три большие задачи, не больше. Если четвёртая оказывалась срочной, то мы убирали из спринта другую задачу.
Такая организация позволяет выпускать новые сборки приложений регулярно и в срок.
Разработали свежую концепцию дизайна, но отложили из-за коробочного бэкенда
Мы придумали и предложили банку новую концепцию дизайна, в которой сохранили фирменные цвета банковской группы и освежили элементы интерфейсов. Сделали всё с учётом ограничений бэкенда.
Продуктовая команда банка оценила этот дизайн и хотела внедрить. Но руководство решило отложить это до момента, когда банк перейдёт на свой бэкенд на микросервисах.
Спланировали состав первой версии приложения и последующих доработок
По ходу проекта команда банка составляла ежегодные и ежеквартальные планы развития приложения.
Мы определяли приоритет новых функций и порядок их внедрения. Договорились с командой банка, что можем дополнять требования и проводить улучшения поверх минимально необходимых запросов.
За шесть лет работы мы разработали и внедрили более сотни различных возможностей. В этом кейсе не приводим все, а рассказываем про самые основные и важные для банка.
Добавили индивидуальные предложения на главный экран
Помимо работы по основному бэклогу, мы прорабатывали проблемные места в приложении и неучтённые сценарии использования. Например, добавили на главный экран баннеры с индивидуальными предложениями.
Команда банка может создавать и показывать баннеры на основе данных клиента: ему могут предложить открыть новую карту, депозит с выгодными условиями, или оформить другой продукт.
Интегрировали удобные способы переводов и платежей внутри и за пределами страны
В соответствии с требованиями национальной системы платёжных карт (НСПК) и системы быстрых платежей (СБП) реализовали платежи между разными типами клиентов:
- C2C (customer-to-customer) — денежные переводы между физическими лицами по номеру телефона.
- C2B (customer-to-business) — оплата по QR-коду от физических лиц в пользу юридических лиц и ИП.
- C2G (customer-to-government) — платежи от граждан в пользу государства через СБП вместо платежей по реквизитам.
Также добавили бесконтактный поиск NFC-меток, чтобы пользователь оплачивал покупки смартфоном даже если оплачивать банковской картой через приложение-кошелёк он больше не может.
Чтобы пользователи могли переводить деньги по номерам телефонов и в другие страны, мы добавили в приложение справочники номеров разных стран. При переводе страну определяли по коду телефона.
Реализовали дистанционную верификацию клиентов и открытие счетов
Для этого подключили Know Your Customer Solutions (KYC) — процедуры по сбору и обработке персональных данных и биометрическому распознаванию клиентов перед тем, как открыть счета и позволять автоматически проводить банковские операции.
Чтобы KYC работали корректно, проработали передачу данных между всеми независимыми сторонами:
- Нами как фронт-разработчиком.
- Пользователем как владельцем и источником данных.
- CRM банка как обработчиком данных.
- Базами данных из бэкенда.
- ЕСИА и другими государственными службами.
Также настроили защищённую передачу данных между сторонами.
Чтобы дистанционно верифицировать клиентов и открывать счета, интегрировали приложение банка с Госуслугами и единой биометрической системой.
Чтобы собирать данные клиента и направлять его по всем шагам, разработали мобильные анкеты и экраны с подсказками и инструкциями.
Добавили в пуш-уведомления диплинки, ведущие в конкретные разделы приложения
Когда пользователь нажимает на такую ссылку, операционная система смартфона перенаправляет его на соответствующую страницу в приложении. Там пользователь увидит предложение от банка: например, сниженную ставку по кредиту или цифровую карту.
Интегрировали работу трёх команд и наладили обмен данными
На проекте мы работали с командой бэкенда через ещё одного подрядчика банка: он адаптировал и передавал наши запросы друг к другу. В него стягивалась вся информация с бэкенда и из внутренних систем банка — например, из справочников.
Как это работает: оформление онлайн-заявки на кредит
Для пользователя процесс выглядит просто и понятно. Но в основе этой функции — технически сложная логика и интеграции со множеством банковских систем:
- В бэкенде банка обрабатываются транзакции и KYC-верификация.
- Из справочников и баз данных подтягивается информация для анкет.
- Отдел оценки рисков анализирует информацию и рассчитывает процентную ставку.
Такая схема работы потребовала от всей команды проекта особенной внимательности: мы подробно документировали все требования и действия.
В результате мы реализовали приложение, которое стабильно работало с учётом всей специфики внутренних систем банка.
Повысили качество и скорость тестирования с помощью автотестов
Проект задействует десятки ответственных лиц и развивается короткими итерациями. В каждой итерации может быть 10 новых изменений.
Чтобы продукт функционировал, нужно проверять каждую сборку и устранять ошибки вовремя. Иначе каждая пропущенная ошибка будет тормозить или ломать больший объём работ.
На таких проектах мы рекомендуем автотесты: с ними можно тестировать больше за меньшее время и обнаруживать потенциальные проблемы гораздо раньше.
Код приложений покрыли тестами на 90% и ускорили тестирование с помощью автотестов.
На первом этапе работы мы использовали кроссплатформенный фреймворк с открытым исходным кодом Calabash. Со временем перешли на более эффективный инструмент, Appium.
Теперь мы экономим 8 часов на каждой сборке и уменьшили утечку дефектов пользователям на 25% — автотесты обнаруживают эти дефекты.
Автотесты пишем на «человеческом» языке — русском диалекте Gherkin. К тестированию на Gherkin легко подключить любого тестировщика, даже если он не был знаком с технологией.
Сократили количество багов по ходу проекта
В начале проекта мы столкнулись со старыми багами, которые висели без проработки. Ошибки выявлялись и на регрессионном тестировании. Параллельно с их исправлением наша команда планировала, как избежать появления багов в дальнейшем.
- Договорились с банком о тестировании на готовом бэкенде. Выстроили релизы так, чтобы они выходили на 7–10 дней раньше, чем мы начинали внутреннее тестирование. За счёт этого мы сократили число багов на 30%.
- Объединили наши тестовые модели с банковскими. Сопоставили модели и выявили недочёты и непокрытые кейсы. Эти данные включили в новый расширенный тестовый модуль, который также сократил число багов.
- Тестировали смежные функции вместе. Например, переводы C2B, C2C и Me2Me. Это помогло ещё больше расширить тестовый модуль и найти упущения.
- Ввели импакт-отчёт и добавили больше общения в работу. Перестроили процессы так, чтобы было больше обратной связи между коллегами, а функции детальнее проверялись на этапе разработки.
После этих изменений регрессионное тестирование обнаруживало не более 1–2 багов.
Результаты
Банк полностью перешёл на кастомное решение — и перестал зависеть от ограничений коробочного продукта и поставщика.
В новом приложении есть все основные банковские возможности: дистанционное открытие и закрытие счетов, платежи и переводы по СБП, оформление кредитов и другие функции.
Переход прошёл без потери клиентов, а за первый год работы нового решения пользователей стало в 15 раз больше.
Банк может использовать пользовательскую аналитику для развития продукта, которую мы внедрили в новое приложение.
Число багов минимизировали за счёт налаженных процессов разработки и тестирования.
Перевели в команду банка часть наших сотрудников, работавших над приложением, и передали проект банку.