Роль ИТ в банках сложно переоценить. Это и безопасность, и слаженность выполнения всех транзакций, и еще многое-многое другое, о чем конечный пользователь редко догадывается в принципе.
Главное, без чего трудно представить современный банк – это адекватное приложение для мобильных устройств. Человек – существо, любящее комфорт, и быстро к нему привыкающее. Поэтому, если сейчас взять и вернуть всех в парадигму, в которой банк и любое взаимодействие с ним – это походы в отделения и заполнение бумаг для любой рядовой операции, всем резко взгрустнется.
Банк должен быть доступен, приложение должно давать возможность проводить максимально доступное количество операций, настраивать автоплатежи, переводить деньги друзьям, оплачивать все, что только можно оплачивать, заказывать карты и прочее, прочее, прочее.
В Альфа-Банке у нас для этого есть Альфа-Мобайл и Альфа Бизнес-Мобайл.
Меня зовут Илья Царев, я Head of iOS, и сегодня я расскажу вам, как у нас устроен процесс разработки мобильных приложений.
Я работаю в Альфа-Банке более 2 лет, начинал со старшего разработчика, а сейчас отвечаю за всю iOS-разработку. Год назад у нас было шесть iOS-разработчиков на все про все. Сейчас нас 19. Нам удалось нормально масштабировать процесс разработки, не потеряв в качестве и сильно прибавив в скорости.
Периодов бурного развития у нас было несколько. Началось все 2 года назад, мы полностью поменяли команду разработки, в то время это была одна большая команда – 2 iOS, 2 android, несколько дизайнеров, один продакт, аналитики, и вся эта толпа (суммарно около 20 человек) разрабатывала Альфа-Мобайл.
Мы работали в этой команде и один раз в месяц выпускали апдейт приложения, в который входило около 3 фич в среднем.
Во второй половине 2016-го мы поделили эту толпу на три части. В итоге получилось, что существует приложение «Альфа-Мобайл», над которым работают три команды, у каждой из которых – свой конкретный кусок работы. Команды эти небольшие, по 5-8 человек. В каждой – по одному участнику каждой роли, то есть 1 iOS-разработчик, 1 android-разработчик, 1 дизайнер, 1 продакт, и так далее.
При этом каждая команда может пилить свои штуки независимо от остальных команд. К примеру, команда №1 занимается платежами и переводами. Команда №2 – affluent-клиентами (это такие ребята, которые обычно тратят ощутимо выше среднего, и, само собой, являются для банка довольно важными). Команда №3 – редизайном и всякими общими улучшалками.
Когда мы все это сделали, то оказалось, что работает оно гораздо круче, чем было в рамках одной команды. Каждая команда делала свои фичи, решения внутри команд принимались быстрее, и в итоге в релиз попадало больше функциональности, чем от одной большой команды. Ну и понеслось, решили делать не 3 команды, а штук 20.
И именно это с 2017-го мы начали делать.
На сегодня у нас 15 команд (включая и «Альфа-Мобайл», и «Альфа Бизнес-Мобайл»), раздроблено это все весьма сильно, и каждая команда снова делает свой кусок работы. Кто-то делает платежи и переводы, кто-то – узконаправленные фичи, например, под наше сотрудничество с FIFA. При этом, если у ребят из этой команды получается так, что прямо сейчас у них нет задач по FIFA – они начинают делать что-то другое, например, улучшают процесс авторизации и прочее.
В итоге получаем, что у нас 15 команд, они параллельно что-то делают, благодаря чему мы релизимся уже раз в 2 недели, при этом в каждый релиз входит сильно больше фич (около 10) и правок, чем ранее.
На словах такая переделка звучит довольно просто, мол, взяли и раскидали людей по командам, каждая из которых делает что-то свое, но на самом деле это повлекло довольно сложные изменения техпроцесса. Ведь команда изолирована, общается по большей части внутри себя, вокруг этого всего еще и прослойки – iOS, Android, дизайн. Все это необходимо синхронизировать, иначе всё :)
Чтобы все это не развалилось на ходу, мы привели техпроцесс вот к такому виду:
При этом у нас есть ряд автоматических проверок, мы проверяем такой код статическим анализатором (swiftlint), он позволяет быстро зафиксировать проблемные моменты, например, где-то скобочки нет, или есть риск утечки памяти. Говоря чуть больше про swiftlint – у нас включены практически все стандартные правила, а также есть несколько своих. Все это позволяет сэкономить время на код ревью.
Continuous Integration сервер (в нашем случае используется Jenkins) прогоняет статический анализатор кода, прогоняет тесты в приложении, помогает собирать и запускать его, а также пишет обо всем этом в Slack. После всего этого уже проводится ручное код-ревью.
Когда код принят, наш любимый jenkins собирает несколько сборок: для установки на тестовые устройства, для автотестов и для возможного релиза. Тестировщик внутри команды проверяет такую сборку, и если все хорошо, то код может быть влит в следующий релиз.
AppStore с недавнего времени позволяет выкатывать новый релиз не на всех людей, как раньше, а на определенный процент пользователей. Поэтому новые фичи мы сначала выкатываем на 1-5 процентов пользователей, смотрим, что там и как в целом. При необходимости исправляем что-то, выкатываем уже на 10 процентов, и так далее. Кроме того, у нас есть собственное решение, которое позволяет раскатывать конкретные фичи на определенные группы пользователей и гибко всем этим управлять. Эти два механизма позволяют нам не бояться проводить как технические, так и продуктовые эксперименты.
Все это внутри обвешано подробной аналитикой, позволяющей вовремя понять, что и где пошло не так, и как это быстро поправить. Можно также определить, что на какой-то раздел приложения заходят только 2 процента пользователей, а остальные 98% – игнорируют его. Обычно это намекает на удобство расположение раздела или на его смысл вообще.
Сейчас над «Альфа-Мобайлом» трудятся 15 iOS-разработчиков. Над «Альфа Бизнес-Мобайлом» – 3.
Кроме продуктовых команд, ребята активно участвуют в так называемых технических командах, которые появились параллельно с нашим масштабированием. У нас есть команда, которая следит за архитектурой (кстати, эта команда разработала собственное решение, которое мы применяем в Альфа-Мобайле), команда, которая разрабатывает дизайн-систему, и команда, которая улучшает наш CI/CD. На все это ребятам выделяется время в продуктовых командах.
Команда дизайн-системы разрабатывает библиотеку UI-компонентов. Когда разработчик пишет что-то такое, что может пригодиться всем, он заливает это в общую библиотеку. Поэтому, когда у нас появляется какой-то новый проект, то команда может сразу подключиться к этой библиотеке и получить много готового и полезного.
К слову, об идеальной численности команды. Как руководитель я могу сказать, что нас уже слишком много (без паники, мы все равно активно нанимаем мобильных разработчиков). Я просто к тому, что чем больше людей – тем больше времени тратится на синхронизацию, и это нормально. Кстати, по этой причине мы не рассматриваем junior-разработчиков (хотя, признаюсь, бывают исключения).
Нанимаем в основном middle, middle+ разработчиков. Это люди, которые уже достаточно уверенно знают нужные технологии, но при этом их можно заточить под себя и натаскать именно для работы в текущих командах. Мы используем много новых технологий, например, у нас более половины кода на Swift, своя собственная архитектура и есть еще несколько вещей, которые обычно не так активно используют. Конечно, стоящий senior тоже будет оценен по достоинству. А вот лидов мы предпочитаем формировать уже внутри компании.
Прямо сейчас у нас идет активный набор мобильных разработчиков, у нас есть ряд новых команд (есть много продактов с идеями, и им нужны люди в команду), поэтому, если вы чувствуете в себе силы и желание попробовать себя в разработке мобильных приложений для Альфа-Банка, не стесняйтесь – https://hr.alfabank.ru/vacancies/ios-dev
Буду рад ответить на вопросы об особенности разработки мобильных приложений в банке или об общих принципах работы у нас.
Главное, без чего трудно представить современный банк – это адекватное приложение для мобильных устройств. Человек – существо, любящее комфорт, и быстро к нему привыкающее. Поэтому, если сейчас взять и вернуть всех в парадигму, в которой банк и любое взаимодействие с ним – это походы в отделения и заполнение бумаг для любой рядовой операции, всем резко взгрустнется.
Банк должен быть доступен, приложение должно давать возможность проводить максимально доступное количество операций, настраивать автоплатежи, переводить деньги друзьям, оплачивать все, что только можно оплачивать, заказывать карты и прочее, прочее, прочее.
В Альфа-Банке у нас для этого есть Альфа-Мобайл и Альфа Бизнес-Мобайл.
Меня зовут Илья Царев, я Head of iOS, и сегодня я расскажу вам, как у нас устроен процесс разработки мобильных приложений.
Я работаю в Альфа-Банке более 2 лет, начинал со старшего разработчика, а сейчас отвечаю за всю iOS-разработку. Год назад у нас было шесть iOS-разработчиков на все про все. Сейчас нас 19. Нам удалось нормально масштабировать процесс разработки, не потеряв в качестве и сильно прибавив в скорости.
Тогда
Периодов бурного развития у нас было несколько. Началось все 2 года назад, мы полностью поменяли команду разработки, в то время это была одна большая команда – 2 iOS, 2 android, несколько дизайнеров, один продакт, аналитики, и вся эта толпа (суммарно около 20 человек) разрабатывала Альфа-Мобайл.
Мы работали в этой команде и один раз в месяц выпускали апдейт приложения, в который входило около 3 фич в среднем.
Во второй половине 2016-го мы поделили эту толпу на три части. В итоге получилось, что существует приложение «Альфа-Мобайл», над которым работают три команды, у каждой из которых – свой конкретный кусок работы. Команды эти небольшие, по 5-8 человек. В каждой – по одному участнику каждой роли, то есть 1 iOS-разработчик, 1 android-разработчик, 1 дизайнер, 1 продакт, и так далее.
При этом каждая команда может пилить свои штуки независимо от остальных команд. К примеру, команда №1 занимается платежами и переводами. Команда №2 – affluent-клиентами (это такие ребята, которые обычно тратят ощутимо выше среднего, и, само собой, являются для банка довольно важными). Команда №3 – редизайном и всякими общими улучшалками.
Когда мы все это сделали, то оказалось, что работает оно гораздо круче, чем было в рамках одной команды. Каждая команда делала свои фичи, решения внутри команд принимались быстрее, и в итоге в релиз попадало больше функциональности, чем от одной большой команды. Ну и понеслось, решили делать не 3 команды, а штук 20.
И именно это с 2017-го мы начали делать.
Сейчас
На сегодня у нас 15 команд (включая и «Альфа-Мобайл», и «Альфа Бизнес-Мобайл»), раздроблено это все весьма сильно, и каждая команда снова делает свой кусок работы. Кто-то делает платежи и переводы, кто-то – узконаправленные фичи, например, под наше сотрудничество с FIFA. При этом, если у ребят из этой команды получается так, что прямо сейчас у них нет задач по FIFA – они начинают делать что-то другое, например, улучшают процесс авторизации и прочее.
В итоге получаем, что у нас 15 команд, они параллельно что-то делают, благодаря чему мы релизимся уже раз в 2 недели, при этом в каждый релиз входит сильно больше фич (около 10) и правок, чем ранее.
На словах такая переделка звучит довольно просто, мол, взяли и раскидали людей по командам, каждая из которых делает что-то свое, но на самом деле это повлекло довольно сложные изменения техпроцесса. Ведь команда изолирована, общается по большей части внутри себя, вокруг этого всего еще и прослойки – iOS, Android, дизайн. Все это необходимо синхронизировать, иначе всё :)
Техпроцесс
Чтобы все это не развалилось на ходу, мы привели техпроцесс вот к такому виду:
- есть разработчик, который вдохновенно пишет свой код;
- есть наш общий код в удаленном репозитории;
- когда разработчик заканчивает, он создает пулл-реквест (не менее вдохновенный) и пишет ребятам, мол, я все, давайте вольем.
При этом у нас есть ряд автоматических проверок, мы проверяем такой код статическим анализатором (swiftlint), он позволяет быстро зафиксировать проблемные моменты, например, где-то скобочки нет, или есть риск утечки памяти. Говоря чуть больше про swiftlint – у нас включены практически все стандартные правила, а также есть несколько своих. Все это позволяет сэкономить время на код ревью.
Continuous Integration сервер (в нашем случае используется Jenkins) прогоняет статический анализатор кода, прогоняет тесты в приложении, помогает собирать и запускать его, а также пишет обо всем этом в Slack. После всего этого уже проводится ручное код-ревью.
Когда код принят, наш любимый jenkins собирает несколько сборок: для установки на тестовые устройства, для автотестов и для возможного релиза. Тестировщик внутри команды проверяет такую сборку, и если все хорошо, то код может быть влит в следующий релиз.
AppStore с недавнего времени позволяет выкатывать новый релиз не на всех людей, как раньше, а на определенный процент пользователей. Поэтому новые фичи мы сначала выкатываем на 1-5 процентов пользователей, смотрим, что там и как в целом. При необходимости исправляем что-то, выкатываем уже на 10 процентов, и так далее. Кроме того, у нас есть собственное решение, которое позволяет раскатывать конкретные фичи на определенные группы пользователей и гибко всем этим управлять. Эти два механизма позволяют нам не бояться проводить как технические, так и продуктовые эксперименты.
Все это внутри обвешано подробной аналитикой, позволяющей вовремя понять, что и где пошло не так, и как это быстро поправить. Можно также определить, что на какой-то раздел приложения заходят только 2 процента пользователей, а остальные 98% – игнорируют его. Обычно это намекает на удобство расположение раздела или на его смысл вообще.
Команды
Сейчас над «Альфа-Мобайлом» трудятся 15 iOS-разработчиков. Над «Альфа Бизнес-Мобайлом» – 3.
Кроме продуктовых команд, ребята активно участвуют в так называемых технических командах, которые появились параллельно с нашим масштабированием. У нас есть команда, которая следит за архитектурой (кстати, эта команда разработала собственное решение, которое мы применяем в Альфа-Мобайле), команда, которая разрабатывает дизайн-систему, и команда, которая улучшает наш CI/CD. На все это ребятам выделяется время в продуктовых командах.
Команда дизайн-системы разрабатывает библиотеку UI-компонентов. Когда разработчик пишет что-то такое, что может пригодиться всем, он заливает это в общую библиотеку. Поэтому, когда у нас появляется какой-то новый проект, то команда может сразу подключиться к этой библиотеке и получить много готового и полезного.
К слову, об идеальной численности команды. Как руководитель я могу сказать, что нас уже слишком много (без паники, мы все равно активно нанимаем мобильных разработчиков). Я просто к тому, что чем больше людей – тем больше времени тратится на синхронизацию, и это нормально. Кстати, по этой причине мы не рассматриваем junior-разработчиков (хотя, признаюсь, бывают исключения).
Нанимаем в основном middle, middle+ разработчиков. Это люди, которые уже достаточно уверенно знают нужные технологии, но при этом их можно заточить под себя и натаскать именно для работы в текущих командах. Мы используем много новых технологий, например, у нас более половины кода на Swift, своя собственная архитектура и есть еще несколько вещей, которые обычно не так активно используют. Конечно, стоящий senior тоже будет оценен по достоинству. А вот лидов мы предпочитаем формировать уже внутри компании.
Прямо сейчас у нас идет активный набор мобильных разработчиков, у нас есть ряд новых команд (есть много продактов с идеями, и им нужны люди в команду), поэтому, если вы чувствуете в себе силы и желание попробовать себя в разработке мобильных приложений для Альфа-Банка, не стесняйтесь – https://hr.alfabank.ru/vacancies/ios-dev
Буду рад ответить на вопросы об особенности разработки мобильных приложений в банке или об общих принципах работы у нас.
