Как стать автором
Обновить

Новая архитектура на старом фундаменте, или Как за полтора года обновить мобильный банк

Блог компании ВТБ Разработка под iOS *Разработка мобильных приложений *Разработка под Android *Управление проектами *
Привет, Хабр! Я Павел Наумов, лидер стрима «Мобильный банк» в ВТБ. Полтора года назад мы собрали команду, чтобы доработать банковские приложения ВТБ Онлайн для iOS и Android. Первоначально речь шла об их «перекраске», но в итоге пришлось переписать половину унаследованного кода и перейти на новую микросервисную архитектуру. Попутно мы сократили сроки релизов с 1,5 месяцев до 2 недель. С чем нам пришлось столкнуться, как мы решали проблемы и какие уроки из этого вынесли, мы с ребятами из команды рассказываем ниже.

Первые шаги: перерисовка главного экрана

Изначально задача не выглядела такой уж сложной: приложение морально устарело, нужно было визуально освежить ВТБ Онлайн и решить основные проблемы без серьёзных доработок на бэке. Но мы столкнулись с тем, что старый бэкенд не позволял гибко менять логику работы приложения и UI — всё упиралось в необходимость доработок бэка, на которые у нас не было ресурсов. Приходилось искать компромиссы. Кроме того, не было документации по многим сценариям, нужно было искать в приложении, как они выглядят и какая у них логика.
Как платформенная команда мы начали с разработки общей концепции и принципов нового дизайна. Мы понимали, что это будет масштабироваться на все продуктовые команды банка (которых уже больше 50), поэтому сразу упаковывали всё в дизайн-систему. После этого мы взялись за главный экран приложения и навигацию. Затем начали привлекать продуктовые команды. На примере главного экрана мы показали, как применять концепцию и принципы дизайна, чтобы команды могли сделать редизайн своих продуктов.
Обновление дизайна — это когда лучше один раз увидеть
С самых первых шагов мы начали подключать к задаче разработчиков. Это позволило нам обезопасить себя от ситуации, когда дизайн готов, а реализовать его некому и нечем.
Всего мы обновили более 1000 экранов старого приложения.

Дизайн-ревью

Иван Шапотатев
дизайнер
В банке больше 50 продуктовых команд, и их число постоянно растёт. Каждая команда делает свой раздел, например переводы, платежи, кредиты. У всех свои задачи, цели, взгляды и дизайнеры. Но в какой-то момент они должны сойтись в одной точке — приложении ВТБ Онлайн. Цель нашей команды в том, чтобы приложение не развалилось и выглядело консистентно. Для этого мы используем дизайн-систему и дизайн-ревью.
Новому приложению — новые экраны
Любая фича, прежде чем попасть в прод, проходит дизайн-ревью. На ревью мы смотрим, использует ли команда компоненты дизайн-системы, проверили ли функциональность на юзабилити-тестировании, как функциональность встраивается в приложение, не нарушена ли логика, все ли крайние состояния учтены и т. д.
Мы не хотим, чтобы дизайн-ревью было шлагбаумом, который мы выставляем в последний момент, и стараемся общаться с командами на самом раннем этапе. Обсуждаем вместе задачу команды и помогаем ребятам найти лучшее решение в рамках дизайн-системы.

Дизайн-система

Максим Галеев
дизайнер
Дизайн-система, которую мы разработали в сжатые сроки, позволяет командам быстро решать свои задачи. В ней зафиксированы основные компоненты дизайна: типографика, цвета, сетка, поля ввода, кнопки, ячейки и другие элементы, и, главное, всё это реализовано в коде.
Есть общий файлик в Figma для дизайнеров и разработчиков, там находятся все утверждённые компоненты, которые разбиты по группам: поля ввода, ячейки, кнопки, текстовые блоки и т. д. Каждый компонент — самодостаточная часть интерфейса.
Чем меньше компонентов, тем лучше. Компонент — это разметка/контейнер, который может иметь много разных представлений или состояний. Например, есть 4 базовые ячейки, из которых можно собрать почти 100 разных вариаций. Следить за несколькими ячейками проще, кроме того, это помогает лучше сочетать и очень быстро добавлять новые состояния. Вариации каждого компонента также представлены в Figma.
Сложный путь компонентов в дизайне и коде
При этом очень важен баланс между сложностью и количеством, чтобы, с одной стороны, компонентов не было слишком много, а с другой — чтобы не создавать компоненты-монстры, которые потом будет сложно поддерживать.
Когда дизайнер берётся за изменение своего сценария, он заходит в дизайн-систему и смотрит, с помощью каких компонентов может решить свою задачу. Если всё необходимое есть, он может быстро собрать интерфейс и перейти к юзабилити-тестированию. Если оказывается, что с помощью готовых компонентов задачу решить нельзя, мы собираемся с командой, обсуждаем и добавляем новый компонент или дорабатываем один из существующих.
Важная задача — обеспечить синхронизацию дизайна и кода. Тут нам помогает правильный синтаксис компонентов + мы используем комментарии к компонентам в Figma и статусы готовности в названии. Figma API и автоматическая синхронизация тоже в процессе, но после постройки фундамента.
Мы начинали с MVP, собрав самые простые/базовые компоненты, которые нужны всем командам, а потом стали добавлять всё больше и больше новых компонентов и состояний. Затем появились шаблоны, гайды и разные правила.
Мы крупные, а эффективно развивать наши сервисы без набора инструментов под названием «дизайн-система» невозможно. Но никогда не надо строить систему ради системы — это просто инструмент, чтобы делать наши сервисы лучше и эффективнее.

