Однажды мы решили переработать уже существующий адаптив интернет-банка для юр. лиц, а точнее превратить его в веб-приложение (Mobile Web) используя технологию PWA (Progressive Web App), с помощью которой сайт трансформируется в веб-приложение визуально и функционально. Далее для удобства буду использовать термин Mobile Web.

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

Подход к управлению проектом

Немного введу вас в контекст, в который я попал, когда ко мне перешел проект. 

Развитием существующей адаптивной версии интернет-банка "Альфа-Бизнес" я не занимался, а проект "Mobile Web" ко мне перешел сразу при трудоустройстве в Альфа Банк. Поэтому до старта работ мне было довольно непросто оценить сложность проекта, учитывая все нюансы организационной структуры и специфики  разработки интернет-банка "Альфа-Бизнес" в целом. В данной статье я не буду описывать каноны по управлению проектом, используя всем известные фреймворки, а поделюсь интересными инсайтами, проблемами и достижениями.

О проекте

Цель проекта: повторить в Mobile Web мобильное приложение интернет-банка по функционалу и клиентскому опыту.

Участники проекта: более 35 продуктовых команд, не считая остальных вовлеченных стейкхолдеров.

Срок реализации: 9 месяцев.

Бюджет: раскрыть не могу.

Старт проекта

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

• S — на проект выделен текущий состав продуктовой команды. Доработки несложные и с объёмом сможет справиться текущий состав продуктовых команд.

• M — среднее количество доработок. Потребуется усилить текущий состав продуктовых команд.

• L — большое количество доработок. Потребуется сформировать новую команду.

Для лучшего понимания, что такое продуктовая команда, приведу классической пример команды, задействованной в интернет-банке "Альфа-Бизнес". 

• Владелец продукта, как руководитель команды.

• Дизайнер.

• Системный аналитик.

• Веб разработчик.

• Мидл-разработчик.

• Тестировщик.

Теперь немного о возникших трудностях, с которыми пришлось столкнуться.

Сложность 1

Чем больше вовлеченных команд, тем сложнее становится управлять сроками, зависимостями, ресурсами, рисками и т.д. Уследить за всем в моменте бывает довольно трудно, а полагаться на зрелость и ответственность команд не всегда выходит, особенно когда команда формировалась с нуля. Какими бы крутыми и самостоятельными специалистами мы не были, но при отсутствии постоянного контроля, о соблюдении плана можно забыть.

Решение: приходилось применять подход микроменеджмента и регулярно следить за ситуацией, как говорится в режиме онлайн. Но в результате это отнимает много сил и времени. Можно аккуратно перекладывать ответственность за сроки и результаты на команду, но, как показывает практика, для максимального достижения результата без дирижёра никуда. 

Сложность 2

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

Как решение: приходится договариваться и искать компромиссы, перераспределять ресурсы между командами и т. д.. И как крайний вариант - эскалировать на вышестоящее руководство.

Сложность 3

Отсутствие ресурсов. Так как на этапе Инициации проекта я еще не работал в Альфа Банке, то в оценке и запросе ресурсов я участия не принимал. Приходилось работать как есть. 

Решение: поиск компромиссов, переприоритизация задач и регулярный пересмотр бэклога. Здесь я старался применять закон Парето.

Сложность 4

Особенность раскатки на пользователей. В Альфа Банке практикуется постепенная раскатка на пользователей (Fast track) для минимизации негативного влияния на пользователей в случае обнаружения дефекта в проме. При этом на первом этапе подход внедрения по готовности тут не работал, так как одномоментно должен был внедриться минимальный стек разработки, несущий в себе обновленную глобальную навигацию и основные разводящие экраны, как первой точки входа во все остальные пользовательские сценарии. Основная сложность состояла в коммуникации между командами для раскатки функционала на одни списки пользователей, учитывая созависимости и время на саму раскатку. 

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

Подход к разработке

