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

От SMS-банкинга к мобильным приложениям

Само собой, все не случилось моментально, любая новая идея проходит протяженный путь перед тем, как стать мейнстримом. Потому что нужны технологии, клиентская база и понимание аудиторией того, что эта новинка ей необходима. Сложно сказать наверняка, когда появилось «самое первое» приложение для мобильного банкинга — в Европе, вероятно, примерно в 2010—2011 годах. В чем-то первые такие программы и SMS-банкинг были очень похожи: они предлагали самые базовые функции в виде, например, проверки остатка на счете. Вопрос в удобстве.

«Приложения банков начинались как и все остальные мобильные приложения: часто как дополнение к существующим приложениям для веба или для десктопов. Они были тем, что позволяло добавить мобильности и решить самые простые функции. Например, посмотреть баланс — это первичная функция, которая закладывалась в приложение мобильного банка», — поясняет Сергей Юров, глава разработки (мобильного банка «Альфы») InSync.

Тогда, по словам эксперта, для решения задач не требовался какой-то сверхсерьезный подход с исследованиями на ниве UX/UI, цели ставились предельно простые, в том числе с технической точки зрения.

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

На заре развития смартфонов разработка иногда строилась по неэффективным по сегодняшним меркам сценариям. Заказчик приложения нередко руководствовался своим видением того, как все должно выглядеть и работать: «Мне хочется так, потому что я так вижу». Оно и понятно: функций немного. Глубоких исследований рынка не проводилось, а в случае необходимости внести корректировки было проще: время приложений-«комбайнов», объединяющих в себе множество возможностей, еще не пришло.

От разработки «мне так хочется» к «дискавери-фазе»

Свою лепту вносил и Android с его фрагментированностью: тогда были сотни, если не тысячи моделей смартфонов под управлением разных версий операционной системы, модернизированной самими вендорами. Проблемы возникали на уровне внутренних протоколов. «А еще был Windows», — смеется наш собеседник, вспоминая мобильную версию ОС от Microsoft.

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

Постепенно парадигма разработки мобильных приложений менялась из начальственного «мне хочется, чтобы работало так» в «а давайте проведем исследование» — речь идет об общих мировых тенденциях, а не конкретном примере.

«Первично мы, например, смотрим, проводим исследование, нужно ли это клиентам. Используем разные пути: спрашиваем сами проактивно, проводим исследования, собираем информацию со всех площадок, с которыми работаем, начиная с форума на Onlíner и заканчивая отзывами в „сторах“», — поясняет эксперт. Это, по его словам, позволяет избежать появления продукта «в воздухе», которым «кто-то пользуется — ну и ладно».

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

Затем идея начинает «дискавери-путь», исследуется, появляется несколько вариантов прототипов того, как это может быть сделано: от путей взаимодействия внутри, понятных пользователю, до, условно, расположения кнопок. Потом тестируется на небольшой аудитории, которая выполняет определенные задания.

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

«В моей практике был случай, когда тестовые задания были составлены так, чтобы подталкивать к правильному варианту, а такого нужно избегать. Это может быть совсем мелочь, слово в вопросе с названием кнопки, — рассказывает о подводных камнях Сергей. — Когда мы столкнулись с реальными ситуациями, то увидели, что что-то не так. Начали разбираться, и пришлось вносить правки и перестраивать начало процесса».

Если все прошло хорошо, начинается самое простое — разработка и внедрение.

«А исследование, думаю, — это самый интересный и довольно продолжительный процесс, даже несмотря на то, что может быть поставлен на поток. Тем не менее это интеллектуальный труд, который сложно автоматизировать полностью», — отмечает эксперт.

Такой подход позволяет избежать ситуаций, когда продукт оказывается «тыквой», требующей полной переделки. В прошлом, когда «дискавери-фаза» не применялась, подобное случалось куда чаще — сейчас субъективное «Хочу так!» обычно игнорируют.

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

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

---

Из чего состоит приложение?

«С точки зрения структуры мобильное приложение, в том числе банковское, имеет свой фронтенд. Это непосредственно программа, которую вы скачиваете из „сторов“. Могут быть вариации, но в нашем случае front-end пишeтся на Kotlin и Swift для Android и iOS соответственно — классика.

Есть бэкендовая часть, которая опять же может быть написана на разной вариации языков, но в нашем случае это Java— популярный и распространенный язык (он сейчас на первом месте по востребованности в мире)», — продолжает Сергей.

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

С бэкендом аналогично: есть монолитные приложения, которые в себя включают весь функционал мобильного банка в одной «коробке». Соответственно, изменение в одной части «коробки» может привести к тому, что что-то сломается в другой (из-за большого количества неочевидных зависимостей). Такой сложно тестировать, дорабатывать, и все это нарастает как снежный ком. Альтернатива — микросервисный подход (плюс есть разные подходы к нему). В этом случае все разбивается на независимые функциональные «кубики», они быстро обновляются и дорабатываются, не влияя на работоспособность друг друга.

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

«Банковские приложения построены так, что за классической структурой фронтенда/бэкенда имеется еще множество точек интеграций — от классических банковских систем типа процессинга, в котором „живут“ наши карты и транзакции по ним, статусы, до каких-то сторонних систем. Это паутина, которая может расползаться бесконечно, а взаимодействие между системами унифицировано, в нашем случае через REST API», — уточняет Сергей.

Так как основные элементы являются отдельными узлами, в случае «падения» сервиса причина часто не связана с непосредственным мобильным приложением. Но и вариантов причин сбоя также немного: например, это может быть отсутствие связи с каким-то критичным сервером. В этом случае не получится ни попасть в приложение, ни авторизоваться или тем более выполнить какую-либо операцию. Или выпало звено из той самой обширной паутины сервисов за бэкендом: по итогу само приложение работает частично.

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

---

«Сейчас мы работаем с контейнерами, микросервисами, большими данными, машинным обучением, распределенными структурами, нереляционными базами данных, и все эти современные (и не очень, на самом деле некоторым по 20 лет) инструменты активно используются.

Любой продукт постоянно живет, развивается, адаптируется. Это бесконечная тема. Меняются какие-то тенденции — нужно подстраиваться. Путь, который был понятен пять лет назад, сегодня уже просто не зайдет. Растет количество функций, появляются все более сложные задачи. Это высококонкурентная среда, все приложения — банковские и не банковские — становятся мультифункциональными, так как выполняют не только основную функцию, но и нанизывают приближенные сервисы», — пояснил Сергей.

Он добавил, что сегодня разработка перестала быть «просто процессом», речь скорее о людях, способных исследовать, собирать результаты, предлагать идеи и реализовывать их на сложном техническом уровне, — это люди-творцы. Плюс имеет место гибкий подход к разработке и технологии.

Спецпроект подготовлен совместно с закрытым акционерным обществом «Альфа Банк», УНП 101541947.

Наш канал в Telegram. Присоединяйтесь!

Есть о чем рассказать? Пишите в наш телеграм-бот. Это анонимно и быстро

Перепечатка текста и фотографий Onlíner без разрешения редакции запрещена. ng@onliner.by