Переход на разработку in-house

Павел Дащак
лидер платформенной команды iOS
Помимо создания дизайна, перед нами стояла задача перейти с аутсорса на in-house-разработку. До перехода разработка приложения велась разными подрядчиками, переходя из одних рук в другие. В итоге получилась цепочка из 4 подрядчиков. На подрядчика были завязаны практически все процессы по запуску мобильного приложения. У него были собственные пайплайны и процессы тестирования, сопровождение тоже лежало на нём. Он же запускал приложение в маркет. Все эти процессы нам нужно было в короткий срок перенести в контур банка и сформировать костяк разработки внутри ВТБ.
Антон Шаляев
лидер платформенной команды Android
Репозитории раньше принадлежали подрядчику, и код приложения хранился у него. Но нельзя просто взять и перенести код приложения в контур банка. Нам пришлось полностью перестроить весь процесс по поддержке, мониторингу и сопровождению приложения и выстроить его внутри, а также создать DevOps-пайплайны для упрощения процесса разработки и публикации (CI/CD).
Сборка теперь выполняется автоматически и распространяется по продуктовым командам, тестировщикам, чтобы каждый видел исправления, тестировал, проверял. Это отняло много сил, но мы это сделали в короткие сроки. Теперь все, кто принимает участие в разработке мобильного приложения, используют наши процессы для тестирования, получения сборок, исправления и пр.
Все компоненты собраны — можно строить UI
Мы стали отвечать за мобильное приложение полностью — и за разработку, и за релизы, и за сопутствующие им процессы.

Команда

Раньше в банке не было отработанного процесса найма разработчиков. И выстраивание in-house-команды началось с нас. Собственно, мы этим и занимались: полностью проводили интервью, готовили требования, которым должны соответствовать приходящие к нам люди. В итоге удалось увеличить команду разработки, которая развивает проект ВТБ Онлайн, с 40 человек до 150. Это только разработчики платформ Android и iOS. Из них 20 человек в платформенной команде, остальные ребята стали частью продуктовых команд. Совокупно в стримах сосредоточено около 100 команд общей численностью 1 000 человек.
Сами мы как-то поскромничали. По численности у нас достаточно небольшой стрим — около 50 человек, но в следующем году планируем расшириться до 60. Костяк команды, 6 человек, пришёл вместе со мной из другого крупного банка. Там мы тоже занимались большими вещами — первыми в России запустили ApplePay и сократили релизный процесс с полугода до 2 недель.
В нашем стриме 5 направлений разработки — это платформы iOS и Android. Отдельная команда занимается ускорением приложений на обеих платформах. Команда Force, отвечающая за скорость и качество релизов, добавилась в конце года. В отличие от других команд, у нас в принципе нет разработчиков бэкенда — фокус полностью на мобильной разработке. Помимо разработки, есть релизная команда плюс команда дизайна: 3 дизайнера и иллюстратор, — и команда аналитики: 2 аналитика и 2 архитектора.

Agile

В разработке мы придерживаемся Scrum. Этот подход нам уже был знаком, поэтому для нас не составило труда сразу включиться в процесс.
Каждое направление ежедневно проводит стендапы: команда рассказывает, в чём им нужна помощь, что они сделали за предыдущий день. Два раза в неделю я провожу часовые встречи с лидерами команд. Это позволяет всему большому стриму понимать, куда мы идём, и избегать расфокуса, когда одна команда делает одно, другая — другое, третья — третье.
Демо. Мы работаем спринтами по 2 недели. В конце каждой итерации проводим одно большое демо нашего стрима — что сделали. Мы были первой командой в банке, которая стала проводить такие демо. Сейчас эта история стала общей: каждые 2 недели за один день проходят демо всех продуктовых команд.
Ретро. В конце спринта также проводим встречи на час-полтора, где обсуждаем проблемы, с которыми столкнулись во время итерации: не успели сделать какую-то задачу, слишком много времени потратили на ненужные вещи и т. п. По итогам обсуждения составляем список того, что сделать, чтобы в дальнейшем минимизировать риск подобной проблемы.
При этом мы применяем Scrum не ради Scrum. В случае необходимости меняем подход — сейчас такая необходимость есть: для глобального обновления Scrum не вполне подходит. Часто прилетает куча ошибок, дефектов, которые необходимо исправлять, и здесь мы скорее ближе к Kanban. Да и не для всех есть смысл работать по Agile, например DevOps-инженер работает только по канбану.
После выпуска релиза разработка вернётся к Scrum.