Переделывать полностью уже существующую адаптивную версию интернет-банка "Альфа-Бизнес" под Mobile Web довольно долго и дорого, поэтому для быстрой победы мы решили использовать гибрид, состоящий из адаптивной и отдельной мобильной версии.

Для чёткого понимания архитектуры определим два термина:

• Адаптивная версия — приложение, которое, в зависимости от разрешения экрана, отображает UI в определённом виде. Элементы могут вести себя по-разному в зависимости от брейкпоинтов (скрываться/видоизменятся). Тип устройства не учитывается. Один и тот же код отвечает за отображение на десктопе и мобильном устройстве (это то, как были реализованы текущие страницы в интернет-банке "Альфа-Бизнес" на февраль 2023). 

• Отдельная мобильная версия — приложение, в зависимости от типа устройства, отдаёт отдельную версию UI, которая может частично или полностью отличаться от десктопной. Внутри мобильной версии могут реализованы собственные паттерны по реализации функционала приложения. Код мобильной версии разделен с десктопной версией. 

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

Что выбрать: адаптивную или отдельную мобильную версию?

Чтобы определиться, какую версию использовать в продукте, мы отвечали на несколько вопросов:

При этом выбирая реализацию адаптивной или отдельной мобильной версии, я с командами придерживался нескольких принципов:

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

• Консистентность. При подходе к проектированию дизайна, даже если часть функционала остаётся на адаптивной версии, мы использовали мобильные паттерны и компоненты. Проще говоря, любая кнопка, строка, заголовок и т.д. должны проектироваться по единым версиям библиотек компонентов. К тому же, так проще проводить общий рефреш (редизайн) приложения.

• Ресурсоемкость. Мы учитывали время на разработку и бюджет. Не всегда разработка отдельной мобильной версии приведёт к максимальному эффекту, ведь затраты на неё могут быть многократно больше, а частота использования страницы относительно редкой. 

PWA Feature

Использование нативного приложения обеспечивает уникальный опыт не только за счёт визуального языка и стилей, но и за счёт уже ставшей привычной функциональности, паттернов, которые доступны только с мобильного устройства.

Если вы хотите задействовать схожий опыт, используя функции смартфона, максимально приблизив Mobile Web к мобильному приложению, то рекомендую ознакомиться со списком PWA-фичей, который поможет вам в достижении этой цели. Например: Web Share, Notification, File System и другие. Более подробно ознакомиться со списком и документацией можно по ссылке.

Однако сразу хочу подсветить ограничение, с которым мы столкнулись — не все PWA-фичи поддерживаются на iOS, в частности браузером Safari. Для сравнения какие PWA-фичи получится применить можно посмотреть по ссылке. 

Так как санкции не повлияли на android-разработку, и мы спокойно можем заниматься дистрибуцией мобильного приложения, то для нас основные пользователи Mobile Web —  iOS пользователи. При этом хочу поделиться интересной продуктовой аналитикой. Несмотря на то, что приложение на Android свободно для скачивания и регулярно обновляется, у нас распределение пользователей Mobile Web по ОС находится в соотношении: iOS 52% / Android 48%

Архитектура

Первоначальная загрузка мобильной версии

Никакой принципиально новой схемы взаимодействия пользователей с Mobile Web у нас не возникает.

Пользователи web-версии/Mobile Web взаимодействуют с одним и тем же Node.JS приложением, которое взаимодействует, в общем случае, с теми же API. Разница заключается только в том, какой view будет отрендерен на сервере для клиентов, и в том, какие ссылки и на какие статичные файлы получит пользователь. 

Приложение определяет какой view отдать по типу устройства.

Взаимодействие с API

С клиентской стороны мобильная версия может добавлять вызовы новых API, которые не использовались в веб-версии. Новые API добавляются так же, как и раньше, никак специально не обозначаясь как «API для мобильных». Это просто такие же API.

Использование API Мобильного приложения

