АПИКС – название информационной системы автоматизации процессов ипотечного кредитования и сопровождения в Банке ДОМ.РФ (рис.1). Система предназначена для управления ипотечными продуктами, автоматизации процесса предоставления клиентам ипотечного кредита, а также выкупа и сопровождения закладных до полного исполнения обязательств. Я, Алексей Прутик, чаптер-лид системного анализа, в данной статье расскажу, как мы на базе АПИКС строим единый кредитный конвейер, совершенствуем наши ИТ-процессы и архитектуру.

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

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

 От информационных систем, обеспечивающих данное направление, ожидаются:

• автоматизация всего бизнес-процесса ипотечного кредитования и сопровождения,

• интеграция с информационными системами партнеров,

• адаптация продукта под меняющиеся условия рынка,

• высокая скорость вывода новых функций в промышленную эксплуатацию,

• высокие показатели отказоустойчивости.

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

Процесс ипотечного кредитования и сопровождения

Бизнес-процесс ипотечного кредитования и сопровождения состоит из трех этапов (рис. 2):

1. Продажа. На данном этапе для потенциального заемщика (лида) осуществляется предварительный подбор ипотечного продукта (кредита) и расчет его параметров. Лиды формируются из потока клиентов, которые обращаются в Банк самостоятельно или по направлению партнеров Банка. Для получения предварительного одобрения по клиенту формируется короткая заявка, включающая набор минимальных сведений (ФИО, первоначальный взнос, доходы и расходы). При заинтересованности клиента, на основе короткой заявки формируется полная заявка, включающая в себя дополнительную информацию, необходимую для оценки платежеспособности клиента. В терминологии ипотечного кредитования такая активность называется «андеррайтингом». Ее результатом в рамках АПИКС может быть решение об одобрении, отказе или доработке заявки.

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

2. Выдача – процесс оформления ипотечной сделки. Включает в себя: формирование шаблонов и форм печатных документов кредитно-обеспечительной документации (КОД); определение графика платежей и выдачу ипотечного кредита. Благодаря использованию электронного подписания документов и электронной регистрации сделки в Росреестре весь процесс может проходить в удалённом режиме. Посетить офис потребуется всего один раз – непосредственно в дату сделки.

3. Сопровождение. Контроль выполнения денежных обязательств клиентов, страхового обеспечения, изменения условий кредитного дела, хранение закладных.

   Дополнительно существует процесс рефинансирования кредита (выкупа ипотечных закладных у других банков), оставим его за рамками данной статьи.

Функциональная архитектура

Для реализации приведенного бизнес-процесса в АПИКСе реализованы следующие способы подачи ипотечных заявок (рис. 3):

• Через Пользовательский интерфейс (оператора Банка),

• Через Личный кабинет ипотеки (ЛКИ)

• Через Внешний API

• Через Лендинг-сайт

Схема отображает различия в способах подачи ипотечных заявок:

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

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

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

• Лендинг-сайт - инструмент застройщиков. Застройщиками-партнерами Банка используется лендинг-страница с экспресс-формой, которая включает несколько кредитных продуктов, кредитный калькулятор и минимальный набор полей для заполнения данных о заемщике. Оператор со стороны застройщика заполняет форму (для этого не требуется особых навыков) и отправляет данные в Банк, чем запускает механизм онлайн-одобрения заявок, реализованный в АПИКСе. Автоматические проверки во многом похожи на Экспресс АПИ. Разница в том, что заявка с лендинг-сайта автоматически подхватывается оператором Банка и дальнейшее обслуживание выполняется в Пользовательском интерфейсе.

Каждый из способов (каналов поступления) фиксируется в заявке и служит триггером для задействования тех или иных микросервисов.

Программная архитектура

Информационная система АПИКС спроектирована на основе микросервисной архитектуры. Схема компонентной архитектуры представлена на рисунке 4.

АПИКС включает в себя больше 60 взаимодействующих по MQ и REST-принципам микросервисов. Оркестратором сервисов при реализации бизнес-процесса кредитования является Camunda BPM. Согласно приведенной схеме, сервисы условно поделены на следующие группы – см. таблицу 1.

Таблица 1 – Группы микросервисов АПИКС

АПИКС обеспечивает информационный обмен с внешними системами посредством синхронных и асинхронных интеграций (REST, SOAP, MQ). Сокращенный перечень внешних систем и их назначение (вместо реальных названий используются придуманные для статьи):

