Разработали новое ДБО для крупного банка

Привнесли проектную культуру и процессы в команду банка

Когда мы начинали проект, у банка не было сформированной ИТ-команды и устоявшихся процессов работы по разработке приложения. Это нормально для компании, которая только запускает или масштабирует онлайн-направление. За шесть лет работы мы постоянно дорабатывали процесс взаимодействия и меняли некоторые аспекты, но сохранили три главные договоренности:

1. Мы предложили составлять годовые, квартальные и ежемесячные дорожные карты проектов и разбивать их на релизные планы. То есть мы в начале временного отрезка уже знали, над чем и когда будем работать.
2. Мы перешли на релизы каждый месяц вместо релизов каждые три месяца. Так мы смогли сократить объем каждой сборки приложения и быстрее доставлять новые работающие возможности до клиентов банка и руководства.
3. Строго ограничили число доработок или новых функций в одном релизе. Строго говоря, мы могли брать в релиз только три большие задачи и ни при каких условиях не брали четвёртую. Если четвёртая оказывалась срочной, то мы убирали из спринта ранее запланированную задачу.

Такая организация процесса позволила следовать планам и регулярно в назначенные сроки выпускать новые сборки приложений с новыми работающими возможностями. Такой процесс сохраняется в команде банка и после полного выхода нашей команды из проекта.

Разработали свежую концепцию дизайна, но отложили из-за коробочного бэкенда

Приложение банка было стилизовано под строгий фирменный стиль банка, а также унаследовало ограничения коробочного решения. Мы придумали и предложили банку новую уникальную концепцию дизайна, в которой сохранили фирменные цвета банковской группы и освежили элементы интерфейсов.

Продуктовая команда банка оценила этот дизайн и хотела внедрить, но не смогла согласовать реализацию с руководством. Руководство решило отложить переработку дизайна до момента, когда банковская инфраструктура полностью откажется от коробочных решений и сделает свой бэкенд на микросервисах.

Сфокусировались на разработке первой версии приложения и его последующей доработке

Совместно с руководителем проекта со стороны банка договорились разработать новое приложение в существовавшем дизайне и выполнить первоочередную задачу — уйти с коробочного решения ДБО на собственную платформу. Решили дорабатывать дизайн по ходу проекта строго в рамках фирменного стиля всей банковской группы.

По ходу проекта команда банка составляла ежегодные и ежеквартальные планы развития приложения — мы примерно понимали, какие функциональные возможности планирует внедрить банк в рамках года, приоритезировали их и определяли последовательность внедрения этих возможностей. В результате получали релизный план. При этом мы сразу договорились с командой банка, что можем дополнять требования банка, проводить улучшения и доработки поверх минимально необходимых запросов.

Продолжили разрабатывать и выпускать новые возможности в банковском приложении

Добавили индивидуальные предложения продуктов на главный экран

Помимо разработки функциональностей из основного банковского бэклога, мы прорабатывали проблемные места в приложении и неучтённые сценарии использования. Например, вместе с продуктами банка добавили на главный экран баннеры с индивидуальными предложениями для клиента.

Команда банка может создавать и показывать баннеры для клиента на основе его данных и предпочтений. Баннеры мотивируют открыть новую карту, оформить страховку или кредит, открыть депозит с выгодными условиями.

Интегрировали систему быстрых платежей и настроили операции между физическими лицами, бизнесом и государством

В ходе проекта доработали приложение в соответствии с техническими спецификациями и требованиями со стороны национальной системы платёжных карт (НСПК) и системы быстрых платежей (СБП). В результате реализовали в приложении платежи между разными типами клиентов:

• C2C (customer-to-customer) — денежные переводы между физическими лицами по номеру мобильного телефона.
• C2B (customer-to-business) — оплата по QR-коду от физических лиц в пользу юридических лиц и индивидуальных предпринимателей.
• C2G (customer-to-government) — платежи от граждан в пользу государства через СБП вместо платежей по реквизитам.

Реализовали возможности полностью дистанционной верификации клиентов и открытия счетов

Для этого подключили так называемые Know Your Customer Solutions (KYC) или решения типа «Знай своего клиента». Это различные процедуры по сбору и обработке персональных данных клиентов и биометрическому распознаванию перед тем, как открыть счета и позволять автоматически проводить банковские операции. Требования KYC прописаны в ФЗ № 115, а также в Положении Банка России № 499-П.

