Как интегрировать сервисы страховых компаний

Смотрите, у вас есть автомобиль, вы хотите приобрести полис ОСАГО. Как узнать, какая страховая компания предложит наиболее выгодное предложение по вашим параметрам? Для этого надо воспользоваться сервисом Banki.ru, который собирает информацию с нескольких страховых компаний и выдает результаты для сравнения.

Чтобы получать расчеты из разных источников, необходимо с ними интегрироваться. Мы, команда Nord Clan, и реализовывали интеграцию Banki.ru с рядом страховых компаний: Zetta, Согласие, Верна, Либерти Страхование, Астро-Волга, Абсолют Страхование, Югория, Гайде и др.

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

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

Со стороны разработки это также на первый взгляд не вызывает вопросов:

• запрос документации API
• подготовка ТЗ
• разработка интеграции
• подготовка тестовых данных
• тестирование
• техподдержка при релизе

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

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

Нужно учитывать, что на скорость коммуникации будут влиять внешние факторы:

• разные часовые пояса (даже разница всего в 1 час между Ульяновском и Москвой заметна);
• загруженность представителей страховых компаний локальными задачами;
• использование неэффективных каналов взаимодействия (переписка в нескольких мессенджерах или только при помощи e-mail);
• ожидание согласования начала разработки между заказчиком и страховой компанией (открытый API может изучаться, но переход к техническим этапам должен происходить после заключения договора и NDA).

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

Чтобы убедиться, что запросы работают так, как описано в документации API, мы прогоняли процесс получения полиса от начала до конца с помощью Postman и SoapUI. Это помогло выявить разного рода ошибки:

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

Ох уж эти правочки

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

Чек-лист для аналитика

• Получить контакты специалистов со стороны менеджмента и разработки страховых компаний, оговорить удобный всем формат и время коммуникаций;
• Узнать, какие внутренние справочники есть в системе заказчика, и какие из них используются при формировании запроса на полис ОСАГО;
• Запросить у страховой компании нужные справочники;
• Узнать, как должны обрабатываться данные от страховой компании на стороне banki.ru (в нашем случае использовались статусы и из ответных запросов сохранялась лишь часть данных);
• Оговорить с заказчиком формат ТЗ. Если у заказчика есть шаблон, то необходимо изучить его заранее, до того, как начнете писать новое ТЗ.

Если углубиться в сам адаптер, то процесс покупки полиса в каждой страховой компании содержал до 10 различных запросов. Мы разделили их на три группы. Первая группа отвечала за проверку данных водителя и предварительный расчет. Вторая — за подтверждение выбора полиса и окончательный расчет. Третья группа — за оплату полиса.

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

В процессе работы мы применяли подход TDD (Test Driven Development) в виду того, что актуальный стенд для разработчиков с релевантными данными был один и мы не могли тестировать на нем отдельно каждую нашу интеграционную часть. То есть мы сначала писали тесты, используя модуль camel-test, а потом уже сам код.

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

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

Иногда даже при наличии необходимой информации могут возникнуть сложности. У нас был набор данных для авторизации в сервисе страховой компании. Но были какие-то проблемы с API, поэтому чтобы протестировать разработанный код необходимо было каждый день использовать разные параметры для авторизации на тестовом стенде: ежедневно мы пробовали разные комбинации данных, причем иногда срабатывали и те, которые предназначались для боевого стенда.

ПП — правильный подход

Каждая страховая имеет уникальный набор технологий и данных. Разработчики подходили к реализации задач индивидуально, учитывая специфику API. Например, одна страховая использовала стиль взаимодействия REST, другая — SOAP-протоколы, но архитектура решения позволяла легко управлять этим многообразием. Или у одной страховой компании было заложено 30 минут на подсчет стоимости полиса. Для этого кейса мы разработали логику, которая периодически опрашивала внешний сервис на предмет готовности расчета, отправляла его на почту заказчику или по истечению определенного времени отменяла запрос.

Нельзя так просто взять и закрыть задачу

После успешного завершения этапа тестирования разработчики загружали код на стенд Banki.ru, откуда уже производилась его внедрение на рабочий сайт. При необходимости наша команда подключалась к решению вопросов: аналитик консультировал команду нашего клиента по нюансам ТЗ и особенностям API, разработчики оперативно адаптировали интеграции под реалии боевой инфраструктуры, специалисты по качеству прогоняли тесты на стендах, а менеджер проектов оперативно решал все вопросы, которые неизбежно возникают при приемки результата и запуске продукта в эксплуатацию.

Чек-лист для разработчика

• Основываясь на ТЗ, отослать все запросы через Postman или SOAP UI на тестовый стенд страховой компании;
• Если есть вопросы, то обсудить совместно с аналитиком. По необходимости подключиться к общению со страховой компанией для выяснения требований;
• Перед началом реализации убедиться в работоспособности стенда для разработки;
• Реализовать необходимую функциональность, по методологии TDD (с использованием тестов).

Ты не пройдешь!

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

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

Чек-лист специалиста по качеству

• Подключиться к тестовому стенду страховой компании и уточнить возможные ограничения.
• Узнать следующее:
  - Возможно ли провести оплату на тестовом стенде;
  - К какому стенду РСА (тестовому или рабочему) обращается тестовый стенд страховой компании;
  - Есть ли у страховой компании готовый набор тестовых данных (если нет, надо подготовить свой);
  - Технические уточнения (IP white-list, особенности авторизации и запросов и т.д.).

Как и любой другой специалист команды, менеджер проекта (PM) присутствует на любом этапе процесса разработки. Но именно присутствие РМ делает разработку проекта продуктивнее, т.к. в основном вся коммуникация проходит через нас.

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

Помимо этого PM отвечает за бюджет и сроки разработки. Чтобы уложиться в согласованные показатели, мы брали в работу интеграции параллельно. Пока команда была занята реализацией интеграцией одной страховой компании, я узнавала информацию о другой. Таким образом, когда первый процесс приостановился, можно начинать второй. В результате такого распределения нагрузки нам удалось построить непрерывное течение разработки.

Чек-лист менеджера проекта

• Создать канал связи с представителями заказчика и страховой компании;

• Договориться с заказчиком об удобном формате и времени коммуникации;
• Убедиться, что у всех членов команды есть доступы в необходимые внутренние сервисы заказчика;
  
• Определить необходимую частоту созвонов внутри команды;
  
• Составить список данных, которые нужны от страховой компании для старта разработки;
  
• Ежедневно актуализировать статус задач для каждой страховой компании.
  

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