Изображение предоставлено red_mad_robot с сайта https://redmadrobot.ru

Мобильное приложение для такси, учитывающее региональную специфику 

 

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

Особенности кейса: Общая команда заказчика и разработчика 1,5 года тестировала по стране различные фичи, чтобы сделать сервис максимально удобным для пользователя. 

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

Команда проекта: Над проектом работала совместная команда разработчика и заказчика. В нее вошли: 

• от red_mad_robot: бизнес-аналитик, два iOS-разработчика, два Android-разработчика, менеджер продукта, три дизайнера, два QA-инженера. 

• от заказчика: менеджер продукта, дизайнер, продуктовый аналитик, два backend-разработчика.

После передачи приложения инхаус его развитием занимается команда, состоящая из менеджера по продукту, двух дизайнеров, семи разработчиков (два — iOS, два — Android, три — backend) и двух QA-инженеров.

 

Заказчик и бэкграунд проекта 

Эта история началась пять лет назад, во время объединения усилий агрегаторов такси Fasten и RuTaxi, когда появилась компания «Везёт», ставшая одной из крупнейших в регионах и работавшая в малых городах, куда не выходили Uber и Yandex со своими сервисами такси. 

Сервис «Везёт» охватывал 120 городов. Их жители заказывали до полутора миллионов поездок в сутки. Для сравнения, за сутки на «Яндекс.Такси» приходилось примерно 750 тысяч заказов, а Uber обслуживал порядка 160 тысяч клиентов.  

Несмотря на то что после объединения «Везёт» стал обладателем сразу пяти мобильных приложений, восемь из десяти пользователей сервиса заказывали такси по телефону. 

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

Когда я вызываю такси в приложении, могу не вбивать адрес вручную, а подтвердить геолокацию, которую сервис определяет автоматически. Этого не было в старом приложении «Рутакси», — директор по продукту «Везёт» Анатолий Кульбацкий.

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

Разработчикам предстояло создать принципиально новый программный продукт уровня Gett, «Яндекс.Такси» и Uber, который оказался бы лучше существующих приложений «Везёт» по основным продуктовым метрикам и равен им по конверсиям. Последнее считалось бы свидетельством успешности нового проекта. 

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

 

Процесс работы над проектом 

 

В связи с реорганизаций IT-отдела заказчика, первую версию для Android команда red_mad_robot делала самостоятельно. 

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

Условно в работе над проектом можно выделить четыре этапа:

1. Выпуск двух стартовых версий приложения, который занял шесть месяцев.
2. Апгрейд и тестирование нового функционала продолжались четыре месяца.
3. Работа вместе с заказчиком по передаче дел и компетенций длилась два месяца.
4. Еще два месяца понадобилось на передачу и развитие приложения.  

После выхода Android-версии к проекту присоединились специалисты заказчика и началась работа над созданием продукта для iOS. Совместная команда разработчика и заказчика закончили создание iOS-приложения за 2,5 месяца.

По окончании работ провели первое сравнение нового сервиса «Везёт» со старым «Рутакси».

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

• где чаще заказывают, 
• какое количество поездок приходится на одного нового пользователя. 

Консервативный «Рутакси» оказался более востребован у пользователей. Он лидировал по конверсиям в первую поездку, а также по числу поездок на нового клиента.

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

После сравнения старого и нового сервиса разработчики: 

1. Собрали список метрик, а затем, при внедрении всех улучшений, ориентировались на их повышение.  
2. Приняли решение делать больше прототипов и запускать их в тестирование до начала разработки. 
3. Помимо тестов прототипов, стали проверять гипотезы, исследуя пользовательскую реакцию на их воплощение.

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

 

Поиск проблем и создание фич для их решения 

В процессе проектирования разработчики ознакомились с 23 приложениями для заказа такси. Среди них были отечественные и зарубежные сервисы, в частности Lyft, Grab, а также другие продукты, разработанные во Франции, США и Азии.

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

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

Затем команда перешла к изучению потребностей пользователей «Везёт». Чтобы описать устоявшийся сценарий заказа такси через диспетчера, разработчики многократно вызывали такси в различных городах.

Представители red_mad_robot поделились с MarketingTECH своими воспоминаниями. Рассказываем интересные подробности. 

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

• Десяток раз был получен отказ при вызове такси для клиента с большой собакой.

• В большинстве случаев сотрудник не успевал задать вопрос о собаке или поинтересоваться тарифом. Диспетчер спрашивал начальную и конечную точку маршрута, информировал о принятии заказа и отключался. 

• Беседа с оператором, в зависимости от города, длилась 22–32 секунды. Соответственно, вызов такси через приложение должен был занимать такое же время или быть быстрее.

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

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

Составив бэклог рабочих задач, расположенных в порядке приоритетов для разработки, совместная команда red_mad_robo и «Везёт» взялась за дело. 

 

Проблема №1. Низкоскоростной интернет

В небольших городах интернет работает медленно, а значительная часть целевой аудитории «Везёт» пользуется бюджетными смартфонами на Android. Эти устройства работают медленно и «не тянут» тяжелые приложения. 

Чтобы решить проблему, новый сервис «Везёт» для Android должен быть легким. Разработчики создали приложение, которое весило 5 МБ. Оно не забивало память телефонов и загружалось быстро. Особенно по сравнению с приложениями «Яндекс.Такси», весившим 90 МБ, и Uber на 170 МБ.

 

Проблема №2. Карты с низкой детализацией и «белыми пятнами» 

Разработчики отказались от применения «Яндекс.Карт», а в «Google Картах» не было подробных и свежих карт для некоторых небольших городов. 