Механика достаточно простая и базовая для российских банков, но чтобы она работала корректно, необходимо проработать механизм передачи данных между всеми независимыми сторонами: нами как фронт-разработчиком, пользователем как владельцем и источником данных, CRM банка как обработчиком данных, базами данных из бэкенда, ЕСИА и другими государственными службами.

Чтобы собирать данные клиента и навигировать его по всем шагам, мы разработали мобильные анкеты и экраны с подсказками и инструкциями. Чтобы дистанционно верифицировать клиентов и открывать счета, мы интегрировали приложение банка с Госуслугами и единой биометрической системой от Ростелекома. Также настроили защищенную передачу данных между сторонами.

Добавили диплинки в пуш-уведомления, чтобы перенаправлять пользователей в конкретные разделы приложения

Банк может дополнять свои пуш-уведомления ссылками. Когда пользователь нажимает на такую ссылку в уведомлении, операционная система смартфона перенаправляет его на соответствующую страницу в приложении. Там пользователь увидит предложение, которое для него подготовил банк: например, сниженную ставку по кредиту или цифровую карту.

Настроили бесконтактную оплату через NFC

Сделали так, что клиенты банка могут оплачивать покупки бесконтактно — даже если их устройство перестало поддерживать банковские карты внутри мобильного кошелька. Для этого добавили в приложение возможность находить NFC-метки бесконтактно. Это работает так:

1. Пользователь подносит устройство к терминалу оплаты.
2. Устройство бесконтактно обнаруживает NFC-метку владельца магазина.
3. Приложение запускается и предлагает оплатить заказ по нажатию кнопки.

Механика похожа на оплату QR-кодом, только без сканирования камерой.

Внедрили международные переводы

Когда в некоторых странах СНГ заработала НСПК, банку потребовалось внедрить возможность переводить деньги в разные страны по российским и зарубежным номерам телефонов. Мы разработали такую возможность. Для этого мы добавили в приложение справочники номеров новых стран. При переводе страну определяли по коду телефона.

Работали вместе с банковской бэкенд-командой и подрядчиком по бэкенду, чтобы интегрироваться и обмениваться данными

На проекте мы работали с командой бэкенда через ещё одного подрядчика банка: он адаптировал и передавал наши запросы друг к другу. В него стягивалась вся информация с бэкенда и из внутренних систем банка — например, из справочников. Такая схема работы потребовала от всей команды проекта особенной внимательности и точности: мы подробно фиксировали все требования и действия в документации. В результате мы реализовали приложение, которое стабильно работало с учётом всей специфики внутренних систем банка.

Например, процесс оформления онлайн-заявки на кредит для пользователя выглядит просто и понятно. Но в основе этой функции — технически сложная логика и интеграции со множеством банковских систем:

• С бэкендом банка, где обрабатываются транзакции и KYC-верификация.
• Со справочниками и базами данных, из которых подтягивается информация для анкет.
• С отделом оценки рисков, который анализирует информацию и рассчитывает процентную ставку.

Внедрили автотесты, чтобы сократить время и повысить качество тестирования

На подобных проектах мы рекомендуем использовать автотесты. Проект задействует десятки ответственных лиц и развивается короткими итерациями. В каждой итерации может быть 10 новых изменений. Чтобы продукт функционировал, нужно проверять каждую сборку и устранять ошибки вовремя. Иначе каждая пропущенная ошибка будет тормозить или ломать больший объём работ.

В результате приходится вручную тестировать каждую сборку и оттягивать последующие сборки до полного устранения ошибок, либо рисковать и тестировать по ходу. Но также можно использовать автотесты: с ними можно тестировать больше за меньшее время и обнаруживать потенциальные проблемы гораздо раньше.

На первом этапе работы с банком мы использовали кроссплатформенный фреймворк с открытым исходным кодом Calabash. С его помощью мы автоматизировали регрессионное тестирование: оно проверяет стабильность приложения, ищет явные ошибки и проверяет функции, которые изменились в новой версии. За счёт внедрения автотестов мы покрыли код приложений тестами на 90% и ускорили тестирование.

Со временем мы перешли на более эффективный инструмент, Appium. Теперь мы экономим 8 часов на каждой сборке и уменьшили утечку дефектов пользователям на 25% — автотесты обнаруживают эти дефекты.

Автотесты пишем на «человеческом» языке — русском диалекте Gherkin. Использование Gherkin — хорошее решение, если компания заказчика собирается продолжать разработку самостоятельно. К такому тестированию легко подключить любого тестировщика — даже если он изначально не знаком с технологией.