• Система принятия решений (СПР) – оценка (андеррайтинг) физических лиц и предмета ипотеки;

• СПАРК – проверка работодателя заемщика;

• РСПИ – получение оценочной (рыночной) стоимости предмета ипотеки;

• ДаДата – используется в качестве советчика для заполнения паспортных данных клиента;

• ЭЦПС – обеспечивает использование ЭЦП;

• AБИ – распознавание паспорта и справки 2-НДФЛ, сравнение документов;

• DocStore – хранилище документов;

• ПОС – платформа онлайн-страхования;

• Росреестр – для регистрации сделки;

• ЕСИА – получение учетной записи клиента через сервис Госуслуг;

• АБС – регистрация кредитного договора, формирование графика платежей;

• Сторонние УЦ (удостоверяющие центры) - для выполнения операций электронного подписания.

При электронной регистрации сделки в Росреестре от участников требуется подписать необходимые документы, используя усиленную квалифицированную подпись (УКЭП). Если УКЭП выпущена сотрудниками Банка, то участникам сделки достаточно подтвердить подписание в приложении КриптоПро MyDSS. Если УКЭП была выпущена в другом месте или сервисе, от участников сделки потребуется предоставить файлы документов и соответствующие им файлы подписей в формате SIG.

Структура команд и методология разработки

В процессе разработки АПИКС используются гибкие методологии Scrum и Kanban, адаптированные под потребности нашего проекта c учетом архитектуры системы. Над проектом работает более 90 человек, которые поделены на команды по продуктовым направлениям с учетом необходимости обеспечения независимой разработки внутри команды. Это достигается с помощью микросервисной архитектуры, которая позволяет назначить в ответственность каждой команды развитие набора определенных микросервисов.

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

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

Рассмотрим подробнее состав команд и этапы работ.

Каждая команда разработки включает в себя следующие роли (рис. 5):

• Team Leader (TL) – лидер команды с техническим бэкграундом (в прошлом бэк/фронт разработчик или системный аналитик).

• Product Owner (PO) – владелец продукта: ведет бэклог, определяет приоритеты, совместно с TL осуществляет координацию команды для достижения целей спринта, проводит ежедневные статусы (дэйли), ретроспективы.

• Business Analyst (BA) – бизнес-аналитик: выполняет бизнес-анализ по задачам.

• System Analyst (SA) – системный аналитик: выполняет системный анализ, используя результаты бизнес-анализа.

• Backend Develop (BE) – бэкенд-разработчик (Java).

• Frontend Developer (FE) – фронтенд-разработчик (React).

• QA Engineer (QA) – тестировщик: формирование тестовой модели (тест-кейсов) и контроль качества путем ручного функционального тестирования.

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

Команды поддержки

Отдельно существуют команды платформы, технического долга и сопровождения. К команде платформы относятся роли:

• QA Automation Engineer – автотестер: разработка и поддержка автотестов, на базе корпоративного фреймворка.

• DevOps – девопс-инженер: отвечает за инфраструктуру, CI/CD. Выполняемые функции: поддержка и развитие CI/CD на базе Teamcity; помощь разработчикам с дебагом приложений; проектирование инфраструктуры для переезда в новый ЦОД; участие в разборе инцидентов в промышленной среде; взаимодействие со специалистами по безопасности Банка, устранение уязвимостей на серверах или в Kubernetes; поддержка инструментов мониторинга Prometheus+Grafana; поддержка ELK-стека, используемого у нас для хранения логов приложений.

Команда технического долга включает в себя бэк- и фронт-разработчиков. В части бэкенда в настоящее время ведутся работы по оптимизации микросервисов, снижения их связанности. Внедряется инструментарий для трассировки, выявления проблемных мест, осуществляется рефакторинг, уделяется внимание повышению стабильности и быстродействия. В части фронтенда (React) выполняется рефакторинг, осуществляется перевод системы на актуальный стек. Одна из основных задач - перейти от самописного State Management на Redux (текущий State Manager передается в качестве параметра через все приложение как глобальный props, из-за чего происходит большое количество ререндеров приложения; переход на Redux избавит от лишних ререндеров, будут реализованы два отдельных слоя: визуализации и хранения данных).

Команда сопровождения и эксплуатации – выполняет поставку релизов, хот-фиксов, осуществляет функцию второй линии поддержки.

Команда управления

