30 Августа 2021 09:00 30 Авг 2021 09:00 |

Поделиться

Артем Каличкин, Faktura.ru, в интервью CNews — о цифровом быте и аутсорсинге головной боли

«Неизбежность цифрового быта»

CNews: Дистанционное банковское обслуживание (ДБО) — основа основ современного банкинга. Что сегодня происходит в этой отрасли, какие основные тенденции можно отметить?

Артем Каличкин: Основная тенденция, которая характеризует современные процессы вообще, не только в сфере онлайн-банкинга, — это тотальная цифровизация быта, цифровизация обыденной, повседневной жизни. Это началось не вчера и не в прошлом году, просто пандемия сделала этот процесс форсированным. Всегда есть колеблющиеся, сомневающиеся, консерваторы и традиционалисты. Все они до последнего времени предпочитали за финансовыми услугами обращаться в офис банка. События 2020-2021 гг. коренным образом переломили эту ситуацию, заставив колеблющихся принять неизбежность цифрового быта.

Другой стороной этих процессов стало то, что ДБО наравне с процессингом окончательно приобрели статус критических. А это влечет за собой повышенную ответственность за все технологические и бизнес-процессы — просто потому, что ты теперь буквально обеспечиваешь нормальную жизнедеятельность людей. Доступность сервиса, безошибочность его работы, максимально быстрая и адекватная реакция в случае, если все-таки что-то пошло не так. Эти параметры сегодня необходимо обеспечивать фактически на стопроцентном уровне в режиме 24/7.

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

ДБО сегодня — это предоставление услуг «здесь и сейчас». Пользователь ждет, что в любой момент времени, дня и ночи, когда бы он ни захотел, он воспользуется любым сервисом немедленно. Ему нет дела до того, что в банке может быть завершение операционного дня, а глобальная мобильная платформа с новой версией вновь закрутила гайки по безопасности, что требует ресурсов для приведения решения в соответствии с новыми требованиями.

«Клиенты могут предъявлять абсолютно заоблачные требования»

CNews: Учитывая критическую важность онлайн-банкинга, какие требования к ДБО сегодня предъявляют банки?

Артем Каличкин: Я бы ответил на эти вопросы с точки зрения такой сущности, как источники развития продукта. У нас их три. Первый — это ожидания банков по поводу функциональных возможностей, которые есть в Faktura.ru. Банк хочет, чтобы мы поддержали доступность в дистанционных каналах максимального количества продуктов и сервисов, которые есть в его линейке. То есть это тема цифрового офиса и daily banking.

Второй источник — инициативы и требования Центробанка. Поставщик ДБО должен помогать, а также давать решения под ключ для всех инициатив ЦБ. Появляется много централизованных, независимых от конкретного банка сервисов. Это и «Система быстрых платежей», и «Единая биометрическая система», и «Финансовый маркетплейс». Сейчас появилась новая тема, которая обещает в ближайшее время стать горячей — цифровой рубль. У Faktura.ru, кстати, есть шанс вместе с нашим банком-партнером оказаться в первых рядах, поскольку мы участвуем в пилотном проекте. Понятно, что эти сервисы подлежат реализации в банках просто в силу того, что исходят от регулятора. И банки ожидают, что вендор максимально быстро и качественно поддержит все инициативы ЦБ. В этих процессах мы стараемся работать на опережение — предложить банку решение раньше, чем он сам обратится с запросом.

Здесь я плавно перехожу к третьему источнику развития продукта — нашему внутреннему R&D. Мы предоставляем продукт не по запросу банка, а создаем его, опираясь на собственное видение того, что функционально обогатит онлайн-банкинг, будет востребовано клиентами и имеет перспективы с точки зрения бизнеса банка. Мы постоянно участвуем в профессиональных рейтингах не столько для того, чтобы занимать там призовые места, сколько с целью быть на острие индустрии, в ее авангарде. А этого можно добиться только постоянным и неустанным сканированием среды, тщательным анализом решений конкурентов и глубоким погружением в запросы и ожидания конечных пользователей. Мы научились жить в режиме тестирования гипотез. Я не могу сказать, что у нас есть отдельная Growth Hacking Team, но в Faktura.ru каждая команда в состоянии в рамках одного спринта затащить и какие-то базовые вещи в функционал доработки, и реализовать гипотезу для проверки на реальных клиентах.

