От вендора до релиза каждые три недели: как Газпромбанк перезапустил мобильную разработку
В новом выпуске подкаста «Техно.Логично» Павел Наумов, первый вице-президент и куратор цифровых каналов, вместе с Павлом Каретниковым, лидером центра экспертизы iOS-разработки, рассказали, как за три с половиной года банк прошел путь от создания аутсорсного приложения до запуска собственной «фабрики» обновлений.
Как собрать больше 60 разработчиков за квартал, когда на рынке дефицит кадров? Почему ставка на веб-версию в эпоху Mobile First спасла банк после санкций? И как выстроить процесс, позволяющий выпускать релизы каждые две-три недели для 250+ репозиториев? Пересказываем самое интересное.
А еще в подкасте обсуждали планы на будущее: как AI-поиск изменит навигацию в приложении (представьте Spotlight, но в банке), зачем Газпромбанку SuperApp и маркетплейс нефинансовых сервисов, что такое проект GPBLite, который позволит пользоваться банковскими сервисами без открытия счета.
Об этом слушайте в выпуске и подписывайтесь на «Техно.Логично».
Начинали с выжженной земли
Три с половиной года назад картина была типичной для крупной компании: вся разработка — у внешнего вендора, который изначально делал бэкенд и процессинг, а экспертизы в мобильной разработке не было. Приложение отставало от рынка. На старте в банке работало всего по несколько разработчиков для каждой из платформ.
Новой команде дали железобетонный срок: за год перестроить и перезапустить цифровой канал. При этом следовало сделать все так, чтобы бизнес не пострадал,— останавливать все и уходить переписывать код было нельзя. Менять колеса приходилось на ходу.
Тактический маневр
Вместо классического подхода «год сидим в бункере, потом выходим с готовым решением» команда пошла на тактический маневр: запустили фейслифт существующего приложения — обновили визуал, переделали клиентские пути, добавили недостающий базовый функционал.
Это решило сразу две задачи. Клиенты увидели, что банк начал меняться, — оценки в сторах пошли вверх, динамика улучшилась. А команда получила первую победу и веру в то, что можно выпускать что-то стоящее. Это критично, когда приходишь на проект, где практически ничего нет, и нужно убедить людей, что революция возможна.
Подбор команды
В фоновом режиме развивалась новая архитектура. Разработку разделили на две части. Первая поддерживала фейслифт, вторая развивала основное приложение, которое должно было его заменить. Фактически команда работала на два фронта одновременно.
Одним из больших вызовов стала задача по найму. Попробуйте быстро собрать сильную команду разработчиков, когда их и так всем не хватает. Искали не просто квалификацию, а «горящие глаза» — людей, готовых идти в проект, где практически ничего нет, и делать это с нуля.
За квартал наняли больше 60 человек: по 30 на iOS и Android. Собеседований проводили по шесть-семь в день. Отбирали тех, кому интересна именно революция, а не работа по ТЗ. В итоге собрали команду, готовую строить, а не просто поддерживать.
Ставка на веб
В эпоху Mobile First было принято контринтуитивное решение — развивать не только приложения, но и интернет-банк. Идея состояла в комплексном подходе: все цифровые каналы должны развиваться единообразно, в единой стилистике. Откуда бы ни заходил клиент — с компьютера, с телефона, с планшета — пользовательский опыт везде одинаковый.
И когда приложения удалили из официальных сторов, банк не остался без цифрового канала. У него был сильный, развитый веб, которым сегодня пользуются миллионы. Интернет-банк оказался не запасным аэродромом, а полноценной платформой, позволившей не терять клиентов.
Как работает фабрика релизов
Выпускать обновления каждые две-три недели для 250+ репозиториев можно только при наличии отлаженной системы. Все держится на нескольких принципах:
- Единая дизайн-система. Единая дизайн-система гарантирует, что веб, iOS и Android выглядят и работают одинаково. Клиенту все равно, откуда он зашел, — опыт должен быть единым.
- Модульная архитектура. Приложение — не монолит, а набор независимых модулей. Каждая команда работает в своей песочнице, не мешая другим. Это дает скорость: не нужно ждать, пока соседи закончат свой кусок, чтобы залить обновление.
- Release Train и Feature Toggles. Релизы идут по расписанию. Не готова фича к релизу? Не проблема — прячем ее с помощью feature toggle. Фича в коде, но выключена для пользователей. Команда может спокойно дорабатывать, не тормозя общую сборку. Когда готово — включаем. Это избавляет от паники перед релизом и позволяет держать стабильный ритм.
О чем еще говорили?
За три с половиной года команда прошла путь от трех разработчиков и устаревшего приложения до топ-5 среди банковских приложений и топ-3 среди интернет-банков. В рейтинге MarksWebb банк за год поднялся на 17 мест.
За этими цифрами стоит инфраструктура: юнит-тесты с контролем покрытия, снапшот-тесты для проверки дизайн-компонентов, контрактные тесты для API. Мониторятся размер приложения, время старта, скорость «влития» изменений в код.
Настроили автоматические пайплайны, которые работают в два раза быстрее обычных, и внедрили форс-апдейт между версиями — если в релизе критическая ошибка, клиентов можно мгновенно перевести на новую версию. Кстати, за время подготовки этого выпуска команда достигла показателя Crash Free 99,99%.