АльфаCтрахование Мобайл. Как мы объединили несколько ИТ-систем в одном приложении: кейс
Практически все в нашей жизни — будь то здоровье, имущество или турпоездка — может быть застраховано. Более сотни страховых продуктов с индивидуальными процессами по оформлению страховых случаев и возмещению убытков, а также — несколько ИТ-систем. Это ровно то, что мы увидели, когда начали работать над проектом сервисного мобильного приложения «АльфаСтрахование Мобайл». Суть приложения сводилась к нетривиальной задаче объединить все страховые продукты и процессы «АльфаСтрахование» — сделать для мобильного пользователя единый канал коммуникации со страховой компанией на все случаи жизни.
Примем как аксиому, что клиентам нужен мобильный доступ к страховым сервисам. Дальше теоретически есть два варианта: иметь несколько отдельных приложений по каждому виду страхования или все-таки делать единое приложение для управления всеми полисами. Первый вариант более простой с точки зрения разработки, второй — значительно сложнее, но куда удобнее для пользователя. Мы пошли вторым путем.
История нашего взаимодействия с компанией «АльфаСтрахование» получилась нестандартная. Сначала мы встретились на конференции, поговорили, отправили предложение — проекта не последовало, но макет остался. Тут надо сказать, что мы любим публиковать фотографии рабочего процесса в соцсетях и как-то разместили в Facebook фотографию. На мониторе нашего арт-директора в общем-то случайно оказалась большая буква «α».
И вдруг в «АльфаСтрахование» отреагировали — классная фотка! Что вы такое рисуете? — и после этого все закрутилось. Спасибо, Facebook:)
Александр Прокопчук, директор департамента электронной коммерции в компании «АльфаСтрахование»
«Прежде всего, нам было принципиально важно досконально разобраться: зачем вообще страховой компании и ее клиентам нужно мобильное приложение. Мы серьезно подошли к проработке этого вопроса, проводили исследования и фокус-группы, в результате которых выяснилось, что клиенты в первую очередь ждут от приложения не возможность удобно купить полис (хотя и ее, конечно, тоже), а видят в нем инструмент, который помогает справиться с экстренными ситуациями и в целом облегчает работу со всеми страховыми продуктами. Наша цель — быть лидирующей страховой компанией по уровню сервиса, и мобильное приложение один из важнейших инструментов в достижении этой цели».
На момент старта проекта у нас имелся опыт создания страхового приложения для выезжающих за рубеж. Фактически там был только один сценарий, и это уже было непросто, здесь же сценариев оказалось намного больше.
Артур Сахаров (mc_murphy), технический директор Redmadrobot
«Если сегодня вы соберетесь делать банковское приложение, то увидите, что заказчики обозначают свои требования так: «Сделайте нам, как у Тинькофф Банка, Открытия или Сбербанка». Если нужно написать приложение для аренды автомобиля, можно изучить зарубежный опыт. Увы, в страховании таких бенчмарков на российском рынке не было, а западный опыт оказался нерелевантен из-за различий в законодательной базе».
Поэтому все бизнес-кейсы разрабатывались нами самостоятельно с нуля. Мы составили Feature List — собрали самый полный список функциональности с оглядкой на цели бизнеса и пользователей. Но поскольку нам не хотелось делать из приложения «сборную солянку», каждая фича-кандидат на реализацию проходила серьезный отбор. Каждый раз мы спрашивали себя, сможет ли внедрение той или иной функции решить бизнес-задачи или действительно ли ее наличие сделает приложение более полезным для пользователя. В итоге у нас получился куда более краткий список, с которым мы начали работать.
Татьяна Анисимова, бизнес-аналитик Redmadrobot
«На старте перед нами стояло несколько задач. Важнейшие из них: дать пользователю доступ ко всем страховым продуктам в едином профиле, упростить оформление страхового случая и сделать процесс урегулирования убытка прозрачным. Приложение получило детально продуманный Q&A, подробный чек-лист к каждому страховому случаю и широкий спектр электронных услуг, которые можно получить прямо через mobile. Это возможность записаться ко врачу или вызвать его на дом, оформить заявление о страховом случае и активировать страховые продукты прямо через приложение».
Функционал приложения:
• Экстренная связь со страховой компанией через кнопку SOS (звонок оператору; заказ обратного звонка; IP-телефония при вызове из-за рубежа);
• Дистанционное урегулирование убытка по КАСКО и полису страхования пассажиров;
• Запись в медицинские клиники и вызов врача на дом;
• Офисы страховой компании на карте и списком;
• Активация коробочных продуктов;
• Подробная инструкция с планом действий при наступлении страхового случая;
• Список действующих полисов;
• Покупка и пролонгация полисов.
Из появившихся благодаря приложению электронных услуг особо хочется отметить самую популярную: урегулирование убытка по КАСКО.
Прямо из приложения клиент «АльфаСтрахование» может оформить заявление на возмещение убытка, сфотографировать место ДТП, повреждения (чтобы исключить риск мошенничества, когда фотографии делаются не в то время и не в том месте, где произошло ДТП, допускается только съемка непосредственно из приложения, просто взять и загрузить фотографии нельзя), справки из ГИБДД и тут же отправить на рассмотрение в страховую компанию. Заявление сформируется в электронном виде, и «АльфаСтрахование» тут же начнет процедуру урегулирования.
Универсальный сценарий для всех страховых продуктов в приложении выглядит следующим образом:
• Наступает страховой случай;
• Пользователь нажимает кнопку SOS;
• Выбирает тип полиса и целевое действие (звонок оператору, обратный звонок, просмотр инструкции; составление заявления о страховом случае прямо через приложение);
• Получает оповещения о ходе рассмотрения дела и дальнейших действиях через PUSH-уведомления.
Звонок или заказ обратного звонка
Варианты действий после нажатия на кнопку SOS отличаются в зависимости от типа страхового продукта. Изначально мы планировали «захардкодить» разные сценарии для разных полисов, но в итоге поступили иначе — добавили в спецификацию переменный параметр, и теперь от middleware нам приходит набор «SOS activities», который вычисляется в зависимости от имеющихся у пользователя активных полисов. При добавлении других сценариев в будущем (например, если появится возможность оформить страховой случай через приложение по новым типам полисов) для отображения их функций на экране глобальных изменений в структуру кода вносить не потребуется. Просто для новых страховых продуктов будет приходить дополнительный параметр в методе с middleware.
Middleware мы разработали для интеграции разных ИТ-систем, в которых живут страховые продукты компании «АльфаСтрахование». Нужно было продумывать, из каких систем что брать, некоторые данные дублировались и приходилось решать, что будет для нас источником. Из-за ограничений — во внутренних системах (допустим, обнаруживалось, что мы не можем делать запрос синхронно на сервер, так как обновление информации происходит раз в сутки, и сервер просто не даст нам актуальных данных); в законодательстве и других областях некоторые сценарии пришлось переделывать по несколько раз, начиная с требований и заканчивая реализацией.
Егор Тафланиди (BepTep), архитектор Redmadrobot
«Обычно мы сами пишем спецификацию API, следуя которой потом будут взаимодействовать фронты с сервером middleware или системами заказчика. Соблюдая идеологию REST, мы шаблонизировали подобного рода документацию и используем её из проекта в проект. Направление серверной разработки у нас в компании пока молодое, но наши бэкэндщики уже сделали для себя собственный фреймворк, который используют для разработки промежуточного слоя, и в дальнейшем интеграция будет проходить очень-очень быстро».
Также в ходе проектирования мы должны были учесть ряд ограничений:
1. Логика даже похожих страховых продуктов довольно сильно различается (например, оформление ДТП по КАСКО и ОСАГО). В итоге нельзя было просто взять и внести в одну общую сущность много мелких, часто приходилось реализовывать похожие, но немного отличающиеся элементы в разных страховых продуктах.
2. Нужно было добиться минимального расхода заряда батареи за счет минимального использования антенны для передачи данных — в критической ситуации страхового случая пользователь меньше всего ждет того, что страховое приложение «убьет» его смартфон.
3. Асимметрия GSM-трафика: скорость отправки и получения данных в мобильных сетях серьезно различается. Мобильные устройства быстро получают данные и очень долго их отдают. Поэтому когда пользователь видит индикатор выполнения действия, то большая часть времени ожидания тратится на отправку данных на сервер.
Егор Тафланиди, архитектор Redmadrobot
«Работая над архитектурой приложения, мы думали о том, что пользователи могут оказаться в ситуации ограниченного доступа в интернет, например, в роуминге. При первом запуске загружается весь объём данных. В итоге часть функционала приложения доступна вообще без интернета, а пользователь в принципе не видит индикаторов загрузки. При необходимости информация обновляется в фоновом режиме.
При проектировании «АльфаСтрахование Мобайл» мы исходили из best practices. Если полис содержит поле для центров техобслуживания, то обычно приложения делают два запроса — загружая сам полис и список центров с идентификаторами. Мы пошли другим путем, предусмотрев своеобразный «оффлайн-режим» работы — приложение скачивает максимум данных, которые могут пригодиться в будущем, что позволяет использовать его даже без подключения к сети. Все запросы выстреливают при старте в оптимальном порядке».
В ходе проекта мы попробовали некоторые новшества, например, библиотеку ReactiveCocoa, которую многие разработчики используют в модной парадигме функционального реактивного программирования, и нам тоже было интересно.
Роман Чуркин (firmach), ведущий iOS-разработчик Redmadrobot
«Было решено использовать связку из паттерна MVVM и библиотеки ReactiveCocoa. Дело в том, что при использовании паттерна MVVM приходится решать задачу привязки данных View Model и реакции на изменение этих данных к их отображению на View. Именно для реализации таких связок была использована ReactiveCocoa. Это позволило избежать раздутого KVO синтаксиса. Мы попробовали, сделали определенные выводы и пока будем применять Reactive Cocoa аккуратно, чтобы по минимуму зависеть от такой громоздкой библиотеки. Не исключено, что в будущем мы откажемся от нее в пользу альтернативных решений».
Также на этом проекте мы начали вводить в использование Swift. Часть проекта уже написана на нем, эта практика будет развиваться, мы планируем использовать Swift более широко. Хотя Apple выпустила Swift еще год назад, мы не спешили на него переходить. Фактически начали писать на Swift версии 1.2, уже зная ожидаемый срок релиза версии 2.0, чтобы выпустить приложение сразу на новой версии — это была задача, которую мы решили хорошо, судя по нулевому количеству крэшей у пользователей.
Мы также активно применяли практику повторного использования кода — это позволило сократить время разработки и повысить надежность. Среди использованных повторно модулей, к примеру, была авторизация через Touch ID.
Кроме того, в ходе разработки мы уделяли большое внимание соблюдению лучших практик и стандартов безопасности. Меры защиты в «АльфаСтрахование Мобайл» базируются на подходах, которые мы применяем в банковских приложениях, а это достаточно высокая планка: начиная с банального SSL-pinning’a — и заканчивая защитой от подключения отладчика. Приложение будет максимально сопротивляться запуску на jailbreak- и root-устройствах.
«АльфаСтрахование Мобайл» — не кроссплатформенное решение, а две отдельные нативные разработки под iOS и Android. При схожих функциональных требованиях в iOS и Android разные UX-паттерны и шаблоны.
Нам пришлось немного поплясать с бубнами, чтобы адаптировать приложение под Android 6 и интегрировать в него новую гугловскую permission-модель.
Максим Ефимов (MaximEfimov), руководитель группы Android-разработки Redmadrobot
«В отличие от Android 5, с выходом Android 6 приложение по умолчанию ничего не просит, а запрашивает доступ только в тот момент, когда ему надо. Пользователь может зайти в настройки и выключить разрешение, которое он дал раньше. Это хорошо с точки зрения UX в плане работы со смартфоном в целом, но с точки зрения легкости поддержки для программистов очень неудобно. Спустя пару недель после обновления весь GitHub был буквально забит Android Permission-библиотеками. Мы тоже сделали свою библиотеку, которая интегрирована в наш собственный фреймворк».
Первый прототип приложения мы сделали еще под iOS7 — с тех пор мобильная операционная система Apple пережила два крупных обновления. Вот как выглядела карта экранов в первой версии:
Андрей Лисицын, арт-директор Redmadrobot
«То, что в итоге воплотилось в реальном приложении, от этого прототипа серьезно отличается, хотя некоторые родовые черты сохранились. Одна из них — крупная кнопка SOS с анимацией, которая раскрывается на весь экран, заливая все вокруг красным. При загрузке геолокации для индикатора поиска пользователя мы придумали изображение спутника и сет веселых иконок, некоторые из них рисовались буквально с натуры :)»
В профиле клиента была идея разместить дополнительную полезную информацию вроде группы крови, а также добавить оповещение близких пользователя после экстренного звонка. Прототип был подготовлен не только под iOS, но и под Android и Windows Phone. Для мобильной платформы Microsoft мы даже сделали темную версию, потому что исторически у WinPhone была возможность менять цветовую палитру всей оси, да и вообще смотрелось это довольно брутально, по-роботовски.
Теперь о том, что получилось в итоге. Приступая к проектированию навигации, мы планировали использовать tab bar, как рекомендует в своих гайдлайнах Apple, но еще на уровне wireframes поняли, что главный экран получается слишком перегруженным, и на этом фоне теряется основной интерфейсный элемент — кнопка SOS.
Кнопка SOS доступна всегда, даже в неавторизованном режиме. В процессе регистрации или до ее начала уже можно позвонить в страховую компанию. Так как центровой элемент интерфейса — крупная кнопка SOS — не вписывалась в стандартный таббар, мы сохранили важные блоки функционала на главном экране (кнопка SOS, статусы и уведомления по страховым случаям, просмотр полисов со сроками действия и покупка новых полисов), а все остальное перенесли в меню (профиль пользователя, офисы, информация о приложении).
Сергей Гальцев, ведущий дизайнер Redmadrobot
«В конце первой презентации дизайна заказчику мы вставили ролик с парашютистами, которые прыгали со скалы, и вбросили тезис, что испытывать юзабилити приложения мы будем в свободном падении, чтобы парашютист мог пройти сценарий запроса помощи, пока не раскрылся парашют. И мы действительно это сделали».
Первичные запросы заказчика по части дизайна претерпели ряд существенных изменений в процессе обсуждения и работы над проектом. Например, в части подачи контента и навигации: от идеи давать информацию разворачивающимся списком — обычный такой подход из мира корпоративного ПО — мы отказались. Это нормально работает в веб-среде, но не в мобильном приложении, здесь необходимы отдельные экраны с продуманной системой переходов.
В приложении есть некоторое количество анимаций, при создании которых мы опробовали инструмент для прототипирования Pixate, об этом можно почитать в одной из наших недавних статей. И подробнее о том, как создавался дизайн приложения — в кейсе на Behance.
Написано 88679 cтрок кода;
Отрисовано 850+ экранов и 100+ иконок;
2 версии iOS успели выйти за время подготовки проекта;
С 4000 метров прыгали 2 парашютиста, которые тестировали приложение;
В ходе работы ни один разработчик или дизайнер не пострадал.
За первые четыре месяца у iOS-приложения «АльфаСтрахование Мобайл» уже более 28 тысяч установок, у Android-версии более 33 тысяч. Статистика показывает, что это очень стабильное приложение — количество крашей на iOS не превышает 0,5%. По количеству исходного кода это самый крупный наш проект. «АльфаСтрахование Мобайл» равняется полутора приложениям «Мой Билайн», двум «Мобильным Банкам Открытие» и пяти приложениям Safe Trip (Ренессанс страхование).
Так мы делали «АльфаСтрахование Мобайл». Надеемся, что для коллег приложение сможет послужить тем самым примером, которого нам самим так недоставало на старте проекта. Сейчас приложение доступно в AppStore и Google Play, работает на смартфонах под iOS 8+ и Android 4.4+. Само собой, у нас есть внушительный бэклог задач по улучшению и большое количество гипотез, как именно эти улучшения реализовать. Мы работаем по системе Agile, и релизы с обогащением приложения интерфейсными решениями и функциональностью идут каждые две недели. И, конечно, мы открыты к критике и предложениям — ими можно поделиться в комментариях. На этом все, спасибо за внимание!