Все это касается функционала ДБО, но это лишь надводная часть айсберга. Банки очень строги в своих ожиданиях того, что наш функционал будет работать правильно и будет доступен клиенту в любой момент времени. Каким бы сложным ни был сервис, как бы много точек взаимодействия с другими сервисами банка и поставщиками услуг ни было, сервис ДБО должен иметь стабильную высокую доступность не ниже 99,9%. Банк не ожидает, что у нас может не хватить мощностей по железу, потому что у него выросло количество клиентов. Он не для этого к нам пришел. Банк ожидает, что мы заранее поймем, что мощности надо наращивать и вовремя сделаем это. К счастью, в этом отношении мы максимально управляем ситуацией, поскольку работаем на собственных ЦОДах.

Наконец, банки требуют, чтобы их ДБО полностью соответствовало всем требованиям с точки зрения комплаенса. Отрасль финтеха в РФ достаточно строго регулируется: есть федеральные законы, инициатором которых является Банк России, есть законы, защищающие персональные данные, есть регламенты от ФСБ для каналов связи. Никто не отменял и международные сертификации. Банк ожидает, что при любой проверке со стороны регуляторов его ДБО-провайдер соответствует по комплаенсу всем существующим требованиям и нормативам. А это бесконечный процесс — нельзя один раз получить сертификат и положить его на полочку, будь любезен регулярно проходить аудиты и проверки и подтверждать соответствие. Рифмующаяся с комплаенсом тема информационной безопасности: фрод-мониторинг, проведение penetration test, встраивание в цикл разработки принципов secure development lifecycle и многое другое. Это все огромный пласт работы, который требует и инженерных, и управленческих, и организационных ресурсов, поэтому мы не только провайдер финансовых фич, но и аутсорсер головной боли. Кредитная организация покупает у нас не просто работающий интернет-банк, а получает надежный, защищенный, полностью соответствующий всем требованиям регулятора онлайн-банкинг. Вот это важно понимать.

CNews: Зайдем с другой стороны и попробуем выяснить, что хотят получить от ДБО клиенты?

Артем Каличкин: Клиент хочет, чтобы у него был самый удобный онлайн-банкинг, который позволит не ходить в офис вообще. Чтобы там все было быстро, понятно и удобно. Такое ДБО, чтобы он мог гордиться, что он клиент этого банка, чувствовать себя прогрессивным и передовым в эпоху глобальной цифровизации. Если по телевизору сказали, что можно где угодно сдать биометрию, то человек хочет ее сдать в своем интернет-банке. Это прекрасная эпоха, потому что клиенты могут предъявлять абсолютно заоблачные требования и имеют на это полное право, потому что кто-нибудь эти требования реализует и поддержит.

Интернет-банк должен работать всегда, когда клиент хочет в него войти и выполнить операцию. В черную пятницу и кибер-понедельник я, конечно, ожидаю, что мой банк будет обслуживать все транзакции. При этом безопасность должна быть гарантирована на 100%. Ожидания клиента — это не какой-то закрытый список. Завтра, сегодня, через секунду клиент может захотеть чего-то совершенно экстравагантного и заоблачного, совершенно любых вещей. Если бы биткойн существовал в законодательном поле, наверняка уже было требование, чтобы через ДБО можно было торговать им. Клиенту нужно чуть больше, чем все.