Решением этой проблемы стала разная степень детализации карты в зависимости от города. Разработчики использовали сразу три картографических сервиса: «2ГИС», OpenStreetMap и «Google Карты». 

Сценарий заказа такси приобрел еще один экран, куда можно было ввести номер подъезда или какой-либо ориентир.

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

Проблема №3. Такси может подъезжать долго  

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

Изучив статистику, команда red_mad_robot пришла к выводу, что существенная доля отказов от поездки происходила уже после заказа такси. 

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

• идет поиск машины, 
• такси уже едет,
• показывается время, оставшееся до прибытия,
• машина скоро подъедет.   

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

Проблема №4. Пользователи не хотят привязывать карту 

Не у всех водителей есть карта «Сбера», на которую можно перечислять деньги по номеру телефона. 

Но есть категория пользователей, которым удобно оплачивать с помощью сервиса «Сбербанк Онлайн». Они не настраивают автоматический платеж через привязку банковской карты к приложению. 

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

Кроме того, разработчики позаботились о корпоративных клиентах. Некоторые компании используют «Везёт», чтобы отправить персонал домой после работы в ночную смену. Для B2B-клиентов в сервисе предусмотрена оплата корпоративными картами. Для этого нужно указать номер карты, пароль и работников — пассажиров. 

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

 

Бизнес-показатели и А/Б-тесты как основная движущая сила улучшений 

Гипотезы об эффективности отдельных элементов сервиса проверялись на контрольных группах путем A/Б-тестирования. Например, таким способом разработчики определяли оптимальный дизайн главного экрана и способы оплаты. 

Для red_mad_robot приложение «Везёт» стало одним из первых, в котором можно было полноценно применить продуктовый подход — клиентская база позволяла делать тесты. Разработчикам не нужно было предполагать, какой из вариантов будет работать лучше, они проверяли с помощью А/Б- и даже А/Б/В-тестирования. 

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

Проверка гипотез осуществлялась по следующим критериям: 

• возможность реализации,
• цена внедрения,
• полезность,
• возможность последующего развития. 

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

 

Примеры того, как разработчики тестировали элементы продукта  

 

Основной экран 

Целый месяц проводился тест с главным экраном. Выбирали из двух вариантов. 

• карта, похожая на ту, которую выводит «Яндекс.Такси»,
• поисковая строка для ввода адреса. 

Для Android-версии продукта по итогам тестирования победила карта. 

 

Способ авторизации 

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

1. Большая часть участников команды думала, что пользователь сначала вызывает такси и во время заказа регистрируется. 
2. Клиент сначала авторизуется и только после этого заказывает такси.

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

 

Информирование о времени ожидания машины

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

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

 

Интеграция с аэроэкспрессом 

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

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

 Клиент может понять, когда из-за пробок проще доехать на такси до аэроэкспресса, а не до аэропорта.

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

 

Результаты тестов и финал работы над проектом  

Почти год прошел с момента запуска проекта, когда разработчики еще раз сравнили свой новый сервиссо старым фаворитом «Рутакси». 

По результатам тестирования было выявлено:

1. «Везёт» показывает лучшие результаты на привлеченном трафике. Из тестов исключили органические охваты, поскольку у нового сервиса их было недостаточно для создания релевантных выборок.
2. По конверсии новый сервис обошел старый на пять процентных пунктов, хотя при первом сравнении он уступал «старейшине» шесть процентных пунктов. Этот рывок занял чуть больше трех месяцев. 

Разработчики начали передачу сервиса инхаус-команде «Везёт» примерно за четыре-пять месяцев до момента завершения проекта. В это время специалисты red_mad_robot и заказчика представляли собой единую команду. Они собирались на общих встречах, делали планинги, общались через чаты и формировали задачи в Jira.

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

Приложение «Везёт» было передано под контроль IT-специалистов заказчика в конце 2018 года. С момента завершения работ его метрики росли. Через приложение обслуживались более миллиона клиентов в месяц — миллиона пользователей сервис достиг в июле 2019-го, а за год до этого их было всего сто тысяч.

Другие сервисы группы компаний «Везёт», в том числе «Рутакси», продолжили свое существование. Однако заказчик рассчитывал в первую очередь на новый сервис и занимался его развитием.

 

Выводы и рекомендации по итогам проекта   

1. Обязательно нужно проводить А/Б или А/Б/В-тесты. При создании «Везёт» экспериментами занималась команда из сотрудников разработчика и заказчика. Так, в порядке вещей были «коридорные» тесты дизайнеров, когда они покидали кабинеты и шли показывать макеты сотрудникам других отделов для получения обратной связи. 
2. Хорошее решение можно получить, только погрузившись в проект, изучив контекст его применения различными типами клиентов. В проекте «Везет» это было сделано при помощи тестов на привлеченном трафике. Благодаря этому во время экспериментов можно было не подвергать заказчика рискам потери аудитории и обойтись без ухудшения бизнес-показателей.  
3. Разработчик не должен чувствовать себя аутсорсером. Гораздо эффективнее будет, если он займет позицию партнера. Это позволит выйти за рамки технического задания, а не работать в рамках модели: ТЗ получил — ТЗ исполнил. 
4. Важное значение имеет контакт с заказчиком, совместный поиск багов, придумывание интересных решений, их совместное тестирование. 
5. При передаче решения команде заказчика необходимо планировать больше времени для совместной работы. В случае с «Везёт» проект передавали на протяжении пары месяцев. Однако конкретный срок необходимой совместной работы зависит от специфики проекта.