Использование для мобильной версии API из существующего мобильного приложения "Альфа Бизнес-Мобайл" принимается отдельно, после проведения аналитики. В случае, если API "Альфа Бизнес-Мобайл" возвращает какие-то уникальные данные, недоступные из существующих в Веб-версии API, или данные, которые отфильтрованы уникальным образом, недоступным в Веб-версии API, то в таких случаях мы привлекали лидов/архитекторов направления для принятия решения об использовании. Возможно, в таких случаях правильнее будет вынести уникальные данные на уровень core-api и использовать как обычные API.

Структура файлов в проекте

По сути, наша цель — сделать так, чтобы нам пришлось писать как можно меньше кода, но при этом нам было довольно просто всё это поддерживать.

Пересечение файлов мобильной версии и десктопной внутри проекта сводится к следующим соглашениям:

• Общая серверная часть. Нет смысла заново регистрировать те же самые ручки, можно переиспользовать те, что есть.

• Общие резолверы для подготовки стейта. В метод подготовки стейта также будет добавляться параметр isMobile, исходя из которого приложение может решать вызывать другие API. Но общая сборка стейта должна быть одинаковой для десктопа/мобилы.

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

Все остальные вещи могут различаться. Нежелательно использовать в десктопной версии проекта компоненты из мобильной и наоборот.

Скорость. Метрики и оптимизация

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

Воспринимаемая производительность: скелетоны и асинхронная загрузка данных (Быть быстрым, казаться быстрым). 

Обсуждая с ИТ и Дизайнерами варианты более быстрой скорости работы Mobile Web, мы понимали, что ощущения быстрого сервиса можно достигнуть не только работой над технологиями, но и грамотными интерфейсами. Первоначальный этап по созданию скоростного интерфейса — добавление скелетонов и отложенной загрузки данных.

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

Основное требование: компонент skeleton должен быть максимально похож по структуре с подгружаемым результатом. Если интерфейс ожидает получение списка из нескольких элементов высотой N, то скелетон также должен иметь несколько элементов высотой N.

Воспринимаемую производительность обсудили. Идём дальше.

Реальная производительность: метрики Web Vitals.

Метрики Web Vitals — это инициатива Google, цель которой, предоставить единое руководство по сигналам качества, необходимым для обеспечения хорошего взаимодействия с пользователем в Интернете.

Инструмент выбрали, а что дальше? Теперь, чтобы отслеживать реальную производительность, определили для себя ключевые метрики:

CLS — Cumulative Layout Shift

Метрика CLS (Совокупное смещение макета) измеряет степень стабильности контента на вашем сайте (насколько контент «прыгает»). Если при загрузке контент отодвигается подгрузкой рекламных блоков или другим контентом, то этот параметр оценит, насколько это критично для посетителей.

LCP — Largest Contentful Paint

Метрика LCP (Скорость загрузки основного контента) сообщает время рендеринга самого большого изображения или текстового блока, видимого в области просмотра, отсчитанное от момента начала загрузки страницы.

FID — First Input Delay

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

Для каждого из вышеуказанных показателей, чтобы гарантировать достижение рекомендуемой цели для большинства ваших пользователей, хорошим порогом измерения является 75-й процентиль загрузки страниц, сегментированный по мобильным и настольным устройствам. Более подробнее можно почитать по ссылке.

Метрики определили. Теперь осталось их подключить и следить за показателями. Модулей (страниц), для которых настраивали метрики, было довольно много — более 70, и процесс подключения к метрикам не был быстрым, как хотелось бы. Связано это с огромным числом ответственных, так как в среднем за командой закреплено не более нескольких модулей. Поэтому для быстрой победы рекомендую определить наиболее посещаемые страницы и сконцентрировать внимание на них. 

Теперь у нас есть показатели метрик. Видим какие модули входят в бенчмарк Web Vitals, а какие отстают. Здесь мы придерживались следующих правил для ускорения:

• Оптимизация изображения на проекте (jpg/png/svg).

• Использование code-splitting.

• Использование bundle-analyze для анализа бандла, где рассматривали возможность обновления/оптимизации библиотек в бандле.