CNews: Вот, кстати, интереснейшая тема. Насколько важно для кредитных организаций иметь онлайн-банкинг, уникальный по своим пользовательским параметрам? Faktura.ru предлагает банкам и дефолтный вариант ДБО, и возможность кастомизации решения. Насколько это востребовано на рынке и можете ли вы создать для банка-клиента эксклюзивное ДБО?

Артем Каличкин: В вопросе звучат несколько ключевых слов: «дефолт», «кастомизация» и «эксклюзив». Давайте для начала определимся в дефинициях. Сначала про дефолтное решение. В Faktura.ru реализован очень большой объем функционала, но клиенты конкретного банка получают в ДБО ту его часть, которая соответствует продуктовой линейке этой кредитной организации. Следующая часть совместимости — интеграция с учетным ядром. Российские банки в массе своей используют АБС от 4-6 вендоров. У Faktura.ru реализованы механизмы интеграции со всеми ключевыми системами через ПО «Шлюз», но для каждого нового сервиса необходимо организовывать поддержку в каждой из бэк-систем. В каком-то смысле здесь уже идет речь о кастомизации решения под реальные потребности банка, хотя формально мы рассматриваем дефолтную версию ДБО.

В парадигме Faktura.ru кастомизация — это, прежде всего, адаптация визуального графического решения под бренд-бук банка. Ее основная задача заключается в том, чтобы клиент, заходя в ДБО, чувствовал себя внутри экосистемы банка. Подавляющее большинство банков, предоставляющих своим клиентам сервисы онлайн-банкинга на платформе Faktura.ru, используют именно кастомизированный дизайн. У нас реализовано приложение для банков, где они могут создавать макеты этих кастомизированных под фирменный стиль банка версий.

Если говорить о более глубокой кастомизации, например, на уровне UX/UI, то все-таки наша экспертиза, получаемая в результате работы с очень большим количеством банков, позволяет нам быть уверенными в правильности наших решений. Мы имеем возможность анализировать действия клиентов очень разных поведенческих моделей и на основе этого анализа выдавать хорошо просчитанные и обусловленные практикой UX-решения.

На моей памяти был лишь один случай, когда мы оказались не правы. Очередную версию интернет-банка для юридических лиц мы сделали с «воздухом», большими формами. В результате платежка не вмещалась на одну форму, пользователю нужно было несколько раз нажимать кнопку «Далее». По всем современным гайдам это нормально. Но мы не учли, что пользователи — это по большой части сотрудники отделов бухгалтерского учета, люди весьма консервативные, к тому же работающие в «1С», где масса полей на одной форме, и такая смена UI внесла существенные ограничения в их бизнес-процесс. Мы признали ошибку и внесли корректировки в решение. Получили еще одно подтверждение старого афоризма, что хороший UX убивает UI. Любой удобный интерфейс будет похож на любой другой удобный интерфейс. UX — это в том числе расчеты: сколько времени занимает прохождение формы, позиционирование курсора мышки и т.д. Места для фантазии и креатива особо нет. Конечно, бывает, что у банка по какой-то операции свой специфический workflow, например, какой-то вид заявлений он печатает в начале процесса, а не в конце, а у нас реализовано наоборот. Тогда, конечно, мы кастомизируем алгоритм под workflow банка.

Теперь переходим к эксклюзиву. Немного я про это уже сказал: все удобное похоже на другое удобное. Эта первая горькая правда, которую нужно понимать про эксклюзивность. Второе. Эпоха ноу-хау — это вторая половина ХХ века. Человек изобрел пластиковый зонтик для коктейлей — стал миллионером. Другой придумал фасовать сахар/соль в порционные пакетики — сказочно обогатился. А в цифровом мире не существует ноу-хау. Если кто-то в цифровом мире собирается конкурировать какой-то фичей, он обречен на провал, потому что уже завтра появятся ее клоны, и она будет растиражирована. Никакой патент эти процессы не остановит. При этом конкурировать нужно, поскольку и такой конкуренции, как сейчас, в мире тоже еще не было.

