Когда вы в последний раз совершали революцию? Мы — в ноябре 2021 года, когда внедрили кредиты на платформе личных финансов https://finuslugi.ru/. Впервые у россиян появилась возможность взять кредит полностью онлайн, не посещая офис банка. При этом пользователь заполняет одну заявку и отправляет её сразу в несколько банков, а затем выбирает лучшее предложение — и не важно, есть в его регионе офис этого банка или нет.
Почему Московская биржа занимается маркетплейсом для «физиков», мы немного говорили здесь. Если коротко: мы давно больше, чем биржа, и успешно работаем на внебиржевых рынках — для этого у нас хватает и знаний, и технологий. Плюс к тому, одна из наших задач — развивать финансовую культуру страны. Вот мы и развиваем — создавая продукты, которые меняют представление об управлении личными финансами. Иметь несколько вкладов на разные цели, между которыми можно перекладывать деньги в пару кликов, а если хочется инвестировать, тут же можно прикупить облигаций регионов — круто же?
Но мы отвлеклись. Сегодняшний материал будет о продукте «Кредиты». О том, как создавались кредиты на Финуслугах, с какими вызовами мы столкнулись и как с ними справились, рассказывают ребята из продуктовой команды: Андрей Кителёв (тимлид команды), Алёна Садовская (лидер разработки продукта) и Павел Кряженков (директор департамента разработки электронных платформ). Спойлер: будет и про командную работу, и про knowledge-management, и про чистую архитектуру.
Выбор продукта
Из всей линейки кредитных продуктов первым мы выбрали именно потребительский кредит, и вот почему:
у каждого банка уже есть такой продукт;
потребительский кредит максимально понятен клиентам;
потребительские кредиты популярны, и на их основе можно будет быстрее внедрять новые продукты: кредитные карты, рефинансирование, кредиты под залог.
Преимущества потребительского кредита на Финуслугах:
Банки:
могут обслуживать клиентов из любого региона России;
не тратятся на физическое обслуживание клиентов (например, во время подписания документов в офисе);
могут сосредоточиться на предложении лучших условий по продукту вместо разработки креатива и концепции продвижения;
могут получить большой поток клиентов, которые генерирует сам маркетплейс.
Клиенты:
могут получить кредит не в том банке, который рядом, а в том, в котором выгодно;
могут заполнить одну заявку, отправить её сразу в несколько банков, получить от всех них решение и выбрать наиболее подходящее предложение;
могут получить сумму кредита на счёт в любом банке.
Начало проекта
Старт работ по кредитам на Финуслугах совпал у нас с переходом от монопродуктовой к мультипродуктовой разработке и с созданием продуктовых команд. Проект был амбициозным, необходимо было из одной большой команды, разрабатывавшей депозиты на Финуслугах, выделить:
отдельную продуктовую команду для разработки линейки «Сбережения»;
сервисные команды для работы над кросс-продуктовой функциональностью;
а также создать новую команду, которая менее чем за год смогла бы запустить MVP, позволивший бы оформлять кредит в любом банке через сайт Финуслуг.
MVP
Первой ключевой задачей команды было определение функций MVP. Мы собрали рабочую группу из различных участников и партнёров проекта Финуслуги, и по результатам её деятельности команда «Кредиты» разработала универсальный процесс онлайн-кредитования, который учитывает все потребности каждого клиента, соответствует законодательной базе РФ и подстраивается под особенности любых банков. Сначала проанализировали процессы получения кредитов у банков из рабочей группы, после чего провели исследования первых прототипов на реальных клиентах и коридорные исследования с работниками смежных подразделений Московской биржи. В результате сформулировали основные этапы процесса:
заполнение короткой анкеты;
получение нескольких предварительных предложений от банков;
выбор лучшего предложения и заполнение полной анкеты для его подтверждения;
получение финального предложения от понравившегося банка;
подтверждение финального предложения;
выдача денежных средств и отправка отчёта в РФТ (Регистратор Финансовых Транзакций).
Попытка купить готовое решение (кредитный конвейер)
Сначала мы делали ставку на приобретение готового кредитного конвейера и встраивание его в архитектуру Финуслуг. Изучили рынок, но решения, которое полностью удовлетворило бы нашим нуждам, просто не существует, потому что каждое из них адаптировано под свои определённые цели и не позволяет создать тот универсальный продукт, который был в наших планах. В итоге решили делать самостоятельно — это позволило нам разработать универсальный сервис и не зависеть ни от кого при его дальнейшем развитии. Мы сами принимаем решения по его доработке, в том числе по запросам партнёров и пользователей
Технические решения по ходу разработки
Для нового продукта нам понадобилось разработать несколько новых микросервисов:
Обработка кредитных заявок клиента и банковских предложений.
Обработка кредитных договоров.
Интеграционный шлюз для работы с банками.
API для UI-приложения.
UI-приложение.
Также внесли небольшие доработки в общие платформенные сервисы маркетплейса (уведомления, словари, продуктовый каталог и прочее).
О технологическом стеке проекта Финуслуги мы писали год назад, и с тех пор он существенно не изменился. Использование того же стека помогло минимизировать затраты на поддержку нового продукта, а также позволило применить практики InnerSource для кросс-командной разработки общих платформенных сервисов и тем самым ускорить внедрение новых фич.
Для разработки кредитных микросервисов старались использовать best practices проектирования ПО, а также опирались на опыт разработки существующих сервисов внутри экосистемы Финуслуг, чтобы поддерживать общую целостность и придерживаться единых стандартов в проекте.
Разработка
Мы ставили перед собой цель обеспечить не только высокое качество продукта, но и простоту его поддержки. Большую роль в этом сыграл подход к написанию документации. Мы уделили ей особое внимание с самого начала проекта. В вики описывалось всё — от верхнеуровневого представления процессов до правил маппинга полей при обработке каждой конечной точки. Периодически мы сомневались, целесообразно ли тратить столько сил на документацию, но по мере усложнения процессов приходило понимание, что оно того стоило:
Низкий порог входа для новых участников команды, которые быстрее разбирались в продукте и начинали приносить пользу.
Более качественная реализация задач.
Минимизация ошибок и оперативное их устранение.
Упрощение межкомандного взаимодействия за счёт описанных процессов.
А сейчас, на этапе поддержки продукта, в пользе документации мы убеждаемся ещё больше.
Также разработчики придерживались принципа коллективной ответственности за кодовую базу. Все merge request’ы (МРы) в обязательном порядке проходили код-ревью, и только после получения минимум двух одобрений код заливали в основную ветку. На проверку каждый день выделяли по полчаса утром и вечером. При выявлении ошибок программирования мы не искали виноватых на основании истории изменения исходного кода, потому что влитый код означал, что команда приняла эти изменения коллективно. Такой принцип стимулировал разработчиков старательно проверять код и не одобрять его просто так.
1. Техтолки
Большую роль в повышении качества кодовой базы сыграла и практика регулярных встреч-техтолков командой разработчиков. На встречах обсуждали любые вопросы и сложности, возникающие при работе с кодовой базой, а также принципы написания кодовых конструкций, минимизирующие вероятность ошибок за счёт улучшения читаемости и поддерживаемости.
Примеры тем:
Правила именования и внутренней структуры тестовых методов.
Принципы работы с null-объектами, использование класса
java.util.Optional.Способы написания миграционных скриптов БД (Liquibase DSL или SQL).
Выбор фреймворка для маппинга DTO.
Все договоренности мы записывали в вики на отдельной странице, которая служила разработчикам хорошим руководством при написании кода и значительно уменьшала когнитивную нагрузку, не относящуюся напрямую к решению бизнес-проблемы.
2. Проба чистой архитектуры
Кроме вопросов написания конкретных фрагментов кода на техтолках обсуждалась также и архитектура сервисов. Изначально все сервисы мы писали по стандартному принципу создания веб-приложений из трёх условных слоёв: веб, сервисы и доменная модель. Но по мере усложнения бизнес-логики стало всё труднее расширять существующую функциональность. На помощь пришла концепция чистой архитектуры, о которой написан не один десяток книг. Она нам очень понравилась, хотя опыта работы с ней практически не было.
Посовещавшись, решили испробовать новую концепцию на свежем микросервисе для работы с контрактами. В качестве руководства использовали книгу "Get Your Hands Dirty on Clean Architecture" — пожалуй, самое практическое руководство по чистой архитектуре. Автор не настаивает на конкретном способе реализации архитектуры и не позиционирует его серебряной пулей, которая решит все проблемы. Вместо этого он призывает сохранять баланс между архитектурной сложностью и гибкостью решения в зависимости от поставленной задачи.
На создание основы сервиса по новому подходу ушло больше времени, чем обычно. Для сервисов со старой парадигмой мы используем Maven-архетип, который позволяет за пару минут создавать заготовку сервиса. А с чистой архитектурой так уже не получалось: доработка под новую концепцию заняла бы ещё больше времени, чем создание сервиса с нуля. Также необходимо было определиться с модульной структурой сервиса, выбрать наиболее подходящую стратегию маппинга и понять, как это всё сочетается с использованием ORM-фреймворка. Не будем сейчас углубляться в подробности, иначе статья превратится в отчёт об использовании clean architecture вместо обзора проделанной нами работы, но с удовольствием ответим на все вопросы в комментариях
Интересные статьи
Интересные статьи
