Эта история началась, как ни банально, с тендера.

«Абсолют страхование» готовилась подписать контракт на ДМС стоимостью почти миллиард. Но потенциальный клиент, крупнейшая нефтесервисная компания, обозначил одним из обязательных условий сделки наличие удобного мобильного личного кабинета для владельцев полисов.
На тот момент у «Абсолют страхования» было довольно общее видение функциональности приложения и жесткие сроки будущего контракта. Компания объявила закрытый тендер среди топовых компаний мобильной разработки, отобранных по личным рекомендациям. Приложение нужно было сделать безупречно и быстро. Ну все как обычно.

К первой встрече мы максимально включились в проект: изучили задачи заказчика, создали прототипы дизайна и продумали логику всего приложения. Коллеги из «Абсолют Страхования» были приятно удивлены — такого объема проделанной работы и глубины погружения никто не ждал.

Мы выиграли тендер, пожали друг другу руки и понеслось!

Аналитика, ТЗ, требования: как мы готовились к продакшену

Работы мы начали с создания ТЗ. К этому моменту мы уже провели предпроектную аналитику, и первоначальный список требований расширился и детализировался.

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

После изучения ИТ-инфраструктуры заказчика стало понятно, что нужно не просто мобильное приложение, а программный комплекс, включающий также

● единую точку входа для мобильного приложения в виде серверной части

● административную панель для настройки контента

● интеграцию со многими сторонними сервисами текущей инфраструктуры компании

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

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

Разработка: параллельный подход

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

Проект имел жесткие сроки: от старта разработки и до оговоренной даты релиза у нас было всего 6 месяцев. За это время нужно было отрисовать дизайн, сделать бэкенд, два мобильных приложения и опубликовать их в магазинах Google и Apple.

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

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

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

Чтобы реализовать функциональность качественно и без потери времени, мобильные разработчики должны получить:

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

2. Работоспособное API со стороны сервера

3. Описание задачи.

Техническое задание на продукт мы описали заранее, поэтому с постановкой задач перед командами разработчиков вопросов не возникало.

Оставалось проработать вопросы дизайна и серверного API.


Начнем с дизайна!

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

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

В приложении «Абсолют Страхование.Здоровье» ошибки отображаются в общем дизайне.

Заказчик очень внимательно принимал работы по дизайну и активно предоставлял нам обратную связь. Нам удалось гармонично вписаться в существующий брендбук компании, согласовать дизайн с основными стейкхолдерами — и при этом сохранить, пусть с доработками, свою изначальную концепцию. Более подробно ознакомиться с дизайном можно на behance.

Бэкенд: командная работа и новые сервисы

Для работы над серверной частью мы пригласили коллег из Fusionsoft — у нас уже есть опыт совместной работы над большими проектами. Также на этом этапе работы нам пришлось плотно сотрудничать с командой заказчика.

Основная сложность заключалась в том, что мы фактически интегрировались с корпоративной информационно-аналитической системой «Абсолют Страхования». Это коробочное решение, и в ряде случаев кастомизировать его компоненты было невозможно. В помощь нашей команде активно привлекались разработчики и аналитики со стороны заказчика — они помогали нам с интеграцией.

Для бэкенда были разработаны следующие модули и сервисы:

1. Сервис взаимодействия с информационной системой заказчика, система очередей — для синхронизации и обновления данных.

2. Уникальная система фильтрации API-запросов — позволяет гибко передавать параметры-значения моделей и получать необходимые данные.

3. Сервис для работы с DaData — он помогает получить информацию о расстоянии между текущим местоположением человека и координатами ближайших клиник.

4. Удобная система для работы с API-запросами в Swagger.

5. Механизм push-уведомлений — напоминает пользователю приложения о том, что нужно подтвердить оказанные клиникой услуги или пройти предложенный компанией опрос.

6. Механизм email-оповещений операторов ДМС о результатах различных опросов застрахованных.

Финальный шаг: сдача проекта

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

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

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

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