Что должно быть на главном экране приложения для вызова такси — карта города (как у «Яндекс.Такси») или адресная строка? В какой момент новый клиент должен регистрироваться — когда только скачал приложение или в процессе первого заказа? И какой сценарий больше подойдет жителю Пензы, который привык звонить в диспетчерскую, а вовсе не пользоваться приложением?
red_mad_robot и ИТ-команда компании «Везёт» рассказывают о том, как им удалось создать приложение, используя продуктовый подход. А потом, преодолев все сложности, передать его для дальнейшей разработки инхаус.
Предыстория
В 2017 году агрегаторы Fasten и RuTaxi объединились и образовали группу компаний «Везёт» — она стала крупнейшим игроком в российских регионах, в том числе в небольших городах, где про «Яндекс.Такси» и Uber никто не слышал.
В то время услугами «Везёт» пользовались жители 120 российских городов, а количество заказов, сделанных через оператора, достигало 1,5 млн в сутки (для сравнения: у «Яндекс.Такси» их было вдвое меньше, а у Uber — около 160 тысяч в сутки). 80% пользователей сервиса привыкли вызывать такси по телефону.
При этом у группы компаний «Везёт» в результате слияния появилось пять мобильных приложений. У самого популярного из них — «Рутакси» — было более 2 млн пользователей в месяц.
Но с момента выхода первого релиза прошло уже шесть лет — его дизайн и возможности устарели. За это время разработчики не выпускали значительных обновлений, а на рынок вышли Gett, «Яндекс.Такси» и Uber с новыми, современными решениями.
Когда я вызываю такси в приложении, могу не вбивать адрес вручную, а подтвердить геолокацию, которую сервис определяет автоматически.
Этого не было в старом приложении «Рутакси». Еще не было описания тарифов, сохраненных маршрутов, расчёта времени — сколько ехать от точки А в точку Б.
Опции вроде «детское кресло» или «поездка с питомцем» были «закопаны», и пользователи не заморачивались с поиском.
Совместная команда «Везёт» и red_mad_robot должна была спроектировать и поставить на поток разработку нового приложения — современного и понятного.
Переделывать старое не было смысла: мы собирались внедрять много новых фич, каждую из них надо было протестировать, а проверка неудачной гипотезы могла бы привести к оттоку клиентов и потерям для бизнеса.
Наш продукт должен был стать лучше других приложений группы компаний «Везёт» по основным продуктовым метрикам и сравняться с ними по основным конверсиям. Это стало бы главным критерием успешности проекта.
При этом нашей целью было не обойти текущее популярное приложение, а добиться того, чтобы пассажиры, привыкшие звонить диспетчеру, перешли бы на мобильный сервис — заказ такси через приложение дешевле для компании, чем оператор.
Процесс пошёл
Проект стартовал в июле 2017 года. Чтобы как следует разобраться в том, как устроены сервисные приложения «Везёт», мы решили посмотреть на них со стороны.
Команда проанализировала, как работают существующие приложения, приняла во внимание данные о бизнесе и устройство популярных сервисов конкурентов и спроектировали новый, нестандартный сервис. Оставалось протестировать его вместе с командой «Везёт», внести изменения по результатам тестов и передать проект клиенту.
Однако оказалось, что у «Везёт» как раз меняется ИТ-отдел — прежние сотрудники передавали дела новым, которые только начинали осваиваться на работе. Прямо скажем, не лучшая ситуация, чтобы передать проект инхаус.
Поэтому первое приложение для Android мы делали самостоятельно, а обновленная команда «Везёт» полноценно подключилась на стадии разработки версии для iOS.
Всю работу можно разбить на три этапа:
Выпуск первых версий приложения: ноябрь 2017 — апрель 2018.
Улучшение и тестирование новых функций: май 2018 — август 2018.
Совместная работа с передачей компетенций и дел: сентябрь 2018 — октябрь 2018.
Передача и развитие приложения: ноябрь 2018 — декабрь 2018.
Итак, после того как в ноябре 2017 года вышло Android-приложение, мы вместе с разработчиками «Везёт» начали работу над iOS-версией.
Конечно, процесс требовал взаимной «притирки» — на налаживание ушло около двух с половиной месяцев. К апрелю 2018 года мы закончили iOS-версию, а уже в мае впервые сравнили новый сервис «Везёт» со старым приложением «Рутакси».
Мы купили по 3000 пользователей на каждое приложение и посмотрели на значимые показатели — где люди больше заказывают, сколько поездок приходится на нового клиента.
Старый сервис «Рутакси» при всей его несовременности был лучше для пользователей по конверсиям в первую поездку и по количеству поездок на нового пользователя. Но мы были к этому готовы и через сравнение искали слабые места в новом продукте. Определив их, мы расписали новый подход к разработке.
Вот что мы сделали после сравнения приложений.
Сформировали перечень метрик. Далее все фичи — то есть всё, что клиент видит в приложении, — внедрялись под их рост.
Решили делать больше прототипов и тестировать их до разработки.
А также проверить гипотезы с помощью экспериментов на пользователях приложений.
«Везёт» начали нанимать в команду необходимых людей под проект — от продуктового аналитика до backend-инженеров для реализации микросервисов под мобильное приложение.
Как мы искали проблемы и находили решения
На этапе проектирования мы просмотрели 23 российских и зарубежных приложения для заказа такси: Lyft, Grab и другие сервисы, сделанные во Франции, США, азиатских странах.
Дизайнеры и аналитики изучили функции в этих приложениях и попробовали разные сценарии заказа такси. В процессе подготовки мы составили список фич для пользователей, которые понравились нам и «Везёт» и могли повлиять на наши метрики. Теперь можно было проверять их на локальной аудитории.
После этого начали изучать потребности пользователей «Везёт». Чтобы понять привычный сценарий вызова такси по телефону, мы множество раз заказали такси в разных городах.
Несколько раз мы пробовали говорить с операторами на английском языке, но те пугались и бросали трубку. И 10 раз пытались заказать такси для пассажира с большой собакой — во всех случаях получили отказ.
Чаще я не успевал рассказать легенду про собаку или спросить о тарифе — оператор спрашивал, откуда и куда я поеду, говорил, что заказ принят, и отключался. Этот диалог занимал в разных городах от 22 до 32 секунд.
В дальнейшем мы ориентировались на это время — в приложении заказ такси должен был занимать столько же времени или меньше.
В конце этого этапа у нас появился список основных трудностей при заказе такси в небольших городах. Мы придумали решения каждой из выявившихся проблем — теперь предстояло протестировать их вместе с «Везёт». Сформировав бэклог и определив приоритетность задач, мы начали делать приложение.
Проблема: медленный интернет
В регионах медленный Интернет и большая доля бюджетных смартфонов на платформе Android, которые медленно работают и не справляются с тяжелыми приложениями.
Решение: новое приложение «Везёт» для Android — легкое: оно весит 5 МБ. Это позволяет не засорять память смартфонов и сделать процесс загрузки быстрым. Для сравнения: приложение «Яндекс.Такси» весит 90 МБ, а Uber — 170 МБ.
Проблема: отсутствие подробных карт
Для некоторых небольших городов не существует подробных актуальных карт Google (мы не стали использовать карты Яндекса).
Решение: в разных городах пользователю показываются разные карты в зависимости от степени детализации. Поэтому мы использовали три сервиса с картами: OpenStreetMap, Google Maps и «2ГИС». В сценарии заказа появился дополнительный экран, где можно указать номер подъезда или другой ориентир.
Интересно, что в небольшом городе ориентиром может быть магазин «Карина» или хлебозавод. На картах Google нет таких точек, но любой водитель понимает, где забрать пассажира.
Проблема: долгое ожидание
В небольших городах люди ждут такси дольше, чем в Москве или крупном мегаполисе. На 100–200 тысяч жителей приходится относительно мало машин. Мы изучили статистику и поняли, что большой процент отказов от поездки происходил уже после оформления заказа.
Решение: сделать процесс ожидания интересным. Чтобы клиент не думал, что о нем забыли, мы создали живой интерфейс. Пользователь видит, что происходит и на какой стадии его заказ: идет поиск такси, водитель уже едет, осталось столько-то времени, он скоро будет на месте.
Кроме того, важно было привлечь внимание клиента на этапе поиска автомобиля. Мы показывали дорогу с машинами, которые едут рядом, и плашку со словами «пожалуйста, подождите ещё немного».
Проблема: клиенты не привязывают карты
Некоторые клиенты не привязывают банковскую карту в приложении для автоматической оплаты, а хотят переводить деньги через «Сбербанк Онлайн».
Но иногда у водителя нет карты «Сбербанка», привязанной к номеру телефона.
Решение: разрабатывая приложение, мы добавили такую опцию. Вызывая такси, пользователь может выбрать оплату с помощью сервиса «Сбербанк Онлайн»: в этом случае к нему приедет водитель с картой «Сбербанка», на которую можно будет перевести деньги за поездку.
Еще сервисом пользуются компании, чтобы развести своих сотрудников по домам после ночной смены. Для таких клиентов в приложении есть возможность оплатить поездку с помощью корпоративной карты, указав ее номер, пароль, имена сотрудников.
При оформлении карты менеджеры могут задать ограничения. Есть корпоративные карты, которые работают только по будням или только по выходным, там может быть указан фиксированный адрес отправления или имена конкретных пассажиров.
Улучшения через бизнес-показатели и A/Б-тестирование
Многие элементы приложения — дизайн главной страницы, способы оплаты и прочие — мы выбирали с помощью A/Б-тестов. A/Б-тестирование — это проверка гипотез на контрольных равноценных группах.
Это один из первых проектов, где мы в полной мере смогли использовать продуктовый подход: база пользователей позволяла проводить тестирования.
Мы не предполагали, какой вариант лучше, а постоянно проводили А/Б- или А/Б/В-тестирования. Эксперименты стояли во главе угла, и всё строилось вокруг них. Гипотезы мы часто строили во время командных брейнстормов, где были арт-директор, дизайнер, аналитик, разработчики и тестировщики со стороны роботов и «Везёт».
Обсуждали цифры конверсии, смотрели на графики и генерировали идеи — какие фичи внедрить или переделать, чтобы уменьшить «отвалы» аудитории.
Проверяли гипотезы с точки зрения реализуемости, стоимости внедрения, полезности и возможности дальнейшего развития. Из этого получался бэклог.
Кстати, мы внутри команды роботов еженедельно делали рассылку дайджеста продукта, где рассказывали о том, как меняются показатели в проекте.
Примеры тестов, которые мы проводили
Главный экран
В течение месяца мы тестировали два варианта главного экрана. Часть команды считала, что лучше вывести карту (как у «Яндекс.Такси»), другая была за поисковую строку, в которую вбивается адрес. В результате тестов в Android-приложении победил экран с картой.
Авторизация
С помощью теста мы выбирали способ авторизации — когда пользователь должен регистрироваться в приложении. Большинство членов команды считало, что пассажир должен заказать такси и зарегистрироваться в процессе заказа.
Но был и второй вариант: пользователь сначала должен авторизоваться, а уже потом заказать такси. И тесты показали, что именно второй, неожиданный для нас вариант, эффективнее в метриках продукта.
Время ожидания
Мы расходились во мнении о том, нужно ли показывать пользователю время ожидания машины. Как правило, оно составляет 3–5 минут, но есть регионы, где мало машин и (или) плохие дороги, там ожидание такси любой службы может занять 15 минут.
Не отпугнет ли клиента то, что он будет видеть время в таком случае? Оказалось, что нет: в результате тестирования победил вариант с плашкой, где человек видит, через какое время приедет машина. Конверсия в завершенную поездку была выше на 1,5 процентных пункта.
Аэроэкспресс
Одна интересная идея в итоге не вошла в приложение. Мы придумали интеграцию с аэроэкспрессом. Когда заказываешь такси в аэропорт, сервис предлагает разные варианты поездки с учетом времени и цены. Например, поездка от дома до Шереметьево займет столько-то минут и будет стоить такую-то сумму.
А поездка до аэроэкспресса и на нём в аэропорт — столько-то. Если вы видите, что из-за пробок проще вызвать такси не в аэропорт, а до аэроэкспресса, можно выбрать этот вариант. В итоге мы разработали MVP, работавшее корректно, но через несколько месяцев выяснилось, что его выбирает слишком небольшое количество пользователей. Если клиент пришел заказывать такси, он чаще всего хочет добраться в аэропорт именно на авто.
Какой результат дали эксперименты
Повторное сравнение приложений «Везёт» и «Рутакси» мы провели в сентябре 2018 года — спустя почти год после старта проекта. Тест показал, что новое приложение лучше старого на привлеченном трафике (на тестовой выборке мы убирали органический трафик, в новом сервисе его не хватало, чтобы собрать релевантные выборки).
В мае приложение «Рутакси» обгоняло по конверсии новое приложение «Везёт» с разницей в 6 процентных пунктов, а в сентябре уже «Везёт» обошло «Рутакси» на 5 процентных пунктов.
Как закончился проект
Мы начали передавать приложение «Везёт» за 4–5 месяцев до окончания проекта. В этот период мы по сути были одной командой: ходили на общие встречи, составляли совместно планинги, переписывались в чатах, составляли задачи в Jira.
На заключительном этапе проекта мы продолжали полевые исследования. Например, мы вызывали такси через сервис «Везёт» в Москве, Санкт-Петербурге, Пензе и Тольятти, чтобы проследить, как работает сценарий, не падает ли приложение, корректно ли отображается информация
В декабре 2018 года приложение полностью перешло под контроль ИТ-команды «Везёт». С момента завершения работы над проектом и до сих пор метрики продолжают расти.
Сейчас приложением пользуются более миллиона пользователей в месяц — черту в миллион клиентов сервис перешагнул в июле 2019 года. Для сравнения: в июне 2018 года было 100 тысяч.
Другие приложения ГК «Везёт» по-прежнему существуют, в том числе «Рутакси». Но ставка делается на нашу общую разработку — именно ее развитием занимается новая команда.
Боевая команда
Со стороны red_mad_robot — старший дизайнер, менеджер по продукту, бизнес-аналитик, два iOS-разработчика и два Android-разработчика, два дизайнера, два QA-тестировщика.
Со стороны «Везёт» — менеджер по продукту, дизайнер, продуктовый аналитик, два backend-разработчика.
Сейчас развитием приложения занимается следующая команда: один менеджер по продукту, два дизайнера, два iOS-разработчика и два Android-разработчика, три бэкенд-разработчика и два QA-тестировщика.
Капитанства из проекта
А/Б- или А/Б/В-тестирования — это мастхэв. В наши эксперименты были вовлечены обе команды. Например, дизайнеры делали «коридорные» тестирования, то есть выходили из кабинетов с макетами, показывали их сотрудникам, собирали обратную связь.
Без погружения в особенности продукта и контекст его использования (в том числе в привязке к разным типам пользователей) нельзя получить хорошее решение.
Таким хорошим решением стало тестирование на привлеченном трафике. Это позволило нам не рисковать аудиторией и не ронять бизнес-показатели.
Нужно определять себя не как аутсорсеров, а как партнеров — выходить за рамки технического задания и модели работы «я принял ТЗ и сделал по ТЗ». Важно быть в постоянном контакте, чтобы вместе искать баги, придумывать решения и тестировать их совместно.
При передаче дел во внутреннюю команду нужно закладывать больше времени на совместную работу. В нашем случае двух месяцев хватало, но все зависит от сложности проекта.
Приложение «Везёт» доступно в в App Store и Google Play.