• Избегание лишних reflow и rerender.

• Использование инструмента lighthouse: дополнительные рекомендаций относящихся к конкретно вашему модулю поможет получить расширение Google Chrome Lighthouse.

А как вы думаете, что ещё может способствовать ускорению?

UI/UX

Разработка и релизы

Адаптивная версия или отдельно стоящая мобильная версия (Mobile Web) выходит в прод одновременно с десктопной. Критически важно, чтобы пользовательский сценарий сразу проектировался как под десктопную версию, так и под Mobile Web. 

Размеры.

• Диапазон ширины для MobileWeb: от 320 до 768 dp.

• Диапозон ширины контентной области: от 320 до 600 dp. Далее появляются ушки.

Перенос функционала

Mobile Web должен максимально дублировать функционал десктопной версии. Любое «отрезание» функционала должно иметь под собой аргументацию. Чаще всего мы учитывали обратную связь клиентов или отталкивались от привычных паттернов поведения пользователей в мобильном приложении.

Кросс-навигация

Пользователь будет работать как со страницами отдельно стоящей мобильной версии (Mobile Web), так и с мобильным адаптивом, поэтому особенно важно обращать внимание на навигацию и наличие уже реализованного функционала.

Требования к UI/UX

Здесь все просто. Look'n'feel Mobile Web должен быть максимально близок к мобильному приложению. Это потребовало разработки специальных версий компонентов со стороны команды дизайн-системы. Компоненты наследовали внешний вид, поведение и функционал своих аналогов из нативного iOS-приложения.

Навигация

Мы применили отображение компонента TapBar на пяти главных экранах: Главная, Платежи, Сервисы, Связь, Профиль. Эти экраны уже реализованы, как отдельностоящая мобильная версия (Mobile Web). И если считать основные разводящие экраны как первый уровень вложенности, то все адаптивные сценарии начинают проектироваться со второго уровня вложенности. На всех подобных экранах используется компонент NavBar в разных его состояниях, в зависимости от функциональности продукта.

Система отступов

Для большей консистентности при работе со смартфона мы переиспользовали отступы из нативного приложения для iOS.

• Отступы от краёв экрана до графики: 20 dp.

• Отступы от краёв экрана до текстовых блоков: 24 dp.

• В модальных сущностях отступы от краёв экрана до любых объектов равняются 16 dp.

Поведение шторок

• Полноэкранные шторки в качестве контрола используют крестик без свайпа.

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

Пример результата проекта

Перспективы Mobile Web. Почему стоит в него вложиться, куда дальше и какой спрос

Экономия

Не нужно держать дополнительную команду iOS-разработчиков, так как при разработке фронта используем JavaScript. При этом формируя больший штат фронт-разработчиков, мы можем передвигать их между проектами там, где в моменте требуется усиление. А также возможность экономить на комиссиях до 30% с каждой покупки в Apple Store, Google Play и других сторах.

Свобода от сторов

Разрабатывая Mobile Web, мы предоставляем пользователю возможность получать новые фичи сразу, без потребности для клиента в регулярном обновлении приложения. Для разработки это экономия времени на проверки от сторов до пары недель, и отсутствие риска, что приложение могут удалить или ввести ограничения на обновления в связи с санкциями.

Разработка капсульного мобильного приложения

Идея проста и уже не нова. По сути это экраны (web view) Mobile WEB в оболочке нативного приложения iOS. Если ваше приложение удаляют из Apple Store или Google Play или ограничивают обновления, то пользователь по прежнему продолжает получать обновления, как в web-версии. Можно при минимальных затратах вывести в мобильное приложение сценарии из web-версии интернет-банка.

Но здесь важно отметить, что приложение, состоящее исключительно из web view, Apple или Google не пропустит. Должно быть соблюдено условие по наличию минимальной функциональности для приложений и по наличию пользовательского интерфейса. Детально про плюсы или минусы данного подхода рассказывать не буду так как прежде всего мы говорим о способах применения Mobile Web. 

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