В условиях отсутствия возможности конкурировать при помощи ноу-хау, остается только одно — конкурировать при помощи качества сервиса. Это основной механизм конкуренции в современном цифровом мире. Сделать цифровой быт пользователя максимально комфортным, удобным, сделать, не побоюсь этого слова, родным. Родной — максимально отзывчивый, чуткий, внимательный. Вот на этой основе и надо строить эксклюзивность финтеха, в том числе, конечно, ДБО. Интерфейс должен быть понятным и работать без промедлений и тормозов, сервисные службы должны реагировать своевременно на любые проблемы клиента, функционал должен по максимуму закрывать потребности. Вот если понимать эксклюзивность как эксклюзивное, привилегированное отношение к клиентам, то Faktura.ru как раз и обеспечивает банкам такое эксклюзивное ДБО. А эксклюзивность за счет возможности поиграть в тетрис в интернет-банке — ну, это так себе эксклюзивность.

CNews: То есть перед командой Faktura.ru задача генерировать что-то новое не ставится?

Артем Каличкин: Хороший вопрос, я периодически сталкиваюсь с ним в разных дискуссиях — его задают практически всем вендорам, не только нам. Смотрите. Что такое онлайн-банкинг, если выделить самую суть? Это инструмент для формирования и передачи распоряжения на перевод денежных средств. Если снять все листья с кочана капусты, останется кочерыжка — распоряжение на перевод денежных средств. Все. Поэтому и кажется, что все банки друг у друга все подглядывают и заимствуют. Наверняка, когда возникнет какой-то новый финансовый инструмент, например, тот же цифровой рубль, он создаст определенный простор для поиска новых ниш. А придумывать что-то карнавальное, экстравагантное, лишь бы выделиться, — вряд ли это наш путь. Считаем более важным поддерживать функциональность в максимально актуальном, востребованном состоянии, поддерживаем интенсивную обратную связь с банками, постоянно сверяемся с рынком, участвуя в рейтингах Markswebb, которые подтверждают, что мы в авангарде индустрии.

«Мир экстремально динамичен, а внутри — еще более подверженная трансформациям сущность — ИТ»

CNews: Как наладить ИТ-процессы, чтобы не просто поддерживать работоспособность платформы, которую использует сотня банков, но и заниматься ее постоянным развитием? Как у Faktura.ru построено производства продуктов ДБО?

Артем Каличкин: Очевидно, что для того, чтобы справляться со всем этим объемом, необходимо было построить максимально отлаженный, без сбоев работающий в формате 24/7 конвейер, гарантированно поставляющий по своей ленте весь необходимый для ДБО набор: функциональность, UX/UI, бесперебойность, отказоустойчивость, информационная безопасность, комплаенс. Если подходить к построению такого конвейера прямолинейно, то мы получим какую-то ужасную замятинскую картину: роботы-исполнители кодируют строго по регламенту блок-схемы, которые им передали откуда-то сверху. Вряд ли кто-то захочет встроиться в такой конвейер, но самое главное, такая организация процессов неэффективна для финтеха.

Окружающий нас мир экстремально динамичен, а внутри этой нестабильной системы существует еще более подверженная трансформациям сущность — ИТ. Мы строим самолет на лету. У нас нет возможности и права загнать эту махину в ангар, провести рефакторинг, полгода не выпуская фич, и строить «идеальное» инженерное решение. Нужны люди ищущие, инженеры с широким кругозором, постоянно актуализирующие свои знания на непрерывно меняющемся рынке технологий. И это профиль сотрудника Faktura.ru. Но конвейер никто ни отменял — он должен работать непрерывно и бесперебойно. Как же добиться компромисса между творческим инженерным поиском, который не бывает без ошибок, и конвейером?

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

