Долгое время интернет-банкинг и мобильное приложение Газпромбанка разрабатывалось и поддерживалось внешним подрядчиком. Но около двух лет назад мы решили, что такими вещами надо заниматься самим, собрали команду и полностью перевели разработку на себя. В этой статье расскажем, как прошел этот переход, почему переписали код с нуля и какие выводы сделали из этого опыта. А также поделимся неочевидными выгодами инхаус-разработки.
Предпосылки перехода на инхаус
Работа с подрядчиком, даже с хорошим, накладывает отпечаток на все процессы. Вендор работает по схеме «получить ТЗ — полностью реализовать — отдать задачу». Также вендору почти невозможно уйти от бинарной системы оценки: работает / не работает. В итоге многие вещи уходят на второй план: скорость работы, интуитивность UX/UI и т. п. По сути, работа ведется закрытыми задачами и поставленными «галочками», а не классно реализованной задачей с простым и понятным UX/UI.
Внесение правок — отдельная история. В работе со сторонним подрядчиком процесс неизбежно строится на доработках при приёме задач, а не совместной разработке. А это зачастую выливается в дополнительную стоимость, а то и вообще в допники к договору. Гибко? Современно? Ни разу.
У решения заняться разработкой внутри компании есть множество приятных следствий, в числе которых прозрачность архитектуры, доступ к глубокой аналитике данных, а также оперативное внедрение обновлений и гибкий подход к тестированию гипотез.
При работе инхаус команда отвечает за продукт перед клиентом. Решения о внедрении фич, аналитика, изменения интерфейса происходят в диалоге с конечным пользователем, и это в корне меняет и развивает сам продукт.
Вообще, интервью с пользователями — штука, которая полностью раскрывается только при работе инхаус. Конечно, никто не запрещает проводить их и передавать вендору, но когда аналитика собирается «снаружи», а интервью проводит внутренняя команда, цепочка становится длинной, и телефон превращается в «испорченный».
Ну и, наконец, когда команды сидят в соседних комнатах, система их взаимодействия друг с другом выходит на другой уровень.
Как «склеить» два приложения в одно
Переход на разработку инхаус сложен сам по себе, но у нас ко всем сложностям добавилась еще одна: изначально мы хотели делать приложение параллельно, чтобы потом просто заменить одно другим. Но подобная работа всегда превращается в гонку черепахи с зайцем. Мы проанализировали положение дел и решили изменить подход: в итоге у нас получилось «переходное приложение» с симбиозом функций из обоих.
Подход неортодоксальный, даже в богатом на решения российском банкинге. Объединение иногда проводилось, но на уровне отдельных сервисов. Полный merge двух приложений — пожалуй, уникальный кейс. Для этого потребовалось создавать собственные инструменты, позволяющие использовать оба решения бесшовно для пользователя, несмотря на разницу архитектуры.
Для Android мы создали инструмент, позволяющий без модификации кода старого приложения запускать в нем фичи из нового. Обычно для таких операций необходима работа всех команд. Но у нас получилось сделать это без привлечения дополнительных «мощностей».
В итоге за два года мы полностью переписали код. Плавно и незаметно для клиентов. Сейчас от исходного приложения не осталось, по сути, ничего. При параллельной работе над двумя приложениями тех же результатов удалось бы добиться не за два, а за 3–4 года. Огромным подспорьем стала разработка дизайн-системы, по которой без лишних согласований строилось новое приложение.
Дизайн-система и Mobile First
До перехода на инхаус дизайнеры также находились на стороне вендоров. Они не могли обратиться за детализацией ТЗ к клиенту и в итоге делали «как видят». А критерием оценки было, условно, «классно» и «не очень классно». Дизайн-система уже существовала, но возможности ее масштабирования были ограничены. Поскольку у нашей команды уже был опыт разработки дизайн-систем, мы просто собрали свою собственную.
Элементы, компоненты и шаблоны позволяют разрабатывать новые экраны и внедрять фичи без долгих согласований и споров о том, какой отступ или закругление нужно использовать для каждой кнопки. То же касается шрифтов. Понятно, что в плане дизайна шрифты — сложнейшая вещь. При ограниченном экранном пространстве даже небольшое изменение может привести к «расползанию» текста на лишнюю строчку. А ведь есть процент пользователей, хоть и небольшой, кому нужна возможность увеличить шрифты...
Поэтому каждый элемент должен независимо поддерживать динамическое изменение шрифта. Дизайн-система закрывает потребности в доработке каждого элемента. Начинать большой проект именно с ее создания — наш совет всем разработчикам, особенно имеющим дело с кроссплатформенными сервисами.
Как мы делаем это сейчас? Сначала отрисовываем дизайн под мобильное приложение, адаптируем его под планшет, и уже потом — под десктоп-версию.
Тут надо отметить, что хотя доля планшетов составляет всего порядка 1%, этот формат выступают своеобразной «прослойкой» в процессе адаптации мобильного экрана под десктоп. Она позволяет бесшовно переносить решения с мобильной версии на большие мониторы, адаптируя интерфейс, шрифты и размеры элементов. Ну и, конечно, пользователей планшетов тоже нельзя обходить стороной.
Есть и еще менее распространенные сценарии использования сервисов — например, в «умном» телевизоре. Но они не требуют никаких доработок: стандартная версия интерфейса работает на любом устройстве. Единая дизайн-система и единый бэкенд позволяют выводить фичи на все каналы сразу с минимальными усилиями.
Кто использует интернет-банкинг и почему?
Около 7% наших клиентов предпочитают пользоваться интернет-банком с десктопов и мобильных устройств. Это связано с несколькими пользовательскими сценариями, и мы стремимся сократить эту долю, адаптируясь под запросы и предлагая функционал для этих сценариев на других платформах.
Например, десктопную версию часто выбирают при работе с крупными суммами денег. Это дает большее ощущение контроля. Поэтому мы реализуем наши продукты и сервисы во всех каналах и даем доступ клиентам со всех устройств. Пользователь сам выбирает, где ему удобнее закрывать свои потребности, мы же со своей стороны даем единый клиентский опыт во всех каналах.
Другой сценарий — работа с выписками, счетами, которые поступают из других каналов. Например, нужно скопировать документ из электронной почты и подставить данные в приложение. Это проще сделать на десктопе.
Интернет-банк и Client First
Офтоп: одно из наших исследований показало, что пользователи настолько привыкли «гуглить», что когда ищут банковское приложение в сторе, то не просто набирают его название, а используют поисковую строку для запросов на выдачу кредита. Хоть и офтоп, но этот пример отлично показывает, что без внимания к клиенту «продать слона» не получится.
Мобильным приложением пользуются многие, но не все. Кто-то не хочет устанавливать еще одну программу на смартфон, а кто-то просто привык работать в браузере на компьютере. Для них мы и разработали интернет-банк.
А вот еще интересный факт: 80% пользователей интернет-банка работают с ним с мобильных телефонов, поэтому когда мы разрабатывали его, то большой фокус делали на работу с мобильными устройствами.
Мы стремимся к отсутствию различий между мобильным приложением и интернет-банком. Например, иконку интернет-банка можно установить на главный экран и пользоваться как обычным приложением. Делать покупки в магазине, расплачиваясь по QR, получать push-уведомления, как в мобильном приложении.
При этом большинство клиентов еще не знают, как установить иконку интернет-банка на рабочий стол телефона, несмотря на то, что мы стараемся рассказать об этой возможности различными способами. Слишком сильно закрепился паттерн, убеждающий, что приложение можно установить только из магазинов приложений.
И мы подумали: а почему бы не совместить в мобильном приложении две технологии: мобильной разработки и веб-разработки? Так родилось новое решение — гибридное мобильное приложение, в которое мы встроили наш интернет-банк через webview. Для клиента и для банка преимущества такого решения оказались довольно существенными. Во-первых, больше не нужно ничего обновлять, все релизы интернет-банка в онлайне доставляются на устройство пользователя. Во-вторых, кратно меньший вес приложения, это особенно актуально, когда память телефона сильно ограничена. В-третьих, решение позволяет разрабатывать фичу на едином технологическом стеке сразу для всех платформ и формфакторов (iOS, Андроид, десктоп, планшет). Добавляем в этот коктейль нативные push-уведомления, возможность реализовать книгу контактов в переводах по номеру телефона — и получаем полноценное мобильное решение, закрывающее все потребности клиентов.
Сейчас мы сфокусировались на том, чтобы перевести в интернет-банкинг большинство сервисных операций, которые традиционно нужно совершать в офисе. Например, справки и выписки теперь можно легко получить и в браузерной версии. Мы упростили процедуру и (проанализировав UX) выделили функциям более заметное место в интерфейсе.
Битва за ретеншн
Ни для кого не секрет, что время нахождения пользователя в приложении является одной из ключевых метрик. И удержать пользователя можно лишь пользой и предвосхищением его действий. Банк превращается из «поставщика услуги» в проактивного и внимательного советника. Добиться этого без инхаус-аналитики данных, тестирования и оперативного внедрения фичей было бы невозможно.
Отличия в конкретном пользовательском пути можно и нужно решать с помощью персонализации. Например, создавать персонализированные виджеты. Когда мы анализировали потребности аудитории при выборе виджетов, оказалось, что запросы делятся практически пополам: около 50% хочет видеть на виджете консолидированный бюджет разных счетов, а вторая половина категорически против этого и хочет видеть на главном экране только конкретный счет.
Добавить все возможные функции в виджет нельзя — они и не поместятся, и могут раздражать кого-то не меньше, чем их отсутствие. Выход один: отдать решение клиенту, позволив самому выбирать, что показывать, а что нет. То же касается аналитики расходов, курсов валют, кешбэка — пользователи хотят иметь эту информацию в быстром доступе, но ожидают ее «упаковки» в разном виде. Поэтому без персонализации попасть на рабочий стол пользователя, а значит, и получить больше его внимания, не получится.
Другой интересный инсайт — обновление баланса после транзакции. Казалось бы, показать баланс сразу после перевода — отличное решение. НО — после транзакции многие отправляют скриншот экрана получателю, как подтверждение. Причем в разы чаще, чем чек. И если на этом экране будет также отображаться баланс, то пользователю придется отказаться от привычного поведения, чтобы не демонстрировать получателю остаток на счете. Выход: дать клиенту возможность быстро перейти с экрана перевода на главный экран, чтобы проверить баланс.
Обнаружить такие нюансы пользовательского опыта можно лишь вдумчиво анализируя данные, предлагая и проверяя гипотезы в реальном времени.
Что под капотом?
Для стандартизации и оперативности разработки наша команда разработала сервисно-цифровую платформу. Это мидл-платформа инхаус-разработки, заменяющая мидл-слой вендора. По сути, это омниканальная платформа, решения с которой переносятся на другие ОС. Она дает прозрачность и возможности для гибкой модификации, будь то требования бизнеса, ЦБ или заказчика (в случае интеграции с внешним сервисом). Переход на нее завершим в ближайшее время. Мы близки к 100% по переходу на СЦП, и в ближайшее время, в этом году, на нее будут переведены все сервисы.
В зависимости от обновления мы можем выбрать способ раскатки. С подрядчиком управление обновлениями было, конечно, возможно, но оказывалось куда менее гибким и включало огромный пласт избыточной коммуникации. Экспертиза по тестированию также находилась на стороне подрядчика.
Зависимость от платформы мы снизили до 5–10%. Это позволяет экономить ресурсы при тестировании гипотез: А/Б-тест на любой платформе дает результаты, которые применимы на другой. В зависимости от фичи мы также используем разные алгоритмы раскатки. В случае, если обновление спорное, всегда можно начать с бета-тестов — то есть с сотрудников и доверенных пользователей.
Если доработка критическая, что бывает редко, то обновление происходит внутри и частично — на фокус-группах. Если итеративное обновление невозможно (просто для примера — если меняются стандарты шифрования на бэкенде), то раскатка, конечно, 100%. Но это просто пример — в реальности все доработки локального характера и поэтому проверяются на фокус-группах, на случай, если нужна доработка продуктового сценария или сценария безопасности.
Завершение
Текст и без того получился объемным, поэтому выводы постараемся уместить в несколько абзацев.
Сокращение избыточных процессов при работе с подрядчиком освободило место для других полезных процессов, которые, в свою очередь, естественным образом привели к эволюции всего проекта в целом. Как итог — за год мы вошли в топ-6 MarksWebb Mobile Web Banking Rank 2023, прыгнув сразу на 17 строчек вверх, увеличили количество пользователей до 3,8 млн и сократили количество жалоб на 45%.
По мере изменения процессов и архитектуры мы перешли к проверке качества кода, автоматизации пайплайнов, ревью со стороны аналитиков и дизайна. Для этого были внедрены современные DevOps-практики и инструменты: gitops, quality gate, автоматическое тестирование и DevSecOps для обеспечения безопасности банковских приложений. Всё это позволило в разы уменьшить время на сборку и доставку релизов и улучшить их качество.
Дистанционные каналы являются основными каналами для взаимодействия с нашими клиентами и ключевым каналом для продажи наших продуктов. У нас не было форы, как у наших конкурентов, но за короткое время мы достигли их уровня, и сейчас у нас стоит амбициозная цель – к концу 2026 года мы хотим стать одним из лучших цифровых банков на рынке!