DOR

Елена Леотова
лидер релизной команды
Процесс вывода продукта в продакшн раньше занимал полтора месяца. За это время на рынке много что меняется, и мы всегда были отстающими. Проблема была в том, что одни подрядчики разрабатывали приложение, другие — тестировали. Из-за дискоммуникаций и отсутствия мотивации на выходе получали много ошибок. Сейчас за вывод новых версий приложений отвечает релизная команда из 2 релизных менеджеров (по iOS и Android) и 7 тестировщиков.
И вот так день за днём
В процессе выпуска приложений участвует множество смежников. Чтобы выводить продукт в прод быстро, качественно и с минимальными затратами, мы придумали свод правил, который у нас называется «Определение готовности» (Definition of Readiness, DoR). Это такой чек-лист для продуктовых команд: что нужно сделать, чтобы запустить свою фичу, к кому из участников и в какой последовательности надо обратиться и т. д. DOR помогает соблюсти баланс между качеством и скоростью.
За полтора месяца набиралось очень большое количество исправлений и фичей — всё это вместе было очень тяжело регрессить. Изменения в одном месте затрагивали ещё кучу других. Команды торопились попасть в релиз, чтобы успеть с новой фичей. Это повышало шанс что-то сломать в другом месте. Мы смогли сократить срок релиза с полутора месяцев до 2 недель. И доводим поставки до клиента с неплохим качеством. Основное количество жалоб, которые сейчас оставляют в комментариях, связано со старым бэкендом.

Смена бэкенда

Дмитрий Нелепов
главный архитектор мобильного приложения
Многие решения, которые мы хотели сделать, упирались в старый бэкенд. Вся логика была на стороне бэкенда, что приводило к долгому заполнению даже самых простых, не интеграционных полей операции. Мобильное приложение выступало аналогом браузера или тонкого клиента — отображало то, что отдавал бэкенд. Интерфейсы имели плоскую структуру, что усложняло их кастомизацию. Для того чтобы поменять кнопки, перекрасить что-то, изменить расположение, требовалось дорабатывать бэкенд-систему. А это долго и не всегда возможно — приходилось идти на компромиссы.
Из таких «кирпичиков» построена работа над мобильной платформой
Ближе ко второй половине нашего пути ребята, которые занимаются разработкой бэкенда, предложили поменять его архитектуру: отказаться от монолита и перейти на микросервисы. В новой парадигме мы хотим перейти на RESTful-архитектуру. Бэкенд так и будет присылать объекты, которые необходимо заполнить, но логика заполнения будет переложена на приложение. Это позволяет делать кастомизированные экраны, которые так хочет наш UX/UI- отдел.
Первоначальная задача расширилась — это не только «перекраска» визуала, но и смена архитектуры бэкенда. Бэкенд не разрабатывается только под мобильное приложение или только под сайт. Мы идём в сторону омниканальности и унификации. Если мы делаем, например, вход, то методы и API разрабатываются сразу для мобильной платформы и для веба.

Что мы получили

Месяц назад мы выпустили стабильную версию старого мобильного приложения для AppStore и PlayMarket и взяли небольшой тайм-аут с выпуском регулярных релизов. Все команды полностью сосредоточились на разработке нового приложения на новом бэкенде.
В итоге мы полностью ушли от старого дизайна и сделали приложение в минималистичном стиле. Хотели соблюсти баланс: сделать приложение новым и современным, но оставить простым и понятным. На главной странице только счета и баланс, нет рекламы, баннеров, навязываемых услуг. Приложение, где ты хранишь деньги, должно быть сейфом без лишней информации.
Сократилось время отклика интерфейсов — войти в приложение теперь можно за пару секунд, а не за полминуты. За счёт чего это удалось? Мы переписали и оптимизировали 50 % кода приложения, перешли на новый бэкенд, на микросервисы. Сделали кэширование разделов, что позволяет отображать информацию пользователя моментально.
Кроме того, мы добавили много разных новых фишек и функций для удобства пользователей — например, плавающее контекстное меню Air Bar, кастомизируемый интерфейс главного экрана, возможность снятия наличных в банкомате без карты. Другой пример: часто клиенты совершают операции в транспорте, на фуд-корте, в других многолюдных местах. Не каждому хочется светить баланс своего счёта. Теперь на главном экране можно спрятать сумму от посторонних глаз — она будет скрыта звёздочками.
Такое масштабное обновление мобильного приложения не могло бы произойти без помощи продуктовых команд, которые занимались разработкой своих сервисов для ВТБ Онлайн. Наша задача как платформенной команды заключалась в том, чтобы собрать из всех этих продуктов целостное и качественное приложение.
Нам очень важно получить фидбэк о проделанной работе и узнать ваше мнение о новом приложении — приглашаем всех заинтересовавшихся в комментарии.
Теги:
Хабы:
Всего голосов 28: ↑22 и ↓6 +16
Просмотры 28K
Комментарии 87
Комментарии Комментарии 87