На словах это звучит просто, но на деле для того, чтобы обеспечить такой режим работы производства, нам потребовалось реализовать много архитектурных и процессных изменений. Во-первых, для обеспечения надежного как молоток конвейера, работающего с соблюдением всех норм комплаенса, необходимо было все контроли, что называется «сдвинуть влево», shift left, согласно популярной концепции из мира lean и agile. Секретной магии здесь нет. Просто контроли автоматизируются, например, за счет использования статических и динамических анализаторов кода. И при этом выносятся с этапа выпуска приложения в продакшн на максимально более ранний из возможных этап. В идеале надо стремиться, чтобы они запускались при каждом коммите кода.

Более «тонкий» пример такого «сдвига» — это выделение среди разработчиков в каждой продуктовой команде своего security ninja. Его роль, как известно, заключается не только в тираже знаний и обеспечении дополнительного контроля, но в первую очередь — в формировании культуры приверженности принципам и паттернам безопасной разработки. Это всегда работа на перспективу, которая позволяет постоянно снижать количество выявляемых отклонений на всех этапах контроля безопасности. Аналогичная история с обеспечением качества. Мы осознанно ушли от роли QA как «выпускающего» подразделения и реализовали модель shift left и в этой области. Хоть это и не новая концепция, но ее реальное воплощение по-прежнему остается непростой задачей в условиях высоких темпов разработки. Сейчас мы приняли как стандарт де-юре и де-факто, что организация инфраструктуры и моделей тестирования для новых проектов начинаются с первых шагов проекта, а не в момент готовности кода. У нас установлены нормативы по автоматизации, есть четкие критерии, что именно и в каком объеме обязательно должно быть покрыто автотестами. Это, в том числе, позволяет прогонять цикл регрессионного тестирования не в конце спринта, а на регулярной основе, в том числе и перед выпуском фиксов между релизами.

Во-вторых, «блоки-лаборатории» не стали бы возможны без серьезных архитектурных изменений и даже не рефакторинга, а полноценных миграций отдельных блоков платформы на новые механизмы, инструменты и middleware. Мы провели большую работу по обеспечению достаточного уровня слабой связанности кода (decoupling), что позволяет безопасно вносить изменения в отдельные части приложений, не опасаясь, что это приведет к поломке, казалось бы, не связанных блоков. В ряде продуктов ключевые слои, отвечающие за бизнес-логику, мы перевели с классических монолитных решений на модульную архитектуру с понятными API взаимодействия, которые в том числе более надежно покрываются автотестами. Кроме этого, новые проекты мы пишем строго в сервисной архитектуре. Сейчас в процессе реализации очень амбициозный проект по бесшовной миграции интернет-банка для физических лиц на новый бэкенд. Это делается не потому, что «прошло 5 лет», как принято говорить на модных конференциях, и не для того, чтобы «было правильно», как мечтает «внутренний инженер» в каждом из нас. Нет, здесь простая прагматичная причина — именно слабая связанность кода, модульная архитектура, грамотное расслоение по «специализациям» и простые API обеспечивают возможность безопасно для основного функционала делать быстрые доработки для проверки гипотез как продуктовых, так и инженерных. Эти же принципы делают возможным реализацию «сдвига влево» контролей комплаенса и обеспечения качества.

Такой подход позволяет чередовать рутину и творчество всем без исключения членам команды. Инженерный поиск дает возможность творческой самореализации, а вовлеченность в рутинные процессы не позволяет оторваться от жизни — люди, которые не пишут код, выходящий в продакшн, не должны принимать архитектурных решений и быть авторами технологических схем. Правильность такого подхода подтверждает тот азарт, с которым работают наши ребята, несмотря на колоссальную нагрузку. Работать в Faktura.ru — это работать много. Но, с другой стороны, — это создавать инфраструктуру финансового сектора страны. Наши специалисты создают ее не на базе существующих стандартов, технологий, спецификаций, а сами их придумывают.

Наталья Рудычева

Поделиться

Подписаться на новости Короткая ссылка