Команда управления включает в себя руководителя продукта (Chief Product Owner), ИТ-лидера (IT Lead), менеджера поставки (Delivery Manager) и чаптер-лидов (Chapter Lead). Роль «чаптер-лида» относительно редко встречается в коллективах, поэтому имеет смысл остановиться на ней подробнее, раскрыть назначение в рамках нашей команды.

Чаптер – это определенное направление в команде, вокруг которого объединяются люди со сходными hard-скиллами. У каждого чаптера есть лид, который его фасилитирует, разрабатывает общие подходы, шаблоны, занимается развитием компетенций сотрудников чаптера, организует обмен экспертизой, помогает решать различные проблемы. Когда в коллективе несколько отдельных команд разработки, чаптер-лид, благодаря тому, что находится «над» всеми командами, может лучше оценивать положение вещей, выявлять слабые места, организовывать процесс перехода людей между командами (по необходимости или инициативе сотрудника).   В нашем коллективе следующие чаптер-лиды: бэкенд-разработки, фронтенд-разработки, системного анализа, тестирования и сопровождения. Их функции:

• фасилитация чаптера, активности для повышения продуктивности, тимбилдинг;

• разработка общих подходов, шаблонов, определение критериев готовности (Definition of Ready, Definition of Done);

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

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

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

• мониторинг и контроль психологического комфорта сотрудников (performance review, оценка 360, обратная связь, one-to-one встречи);

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

• взаимодействие с руководящим составом, лидами других чаптеров при возникновении сложностей в команде.

Основные этапы

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

Дадим краткую характеристику некоторым элементам основным элементам схемы:

Бизнес-анализ. Выполняется бизнес-аналитиком при консультациях владельца продукта. Результатом бизнес-анализа являются бизнес-требования (БТ), составленные по определенному шаблону. Шаблон включает в себя: описание решаемой проблемы, эффект от внедрения, описание “as is” и “to be”, сценарии использования, функциональные требования, перечень затрагиваемых систем.

Системный анализ.  Результатом системного анализа, выполняемого на основе БТ, является частное техническое задание (ЧТЗ) на доработку системы, подготовленное системным аналитиком по определенному шаблону. Шаблон включает в себя: концепцию решения, перечень доработок бэкенда и фронтенда. Важными задачами системного анализа являются: а) выявить зависимости и связи с другими компонентами системы, чтобы не допустить некорректного влияния на них; б) обеспечить такой уровень детализация технических требований к дорабатываемым компонентам (сервисам, методам, модели данных, очередям и т.д.), при котором задачу сможет понять и оценить даже новый разработчик команды. 

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

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

Как видно из схемы, кроме разработки итоговых артефактов, важным фактором завершения отдельных этапов является выполнение критериев DoD (Definition of Done). Данные критерии особенно важны для новых сотрудников команды. Они помогают понять, можно ли считать, что задача готова, все ли требования к качеству выполнены. Критерии адаптируются под следующее звено цепочки работ, поэтому содержат не только объективные факторы, но и некоторые субъективные, чтобы лучше соответствовать ожиданиям заинтересованных лиц. Фрагмент наших DoD системного анализа:

1. Бизнес-инициатива проанализирована, проверена на соответствие шаблону БТ. Проведены установочные встречи с бизнес-аналитиком (убеждаемся, что правильно пониманием задачу, подтверждаем ее актуальность). При наличии замечаний, бизнес-аналитик дорабатывает инициативу.

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

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

4. Системный анализ выполнен по шаблону.

Инструментами управления, контролем за статусами, фиксацией результатов этапов являются интегрированные друг с другом: Jira, Confluence, Gitlab, сконфигурированные под наши потребности с использованием различных дополнительных библиотек (в основном распространяемых по лицензиям открытого ПО).

Заключение

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

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

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

3. Следование Agile-манифесту. Выстраиваем процессы и используем тот инструментарий, которые подходят людям. Получаем обратную связь с помощью Agile-мероприятий (ретроспектива), пользовательское тестирование (UAT) и совершенствуемся. Наличие большого количества команд требует процессов, адаптируемых под каждую команду. Сочетаем Скрам (разработка и тестирование) и Канбан (системный и бизнес анализ) для повышения эффективности.

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

5. Стремимся к созданию притягательной, высокой ИТ-культуры: отсутствие бюрократии, доверие к людям, удаленная/офисная работа на выбор сотрудника, мотивация к внедрению нового, возможности роста и поощрения саморазвития, обратная связь и др. Все это способствует набору наиболее квалифицированных сотрудников и их удержанию на проекте.