Когда вы в последний раз совершали революцию? Мы — в ноябре 2021 года, когда внедрили кредиты на платформе личных финансов https://finuslugi.ru/. Впервые у россиян появилась возможность взять кредит полностью онлайн, не посещая офис банка. При этом пользователь заполняет одну заявку и отправляет её сразу в несколько банков, а затем выбирает лучшее предложение — и не важно, есть в его регионе офис этого банка или нет. 

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

Но мы отвлеклись. Сегодняшний материал будет о продукте «Кредиты». О том, как создавались кредиты на Финуслугах, с какими вызовами мы столкнулись и как с ними справились, рассказывают ребята из продуктовой команды: Андрей Кителёв (тимлид команды), Алёна Садовская (лидер разработки продукта) и Павел Кряженков (директор департамента разработки электронных платформ). Спойлер: будет и про командную работу, и про knowledge-management, и про чистую архитектуру.

Выбор продукта

Из всей линейки кредитных продуктов первым мы выбрали именно потребительский кредит, и вот почему:

• у каждого банка уже есть такой продукт;

• потребительский кредит максимально понятен клиентам;

• потребительские кредиты популярны, и на их основе можно будет быстрее внедрять новые продукты: кредитные карты, рефинансирование, кредиты под залог.

Преимущества потребительского кредита на Финуслугах:

• Банки:

  • могут обслуживать клиентов из любого региона России;

  • не тратятся на физическое обслуживание клиентов (например, во время подписания документов в офисе);

  • могут сосредоточиться на предложении лучших условий по продукту вместо разработки креатива и концепции продвижения;

  • могут получить большой поток клиентов, которые генерирует сам маркетплейс.

• Клиенты:

  • могут получить кредит не в том банке, который рядом, а в том, в котором выгодно;

  • могут заполнить одну заявку, отправить её сразу в несколько банков, получить от всех них решение и выбрать наиболее подходящее предложение;

  • могут получить сумму кредита на счёт в любом банке.

Начало проекта

Старт работ по кредитам на Финуслугах совпал у нас с переходом от монопродуктовой к мультипродуктовой разработке и с созданием продуктовых команд. Проект был амбициозным, необходимо было из одной большой команды, разрабатывавшей депозиты на Финуслугах, выделить: 

• отдельную продуктовую команду для разработки линейки «Сбережения»; 

• сервисные команды для работы над кросс-продуктовой функциональностью;

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

MVP 

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

• заполнение короткой анкеты;

• получение нескольких предварительных предложений от банков;

• выбор лучшего предложения и заполнение полной анкеты для его подтверждения;

• получение финального предложения от понравившегося банка;

• подтверждение финального предложения;

• выдача денежных средств и отправка отчёта в РФТ (Регистратор Финансовых Транзакций).

Попытка купить готовое решение (кредитный конвейер)

Сначала мы делали ставку на приобретение готового кредитного конвейера и встраивание его в архитектуру Финуслуг. Изучили рынок, но решения, которое полностью удовлетворило бы нашим нуждам, просто не существует, потому что каждое из них адаптировано под свои определённые цели и не позволяет создать тот универсальный продукт, который был в наших планах. В итоге решили делать самостоятельно — это позволило нам разработать универсальный сервис и не зависеть ни от кого при его дальнейшем развитии. Мы сами принимаем решения по его доработке, в том числе по запросам партнёров и пользователей

Технические решения по ходу разработки

Для нового продукта нам понадобилось разработать несколько новых микросервисов:

1. Обработка кредитных заявок клиента и банковских предложений.

2. Обработка кредитных договоров.

3. Интеграционный шлюз для работы с банками.

4. API для UI-приложения.

5. 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 вместо обзора проделанной нами работы, но с удовольствием ответим на все вопросы в комментариях ????

Результат себя оправдал: в период активной разработки, когда над сервисом работало одновременно три разработчика и каждый добавлял новую функциональность, МРы не конфликтовали между собой. Этого удалось достичь явным отделением доменной модели и бизнес-логики от остальной логики — обработки HTTP-запросов, работы с БД, маппингов и т. д. Таким образом, каждый компонент имел только одну причину для изменений и при параллельном добавлении новых фич старый код изменялся минимально или вообще оставался нетронутым. Также за счёт уменьшения ответственности и межкомпонентных зависимостей проще писать и поддерживать тесты, что тоже повышает качество продукта.

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

Тестирование

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

Бизнес-мониторинг

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

Первая задача — своевременное отслеживание и реагирование на возможные ошибки со стороны системы для контроля качества её работы с точки зрения клиентов. Мы в любой момент времени видим на дашбордах состояние системы, получаем оповещения при технических сбоях и узнаем о проблемах клиента чаще всего ещё до того, как он обратится в поддержку.

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

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

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

Планы по развитию

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

В ближайших планах:

• оптимизировать клиентский путь, минимизировав требуемые от клиента действия и ввод данных;

• подключить Цифровой профиль, который позволит повысить уровень одобрения и качества предложений от банков;

• расширить совместно с банками перечень потребительских кредитов;

• расширить линейку неплатформенных продуктов: предоставить клиенту ещё больше вариантов возможных кредитов.

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

Хотите посмотреть, что у нас получилось? Переходите по ссылке.