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

Что стоит за успехом приложения? Я задал этот вопрос Константину Глумову, бэкенд-разработчику и техлиду в Альфа-Банке, который принимает активное участие в создании таких продуктов, как семейный банк, детский банк и программа кэшбека. Обсудили важность открытой коммуникации и обмена опытом в команде, чем полезно совмещение ролей разработчика и девопса, а также какой специалист имеет больше шансов попасть в команду. 

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

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

В Альфа-Банке мы пошли другим путем. У нас есть два основных комьюнити: Java/Kotlin-разработчики, занимающиеся бэкендом, и команды, работающие над конкретными бизнес-задачами. В обоих случаях мы стимулируем открытое общение и обмен знаниями. Например, у нас есть общая база знаний и чаты, где можно быстро найти ответы на вопросы или поделиться своим опытом. Это создает среду, где знания свободно циркулируют, а решения принимаются быстро. Каждая бизнес-команда включает специалистов разных направлений — от разработчиков до менеджеров продукта. Такой подход позволяет нам быть гибкими и эффективно реализовывать новые идеи. 

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

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

Как устроен процесс найма и онбординга разработчиков?

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

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

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

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

Для этого у нас сформирован бэклог технических задач, который охватывает практически все современные технологии, доступные на рынке. Это позволяет нашим разработчикам не тратить свое личное время на поиск и изучение новинок вне работы. Вместо этого они могут выбрать интересующие их технологии прямо из списка рабочих задач и изучить их, работая над реальными проектами в рамках своего рабочего времени.

Были ли использованы какие-то инновационные подходы в разработке приложения? Как это повлияло?

Проблема многих продуктовых компаний, особенно тех, что долгое время на рынке, заключается в накоплении legacy-кода и устаревших технологий. Часто они не инвестируют в обновление своих систем до актуальных версий. 

Чтобы не допустить «застоя», у нас есть правило: тратить 20% рабочего времени на технические улучшения. В это время мы обновляем библиотеки, переходим на новые технологии и поддерживаем наш кластер, который состоит из 300+ микросервисов, в актуальном положении. Это не только помогает нам держать инфраструктуру в порядке, но и повышает удовлетворенность разработчиков. Так они могут сосредоточиться на написании кода, а не на рутинных задачах по отладке и деплою. 

Можешь поделиться планами на будущее вашего приложения? Есть ли какие-то новые функции или улучшения, которые вы планируете внедрить?

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

Как ты оцениваешь свой вклад в успех приложения? Есть ли что-то, чем ты особенно гордишься?

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

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

С технической стороны одним из значительных достижений была работа над миграцией нашего кластера микросервисов с Mesos/Marathon на Kubernetes и переход системы кэширования с Hazelcast на Redis. Проведенное нами исследование показало, что Redis требует гораздо меньше дискового пространства по сравнению с Hazelcast. Эти изменения позволили нам значительно снизить затраты на инфраструктуру, учитывая, что кэш используется почти в половине наших 300 микросервисов. 

Сейчас я возглавляю проект по обновлению Ansible, и это довольно важная задача для нас. Ansible, как ведущий инструмент в концепции «Infrastructure as Code», помогает автоматизировать настройку нашей инфраструктуры, снижая риск ошибок. 

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

Процесс обновления уже затянулся на год и, как мы предполагаем, продлится еще примерно полгода. Как я уже говорил, разработчики могут включать такие задачи в свои технические цели, выделяя на них до 20% рабочего времени. Но поскольку участие в таких проектах добровольное, это может занять долгое время. 

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