+1400% пользователей за год и отлаженные ИТ-процессы: что дал банку отказ от «коробки»

С новыми санкциями банкам всё сильнее приходится задумываться о том, как стать максимально независимым от третьих сторон. Особенно важным становится иметь собственное ИТ-решение, с которым бизнес может не опасаться изменений в политике и ценах правообладателя. Но кроме независимости такие решения приносят и ощутимую выгоду: и эта история рассказывает, какие плюсы и в чём банк получил сразу после перехода на собственное ДБО.

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

Нам нужно было:

В результате банк:

Параллельно работе с нами команда банка практически отказалась от коробочного бэкенда и перешла на собственный бэкенд на микросервисах.

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

Такая организация позволяет выпускать новые сборки приложений регулярно и в срок.

На старте проекта наши бизнес-аналитики, дизайнеры и разработчики:

Это помогло избежать масштабных переделок по ходу проекта, увеличения сроков и сметы.

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

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

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

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

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

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

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

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

Также добавили бесконтактный поиск NFC-меток. Эта функция позволяет оплачивать покупки смартфоном даже если оплачивать банковской картой через приложение-кошелёк больше невозможно из-за санкций.

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

Для этого подключили Know Your Customer Solutions (KYC) — процедуры по сбору и обработке персональных данных и биометрическому распознаванию клиентов. Банки обязаны проводить такие процедуры перед тем, как открывать клиентам счета и позволять автоматически проводить банковские операции.

Чтобы KYC работали корректно, проработали передачу данных между всеми независимыми сторонами:

Также настроили защищённую передачу данных между сторонами.

Чтобы дистанционно верифицировать клиентов и открывать счета, интегрировали приложение банка с Госуслугами и единой биометрической системой.

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

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

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

Как это работает: оформление онлайн-заявки на кредит

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

Такая схема работы потребовала от всей команды проекта особенной внимательности: мы подробно документировали все требования и действия.

В результате мы реализовали приложение, которое стабильно работало с учётом всей специфики внутренних систем банка.

Проект задействует десятки ответственных лиц и развивается короткими итерациями. В каждой итерации может быть 10 новых изменений.

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

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

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

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

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

После этих изменений регрессионное тестирование обнаруживало не более 1–2 багов.

Банк полностью перешёл на кастомное решение — и перестал зависеть от ограничений коробочного продукта и поставщика.

В новом приложении есть все основные банковские возможности: дистанционное открытие и закрытие счетов, платежи и переводы по СБП, оформление кредитов и другие функции.

Переход прошёл без потери клиентов, а за первый год работы нового решения пользователей стало в 15 раз больше.

Банк может использовать пользовательскую аналитику для развития продукта, которую мы внедрили в новое приложение.

Число багов минимизировали за счёт налаженных процессов разработки и тестирования.

Перевели в команду банка часть наших сотрудников, работавших над приложением, и передали проект банку.

Теперь банк развивает проект сам, и больше он не будет сталкиваться с ограничениями, которое накладывало старое решение. Если изначально приложение мобильного банкинга было сделано «по стандартным лекалам» и не учитывало особенности банка и его процессов работы, то сейчас оно работает так, как нужно этой компании. Банк может самостоятельно дополнять и изменять своё решение, и это не отнимает у него столько времени, сколько отнимала кастомизация «коробки».