№1. Как в кризисных условиях делаем цифровые сервисы, доступные всем
На первых iPhone все цифровые сервисы заканчивались сайтами в сети. Потом выросли мобильные приложения — «вторые сайты», как тогда говорили. Так начал свой доклад Алексей Курзяков — директор по развитию мобильных цифровых продуктов, в Альфа-Банке отвечает за развитие розничного мобильного банка (Альфа Мобайл). С 2013 года работает над развитием мобильных приложений и цифровых сервисов, преимущественно для финтеха.
Цифровые сервисы в России
А что сейчас с цифровыми сервисами? Они делятся на 3 типа.
Суперприложения, в которых компании стараются агрегировать, всё, что у них есть, не дробя по разным сервисам и приложениям — это касается и внутренних приложений и веб-сервисов. Вы их все знаете — это ВК, Яндекс и Тиньков. Всё.
Экосистемы. Например, Сбер, Озон или МТС. Обычно строятся вокруг банков, как ни странно. Банки даже покупают для экосистем, например, Озон купил банк, а про банки МТС и, тем более, Сбера, можно и не говорить.
Монопродукт — тот, путь, который мы развиваем в Альфе. Мы разрабатываем финансовые продукты и выставляем их в нашем мобильном банке.
Главная уязвимость всех вариантов — всё строится вокруг приложений, а они размещаются на площадках, которыми владеют всего две компании (вы их знаете), которые могут их удалить, например.
Что делать, если уже удалили? Разместиться везде, где только можно (в том числе и у себя на сайте).
А что с обновлениями?
Больше 90 digital-команд профессионалов каждые две недели делают новый релиз, доносят новую функциональность до пользователей. Раньше 80% клиентов на Android обновлялись за 2 недели, а теперь нет.
«Не думали, что проблема может возникнуть. Подозревали, конечно, но не в такой реализации»
Решили проблему over-the-air обновлением — непосредственно в мобильном банке появляется раздражающий баннер, и приложение скачивается с защищённого хранилища. Файл достаточно большой — дистрибутив весит порядка 150 МБ. Мы используем CDN, чтобы из любой точки мира можно было его скачивать.
А что с iOS?
Мы продолжаем работать над двумя продуктами одновременно, но наш интернет-банкинг — огонь, поэтому на iOS можно воспользоваться интернет-банком. Также можно обратиться в отделение банка, чтобы скачать приложение.
Результат?
Мы вернулись на тот уровень, что был до удаления приложений из сторов. А проникновение в активную клиентскую базу порядка 85% — это отношение тех, кто раз в месяц заходил в мобильный банк ко всем активным клиентам банка. Это один из самых высоких показателей в мире.
Цифровая платёжная инфраструктура
Платёжная инфраструктура тоже достаточно сильно пострадала в прошлом году. Но выстояла, потому что в 2015 году запустили НСПК — Национальную Платёжную Систему Карт, оператор карты МИР. Это событие можно назвать историческим, потому что все операции по любым платёжным системам с 2015 года должны проходить через НСПК. А когда в 2022 году Visa и Mastercard дружно объявили, что уходят с российского рынка, то, по идее, у нас все карты превратились бы в мертвый пластик, потому что платежные системы отказывались карты процессировать. Но НСПК подхватила этот процесс и карты работают стабильно.
В 2019 году запустилась система платежей c2b — так называемые платежи по QR-коду. Это некая замена эквайринга с меньшими комиссиями для банков и для торговых сервисных предприятий, и некая альтернатива платежным системам. Почему вообще в России стали популярны кошельки?
В России на запуске 50% терминалов принимали бесконтактные платежи, крупнейшие банки гарантировали 80% через 2 года.
В 2022 больше 90% терминалов поддерживают бесконтакт.
Просто удобно.
Что будет дальше?
Мы запускаем Alfa Pay и сейчас тестируем его на Андроиде.
Есть технология, которая позволяет с помощью NFC чипа эмулировать банковскую карту. Любой любой банк может сделать свой собственный кошелек.
QR-платежи будут становиться популярнее. Однако, банкам достаточно сложно оплатить кэшбэк по QR платежам, ввиду микропроцентов. Но…
«Думаю, банки будут развивать сеть партнерств напрямую с сетями в плане кэшбека»
На что сделать упор в будущее?
На BigTech.
Именно так мы развиваем Альфа-Банк — это большая IT-компания, у нас огромное количество IT-сотрудников, которые постоянно работают над новым функционалом, и нет ни одного процесса, что происходил бы без IT. Поэтому, раз пишется много кода, он должен быть качественным. И на уровне Альфа Digital, нашего подразделения, мы всем командам добавили показатель клиентской доступности и строго следим за исправлением дефектов.
Также 20% времени команды отводится на чисто технические задачи. Бизнес не может претендовать на эти 20%, во время которых проводится рефакторинг, или решаются какие-то сложные задачи, пишутся новые фреймворки. Плюс каждая команда вовлечена в отказ от легаси-технологий.
Выводы
«С финансовыми технологиями в России будет всё хорошо, потому что такие кризисные ситуации сильно подстегивают команды их решать. Например, когда нас удалили из AppStore, то мы всей командой сплотились и начали искать выход из этой комнаты»
А дальше был блок вопросов: про Дзынь (Банкинг в мессенджерах), Альфа.Такси, экономию на пушах, клубок безопасников, фэйковые приложения, самодиагностику приложения и куда дует ветер — не переключайтесь.
Отсылка на 26:50.
№2. От мидла до тимлида: трансформация через навыки и опыт
Это история про двух коллег:
Один — тимлид с опытом 3-4 лет в разработке и годом лидерства. Он побывал как как в маленьких стартапах, так и в больших крупных компаниях, трогая самый кровавый энтерпрайс.
Второй — разработчик. У него 2-3 года разработки, которые он мог провести как и в одной компании, так и в нескольких маленьких. Но амбиции уже говорят ему что нужно расти.
На их примере, Ян Чикнизов поделился советами, как из одной роли перейти в другую. Ян Чикнизов — Java TechLead, больше 4 лет работает в Альфа-Банке и повидал разных тимлидов и техлидов. А повидал он потому, что и сам был тимлидом.
«Я бы хотел с вами поделиться опытом и навыками, которые помогли мне трансформироваться в хорошего тимлида, по отзывам коллег, конечно же»
Но это не точно.
Дисклеймер. Образы собирательные, а если у вас не так — напишите в комментариях.
Тимлид и разработчик получают задачу
Итак, представим, что вчера к героям истории пришел бизнес, в лице любимого босса.
Разработчик видит всю эту ситуацию и говорит, что готов написать код. Даже без требований. И даже очень надеется на то, что всё не сломается, но и в этом случае готов взять и оперативно все починить.
На сцену выходит тимлид. И первый его вопрос — «А оно нам надо?»
Если надо, то тимлид распределит задачу между разработчиками. Он имеет колоссальный опыт, поэтому не просто распределит, а расскажет и покажет «Как делать».
И вот фича в проде, тимлид получает премию, а разработчик «Большое спасибо»
Какие навыки помогут разработчику подсидеть стать тимлидом?
Конечно же, опыт разработки схожих систем.
Опыт работы в сжатые сроки.
Умение общаться с бизнесом.
Главное, тимлид постоянно распределяет задачи в команде. И вот первый совет — начните с распределения своих задач и потихоньку растите в этом поле.
Тимлид и разработчик устраняют аварию
И вот наш разработчик уже научился быстро кодить и разрабатывать фичи «вчера». Но тут неожиданное: закончился отпуск, завтра на работу, он спит после перелета. И тут звонок! Берёт трубку и слышит два главных слова.
Но ещё до этого звонка первым в игру вступил лид, потому что только его телефон есть у технической поддержки. Он пытается оценить ситуацию и эффект, и готовит план решения проблемы — может просто откатить изменения, а может поднять базу данных.
Когда план есть, лид назначает ответственных и будет внимательно следить за ними и контролировать процесс.
Разработчик же подключается, в основном, уже постфактум. Он, конечно, захочет починить проблему, посмотрит мониторинги и логирование, но после лида. Ещё одно отличие лида от разработчика в том, что первый будет работать над тем, чтобы аварии не повторялись. Получается, чтобы стать лидом, надо проявлять инициативу.
Тимлид, разработчик и легаси
Внезапно, разработчик узнаёт о том, что кто-то из коллег начал увольняться. Да и сам уже не видит перспективы развития в данной компании, потому что весь его текущий проект построен на легаси.
Но сам разработчик может подсветить это самое легаси и проработать стратегию по выпилу этого самого легаси — легасиаут. А что тимлид? Он уже готовится управлять командой, состоящей из него и принтера без чернил. Тимлид призадумался и понял, что нужно вводить систему 80/20.
80% времени — продуктовые задачи;
20% времени — задачи, к которым продакта не подпускают, в них и можно встроить легасиаут.
Главное, что тимлид может организовать постоянный процесс избавления от легаси, а не разовое мероприятие.
Разработчик передумал писать заявление, помог выпилить всё легаси и даже взял на себя небольшую инициативу и ответственность за Legacy Management.
Тимлид, разработчик и онбординг
Тут все свободные разработчики в индустрии прознали как в компании хорошо, и решили откликнуться на абсолютно все вакансии. Что же тут будет делать наш разработчик?
Он знает, что надо проявлять инициативу и вызывается стать наставником: обновит документацию и проведёт процесс онбординга.
А лид? А он всё будет систематизировать. Ведь так тимлид и и стал тимлидом?
Он работал в большой компании и «прикасался» к потоку новых сотрудников, например, менторил.
Видел недостатки системы и пытался её улучшить.
Активно участвовал в жизни компании.
Тимлид, разработчик и цели на квартал
Разработчик, который хочет стать тимлидом, не ждёт, когда ему принесут цель на квартал…
…а сам себе их поставит (притом, полезные бизнесу и команде). А тимлид будет контролировать их выполнение и между делом мешать проводить менеджерские активности, вроде 1на1.
Выполнит ли разработчик цели? Конечно! Новых велосипедов не появится — за этим следит тимлид, у которого своих достаточно.
В этой истории хороший конец — разработчик получил большой опыт в своей области, прокачал софт скилы, и научился выполнять поставленные перед ним цели. Теперь он стал тимлидом и обратно дороги нет.
Весь доклад смотрите в записи.
И не забывайте про блок с вопросами — там тоже интересно.
№3. Как тяжелый монолит упаковать в удобный интерфейс
Собрались как-то HR, разработчики, продакт, IT-лид и UX-дизайнер, взяли за основу продуктовый подход и начали реформировать HR-процессы. Звучит как фантазия, но это реальность. О том, что получилось из этой «реальности», рассказал Михаил Михеев, Integration TechLead в своём докладе.
Большой банк. Много систем. Много процессов
Раньше, чтобы написать заявку на отгул, сотруднику нужно зайти в один сервис, для посещения конференции — на второй, а чтобы поехать на эту конференцию — на третий сервис. Такая ситуация стресс для опытных сотрудников, а для новичков — тем более.
Когда в Альфе начали разбираться с этой проблемой, то провели целое исследование, и выяснили, что для поиска информации, документов, заполнения документов, заявок, выплат, отпусков, доступов у нас было 23 приложения и 109 процессов/продуктов в HR. Об этой проблеме, и как её решили, мы писали в статье Как мы создали Digital Workplace для сотрудников. Вот скрин реестра (из статьи), куда заносили проблемы сотрудников, расписывали сценарии, масштаб, обозначали сроки исправления. Там были сотни строк.
Во время исследования столкнулись с тем, что:
Много разных бэкендов: SAP HCM, Lotus Notes, SAP АХД, E-Staff, WebSoft HCM, SharePoint.
У каждого бэкенда своя команда: аналитики, разработчики, фронт и интерфейс, сопровождение и заказчики.
Запутанные цепочки связей — каждая команда генерит свои отдельные интеграции с другими бэкендами.
А с точки зрения архитектуры это выглядело так.
Что? Куда? Зачем всё это?
Собрались, посмотрели, поплакали, написали план
«У нас были сотрудники, небольшой бюджет и клиентское приложение, где можно получить все банковские услуги. Почему бы не сделать то же самое для себя?» Почему бы не внедрить продуктовый подход в HR-разработке?
Для начала описали опыт сотрудника с помощью CJM.
В командах появились разные роли, вроде продакта, IT-лида и UX-дизайнера.
Дальше перешли на новую архитектуру — микросервисную. Основа стека — JS, фронт на React, мидл-часть на NodeJS.
Вывели множество сервисов в единый кластер, обеспечив функции множества систем в одном продукте.
Выбрали технологии, которые позволили экономить бюджет и ресурс для новых разработок — WebView.
Выделили в архитектуре слой, где собираем и создаём все фронты и API и держим курс на переиспользование готовых UI и микрофронтендов.
А Kubernetes-кластер позволяет нам строить любой сервис и прикрутить к нему свой бэкенд.
В него можно встроить любой бэкенд.
Внутри сервисного кластера работают микросервисы, выдающие тематический фронт и реализующие API.
Активно используем технологию Module Federation, когда на одном экране создается несколько веб-приложений и виджетов.
Сервисы консолидируют возможности бизнес-систем, предоставляя в итоге единый UI.
Перескочим в конец — в итоге у нас получился Alfa People. Это ключевой продукт — единый канал взаимодействия сотрудника, который объединил себе множество сервисов: HR, инфраструктурные, IT.
Приложение существует как виде классического мобильного приложения под iOS и Android, так и в виде корпоративного портала. Но работу над ним начали с сервиса Мои заявки.
SAP HCM
«Мы решили, что согласование всех заявок в банке должно проходить в одном месте. Так появился сервис-пилот — Мои заявки, мы его называем Inbox. На нём мы начинали»
Так он выглядит.
Это фронтенд-приложение: обертку делает одна команда, а всё, что открывается внутри inbox, может делать, в качестве микрофронтов, любая команда в банке.
Начали с того, что:
перерисовали фронт нескольких заявок на React;
оставили все данные и потоки по заявкам на текущей бэкенд-системе, на SAP;
и настроили информирование с фронта нашей мастер-системы об изменениях статуса заявки для её движения в дальнейшем по потоку.
На следующем этапе перенесли Inbox в целевую архитектуру, выделили мидл слой и разместили приложение под управлением K8S-кластера.
Дальше научились встраивать заявки из других систем к нам в K8S-кластер. Схема приросла новыми компонентами.
Осталось сделать заявки одинаковыми. Переделывать все заявки на React — нереально, хотя бы потому что у заявок много полей и их поля связаны какой-то логикой, автозаполнением. И вообще эти заявок очень много и потом поддерживать это всё…
На помощь пришёл Server Driven UI. Теперь все заявки состоят из одних и тех же стандартных частей.
В качестве формата хранения информации о структуре мы выбрали формат JSON, который хранит в себе описание компонентов заявки, как они связаны между собой, свойства и т.д.
Архитектурно решение выглядит так.
При выборе заявки мы определяем, есть ли у неё уже готовый фронт на какой-нибудь системе.
Если есть — тянем вместе с данными и отображаем пользователю (верхняя часть картинки).
Если готового фронта на системе нет, то берём JSON-шаблон этой заявки у себя в базе, параллельно обращаемся в мастер-систему за данными по этой заявке.
Внутри нашего приложения соединяем шаблон с данными и отображаем пользователю.
Так мы можем встроить в наш Inbox любую заявку из любой системы банка, предварительно лишь согласовав с ребятами тот шаблон в том виде, в котором он нам нужен.
Что же в итоге?
«Благодаря новым подходам в архитектуре разработки, получилось вынести на первый план понятие сервиса. Теперь сотруднику не нужно знать что отпуск — это HR, командировка это HD, а заявка на установку программы это IT-портал»
А выводы для себя такие:
Не нужно бояться изменений. Иногда они полезны.
Фокусироваться на потребностях сотрудника.
Нужно разумно сокращать полномочия монолитных системы.
Теперь будем выбирать максимально открытый и перспективный стек технологий — опыт есть.
№4. Политика в мире IT: дипломатические решения в cross-разработке
Это заключительный доклад на митапе в Екатеринбурге, в котором Михаил Марков решил рассказать о том, что происходит в тени, во время разработки продуктов, о которых рассказывали выше. Михаил Марков — Product Owner, хотя раньше был разработчиком Oracle и СТО (в IT уже 18 лет). Как так получилось, Михаил?
На примере кросспродукта, где затрагиваются интересы разных команд и стейкхолдеров, Михаил рассказал, как же договариваться.
Когда продукт не только твой
Михаил работает в команде ФизЮриков — это человек с двумя ролями: днём он руководит бизнесом, а вечером — он отец и муж, который ходит по магазинам и занимается бытом. Роли две, а человек один.
Когда команда Михаила изучала свою ЦА — ФизЮриков — то заметила, что на ранней стадии развития бизнеса смешивают деньги бизнеса и физика.
Например, нужно срочно заплатить контрагенту, а денег нет. Тогда бизнесмен идет в банк, берёт потребительский кредит и оплачивает товар или услуги. Деньги физика стали юридическими.
А когда деньги уже есть, то бизнесмен может оплатить покупки в магазине корпоративной картой (вдруг забыл обычную) и потом внести их обратно.
А почему мы не можем нашему клиенту сделать благо, чтобы он мог закрывать кассовый разрыв за счет простого перевода между счетами?
«Он наш клиент как физик, как ИП, как компания — мы знаем его счета, сколько там денег, мы это можем сделать можем легко»
Например, сделать так, чтобы на главном экране приложения можно вытащить любой счет для визуализации, добавить в избранное, и он там будет отражаться.
Как это сделать?
Нужно договариваться с командой №1, которая отвечает за главный экран.
Нужно договариваться с командой №2, которая отвечает за список всех счетов — ведь появляются новые счета.
Если мы проваливаемся в счет, то видим детальную информацию: доступны кнопки просмотра операций, заказ справок и так далее. Это команда №3.
Но нам же ещё перевод надо сделать — это четвёртая команда.
Четыре команды, а сюжет один — «Я, как клиент, хочу увидеть счет, чтобы с него инициировать операцию. Я хочу быстро перевести деньги»
Окей. У нас получается одна пользовательская история, но несколько команд, у каждой из которых:
свои цели;
свои приоритеты;
свои метрики;
свои бюджеты;
свои бэклоги.
Приходится договариваться со всеми.
Подводные камни и бюрократия
Когда мы разрабатываем такие кросс-продукты, которые завязаны на несколько команд, то возникают некоторые проблемы.
Чем дольше мы делаем — тем больше мы делаем.
Чем больше команд — тем больше факторов этих изменений, и вы не можете гарантировать, что новых проблем не появится. Вы не можете гарантировать, что все согласятся на ваши условия или не появятся более приоритетные задачи от других команд. Здесь только договариваться лично, встречаться, встречаться, встречаться. Но у этого процесса тоже есть последствия.
«У нас было так много встреч, что мы забывали людей, с кем встречались и с кем надо встретиться»
Поэтому вывели первое правило — найти всех заинтересованных, все системы, всех людей. Их нужно просто физически найти, донести свою историю и пользу для них. Без этого в последний момент обязательно появится тот, кто скажет, что его мнение не учли и на пальцах покажет, почему вы в этот момент ошиблись.
Второе правило — модерация и строгое движение по адженде. Назначаем большую расширенную встречу, куда зовем скрам-мастера в роли фасилитатора. Скрам-мастер двигает встречу по строгому плану и записывает все договоренности, чтобы никто потом не сказал «Ничего не помню, не было такого».
Третье правило — предварительные встречи обязательны. На одной встрече вы никогда ничего не добьетесь. Вы сможете только погрузить в контент.
На предварительных встречах определяется состав участников: кто поддерживает проект, кто нет, у кого есть какие блогеры, у кого есть какие-то потребности. А дальше включается режим политики — после первой встречи нам нужно определить всех, кто против и всех кому надо. С противниками можно проводить отдельные встречи и обращать в свою веру. А если и это не получается — эскалировать на уровень выше.
Четвёртое правило — протокол встречи всегда должен быть честным. Со встреч все выходят с разными выводами, а у протокола может быть своё «мнение», ведь кто ведёт протокол встреч, тот и прав.
Но так не надо делать — пишите правду.
Вы работаете в кросспродуктовой команде, вы с этими продуктами будете пересекаться ещё не раз. В следующий раз вам припомнят подлог.
Выводы
Несколько инсайтов.
Как вы уже могли понять, в кросспродуктах гораздо больше переговорных процессов чем в «стандартных» подходах. Поэтому этап Delivery обязателен для задач, в которых создаём новый продукт или меняем клиентский опыт.
«Например, на одном из продуктов (не на этом), мы проводили согласование в течение месяца (или даже двух), а сам продукт делали два(!) дня. С тестированием»
Время всегда играет против нас. Если будем делать идеальный продукт — будем делать его вечно. Отсюда следует, что
Всегда запускаем MVP.
«Ну не покатится ничего кросспродуктового с полноценным. И к тому же мы еще ошибемся в клиентской ценности, хотя мы проводили UX-исследования, проводили Grow Hack эксперименты»
Сроки обязательно «поедут». Это аксиома. Примите как данность.
Найдите всех заинтересованных. Всегда может прийти дядя Вася, который скажет что вы всё сделали не так.
Будьте полезны. И команды к вам потянутся.
Вот такие доклады были у нас в новом офисе в Екатеринбурге.
Параллельно Кирилл Викентьев, CPO GrowthHacking & JTBD, и Анна Саботович — Android TechLead, провели офлайн-воркшоп: «LEGO в разработке: удешевить и ускорить»
На воркшопе прошли введение в SDUI, слушатели разбились на команды, и каждая сгенерировала свой эксперимент: нарисовали, прописали и объяснили свой дизайн и разработку — фреймворк для динамичных экспериментов. Заходите в альбом в нашей группе ВК Alfa Digital, там больше фотографий с воркшопа.
Такие (и ещё лучше) митапы мы будем проводить ещё — приходите, вживую они веселее… Мы проводим их регулярно, а анонсы публикуем в нашем Телеграм-канале Alfa Digital. Подписывайтесь!
