Как сделать программу для такси

Кейс рассказывает, как с применением продуктового подхода командой 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. При передаче решения команде заказчика необходимо планировать больше времени для совместной работы. В случае с «Везёт» проект передавали на протяжении пары месяцев. Однако конкретный срок необходимой совместной работы зависит от специфики проекта.

Нужно БОЛЬШЕ КЛИЕНТОВ?

Добавьте свою компанию к нам в каталог!

Источник: marketing-tech.ru

Как Создать Приложение для Заказа Такси или Каршеринга

Рынок совместного использования автомобилей (каршеринг) — быстро растущая отрасль мировой экономики. Согласно отчету Allied Market Research, в следующие несколько лет этот рынок будет прибавлять по 12% в год, согласно отчету Zion Market Research — 13,5% в год. Растущая популярность каршеринга также означает рост популярности площадок, которые предлагают эту услугу. В статье мы расскажем, как использовать этот тренд, создав собственное P2P-приложение для проката автомобилей, как Turo.

Шаг 1: Ценностное предложение

Turo уменьшает стоимость проката авто, убирая посредников

1. Для владельцев автотранспорта — получение дополнительного дохода.
2. Для арендаторов (водителей) — прокат авто по демократичной цене.

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

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

В Turo эту проблему решают за счет того, что сервис берет на себя ответственность за полную проверку личности арендатора (и владельца авто также). То есть, если авто украдут, то Turo обязуется возместить его стоимость. Конкурент Turo, приложение Carsharing, требует, чтобы все пользователи регистрировались через социальные сети, используя «живые» аккаунты.

Другие сервисы, к примеру, Drivy не позволяют молодым и / или неопытным водителям арендовать авто на их площадке. При этом практически все подобные приложения, в том числе Turo и Carsharing, используют рейтинговую систему и отзывы для отсеивания неблагонадежных пользователей.

Страхование. Turo предоставляет полис страхования ответственности на 1 млн долларов, который защищает автомобиль от повреждений в течение срока аренды. Подробнее о страховом полисе вы можете узнать на сайте сервиса. Условия страховки указаны в следующей таблице:

Условия страхования на сервисе Turo

Разрабатывая приложение для P2P-аренды авто, вы должны получить лицензию на страховую деятельность или заключить соответствующее соглашение со страховой компанией. В компании RelayRides (первое название Turo) этого не сделали, из-за чего Департамент финансовых услуг штата Нью-Йорк в 2013 году обязал их прекратить деятельность в Нью-Йорке до получения лицензии и оштрафовал на 200 тысяч долларов.

Шаг 2: Бизнес-модель и монетизация

Ключевые детали бизнес-модели P2P-приложения для проката авто

Бизнес-модель. Turo — это peer-to-peer (P2P) площадка по прокату автомобилей. Любой желающий может зарегистрировать свой автомобиль на сервисе, чтобы сдать его в аренду другим участникам платформы. При регистрации автовладелец указывает местоположение, цену и время, когда транспортное средство свободно. Водитель, в свою очередь, резервирует время и оплачивает стоимость аренды владельцу.

Сервис Turo выступает в качестве площадки для встречи сторон и при этом предоставляет некоторые дополнительные услуги (проверка сторон, страхование, доставка автомобиля, администрирование и т.п.) в обмен на 10-35% от стоимости проката в зависимости от уровня страхового покрытия и длительности аренды.

1. При личной встрече. Владельцы автомобилей лично встречаются с водителями-арендаторами, чтобы передать ключи, проверить документы и убедиться, что это реальный человек. Подписание договора и финансовые расчеты в этой схеме могут проходить как на месте, так и через веб-сервис.
2. Онлайн. Turo, Drivy и некоторые другие подобные сервисы нашли безопасные решения, позволяющие передавать авто в руки водителю без необходимости в личной встрече. Это требует дополнительных вложений со стороны владельца транспорта, но затраты обычно быстро окупаются, так как доступ без ключа увеличивает количество сделок ренты.

1. Реклама. Сервис может предоставлять место для баннерной рекламы сторонних сервисов или услуг и продвижения объявлений владельцев авто внутри сервиса (место вверху листинга и рекомендации, более заметное объявление и т.п.).
2. Подписка. Приложение может предоставлять дополнительные услуги в обмен на ежемесячную / ежегодную подписку. К примеру, сервис может ограничить количество объявлений и снять это ограничение за подключение подписки, предоставить услугу GPS-отслеживания, моментального отключения двигателя и прочее.
3. Платные услуги. Сервис может взять на себя доставку авто к водителю-арендатору или возврат его в указанное место после окончания срока ренты. Кроме того, можно взимать дополнительную плату за продление договора ренты или страхование, более глубокую проверку водителей и т.п.
4. Услуги для крупных компаний. Некоторые приложения с возможностью аренды авто вводят специальные подписки / услуги для крупных поставщиков. Например, в приложении LetGo есть подписка LetGo Pro для автодилеров с возможностью получать звонки от покупателей через приложение и автоматическим обновлением листинга.

Шаг 3: Пользовательские роли и функции

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

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

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

1. ) и возможность подать запрос на его бронирование и подтверждение заявки.
2. Подсказки / справка. Короткая экскурсия со всплывающими сообщениями, которая знакомит пользователей с функциями и возможностями приложения при первом запуске или по желанию.
3. Платежная система. Нужна для оплаты ренты, рекламы, подписки и дополнительных услуг. Если финансовые расчеты за аренду проходят через приложение, нужна система взимания комиссионных.
4. Рейтинги и отзывы. Возможность оценить качество автомобиля и отношение владельца авто. Желательно, чтобы ставить оценку и делать отзыв могли лишь те участники, которые взаимодействовали с тем, кого они оценивают.
5. Чат. Обмен сообщениями в реальном времени.

1. м (страна, штат, область, регион, город).
2. Управление платежными шлюзами, платежами и транзакциями.
3. Управление блогами, комментариями, обзорами и рейтингами
4. Управление статическими страницами (о нас, политика конфиденциальности, как это работает, пользовательское соглашение, обратная связь и т.д.)
5. Управление рекламой и пакетами подписки.
6. Отчеты (пользователь, транзакции, отчеты о листингах).

Шаг 4: Дополнительные возможности

Устройство Turo Go позволяет передавать управление автомобилем дистанционно

1. Механизм дистанционной передачи управления автомобилем. Обычно это электронное устройство с идентификатором и механизмом блокировки, который можно разблокировать с помощью специального bluetooth и/или wi-fi сигнала, исходящего из мобильного приложения. Такой механизм устраняет необходимость физического обмена ключами, что сокращает время заключения сделки с 60 до 5 минут.
2. Телематика. Позволяет отслеживать состояние автомобиля на расстоянии и автоматизировать некоторые процессы. Например, можно отслеживать расход топлива, скорость движения, тряску, состояние некоторых приборов, температуру и прочее, а затем использовать эти данные при передаче авто обратно владельцу.

Шаг 5: Разработка MVP

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

• 2 серверных разработчика;
• 1 внешний разработчик;
• 1 Android-разработчик;
• 1 разработчик iOS;
• 1 графический дизайнер;
• 2 QA инженера;
• 1 системный администратор.

• Веб: PHP, .Net, JS и другие.
• Мобильная платформа: Android, iOS.
• Облачная среда: Google, AWS, Azure.
• Push-уведомления: Push.io, Firebase SDK, Twilio.
• SMS, голос и проверка телефона, текстовые сообщения: Twilio, Nexmo.
• Легкая интеграция географических карт: MapKit, Google Maps Platform.
• Отслеживание геолокации в реальном времени: CoreLocation.
• Аналитика: IBM, BigData, Spark, Hadoop, Cisco и Apache Flink.
• Вход через социальные сети: Facebook SDK и Google Sign In.
• Платежи: PayPal, Stripe, EWallets и другие.

Стоимость разработки

Оцените (167 оценки — 4.3 из 5)

Источник: merehead.com

Сервис V.I.P. такси Omcar

Кейс о разработке мобильного приложения для сервиса VIP такси Omcar.

К нам, по рекомендации нашего партнера, обратился Заказчик, с просьбой о разработке мобильного приложения для такси. Приложение для клиента должны быть на платформах Android и iOS. Кроме того также должно быть создано приложение водителя под Android. Диспетчерский кабинет с доступом через web браузер.

Обращу особое внимание, на то, что ни одно такси, за исключением Яндекс Такси и Omcar не реализовано на Я.Картах, а с реализованным нами функционалом клиентской части приложения, даже у самого яндекса…..

Разработка мобильного приложения iOS и Android для клиентов сервиса и приложения Android для водителей. Мобильное приложение для сервиса такси

Заказчик — действующий бизнес по оказанию пассажирских перевозок (такси). Санкт-Петербург.

Ниша: Пассажирские перевозки. Услуги такси (b2c, b2b).

Сторонние сервисы интеграции: Смс-сервис, банковский эквайринг для приема платежей в приложении.

Год реализации: 2019

Срок реализации проекта «под ключ»: 63 рабочих дня. Можно было уложить в 49 рабочих дней.

Задача

Создать мобильное приложение под iOS и Android для существующего бизнеса предоставления автомобилей VIP класса с водителем, для существующих и новых клиентов Заказчика. Данный сервис должен быть не для всех. Данный сервис не должен быть очередным агрегатором такси.

Кроме самих приложений для заказа такси со стороны клиентов Заказчика, создать приложение под управлением ос Android для водителей сервиса. Создать панель администрирования (диспетчерский пункт) для добавления водителей, бухгалтерии, создания заказов, принятых с телефона, а также изменения и добавления новых тарифов для каждого города в отдельности, поскольку г. Санкт-Петербург — отправная точка, точка старта проекта.

В мобильном приложении должны быть три способа оплаты:

Первый — запись стоимости поездки по сотруднику, на организацию, с которой заключен договор оказания услуг .

Второй — оплата самим пассажиром, с помощью банковской карты в приложении.

Третий — оплата наличными пассажиром.

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

Также немаловажными требованиями было:

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

Стартовый экран мобильного приложения

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

Итак, при первом входе мы, по просьбе заказчика, придумали слоган, отвечающий и подчеркивающий статусность.

Далее, на следующем экране, мы предлагаем пользователю авторизоваться, введя код компании, который присваивается при заключении Договора. Т.е. на данном этапе мы отсеиваем не нужных перевозчику «посторонних» клиентов. Данный вид авторизации применяется в трех случаях:

1. Если пользователь запускает приложение в первый раз на своем устройстве.
2. Если пользователь удалял приложение на устройстве, поставил его заново и совершил, по сути, первый вход.
3. Если пользователь в настройках нажал кнопку «Выйти» и тем самым «разлогинился» в приложении .

Если пользователь или его компания, на текущий момент, не является клиентом компании перевозчика, и не имеет Договора на оказание услуг перевозок, то ему предлагается ввести номер телефона для подключения сервиса. Указанный номер приходит в панель администрирования в раздел «Заявки на подключение» и администратор сервиса (или назначенный на эту роль сотрудник перевозчика) связывается с клиентом и объясняет требования для подключения к сервису.

Главный экран мобильного приложения — карта и выбора машины для заказа.

На экране выбора автомобиля для заказа, клиент может видеть, в режиме онлайн все свободные к заказу автомобили.

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

Отображение авто на карте — иконка марки автомобиля и цвет автомобиля.

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

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

Если клиент сервиса нажмет, на интересующую его марку авто, которая доступна для заказа, то он, во всплывающем окне увидит информацию:

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

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

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

Клиент может узнать информацию о том или ином тарифе, выбрав раздел мобильного приложение в боковом слайд — меню «Наши тарифы».

В разделе приложения «Тарифы» пользователь видит информацию и описание того или иного тарифа на поездки, стоимости времени ожидания, а также фото авто класса авто, которые предоставляются на данном тарифе.

В боковом слайд-меню находятся следующие разделы:

• Краткая информация профиля, а именно — миниатюра фото клиента, его номер телефона, принадлежность клиента к компании или частному заказчику. Клацнув в любом месте, в области своего профиля, пользователь перейдет в раздел редактирования своего профиля.
• Мои водители — раздел избранные водители, в который попадают все водители, с которыми состоялась поездка, клиент поставил оценку 5 звезд и подтвердил то, что он хочет добавить данного водителя в список избранных водителей.
• Наши тарифы — подробная информация о тарифах сервиса для различных классов обслуживания.
• Поддержка — форма обратной связи с администрацией сервиса, а также контактные номера телефонов и почта.
• Политика конфиденциальности — стандартная политика, требуемая законодателеьством России.
• FAQ — раздел вопрос-ответ с динамичным поиском и возможностью добавления распространенных вопросов и ответов в данный раздел из панели администрирования.

Оформление заказа в приложении.

Заказ автомобиля в приложении происходит достаточно просто.

1. На главном экране (карте) выбирается или конкретный автомобиль или просто нажимается кнопка «Заказать».
2. Далее указать адрес подачи автомобиля, дату и время подачи. Время выделено не просто так, а по причине того, что минимальное время подачи составляет 35 минут. Также можно указать конкретное время подачи (но не менее 35 мину), в этом случае заказ будет считаться предварительным. Водитель взявший такой заказ будет считаться занятым, с момента «за 45 минут» до времени подачи автомобиля клиенту. Выбрать адрес назначения или же указать, ч то маршрут свободный. Выбрать вариант оплаты — по договору или наличные (в т.ч. оплата картой). Добавить комментарий если требуется, например «Захватите мне кофе латте по дороге» (и водитель его действительно заедет, купит и привезет клиенту).
3. Уточнение места подачи автомобиля на карте, на случай если требуется его уточнить и кнопки быстрого ввода адреса — «Аэропорты» и «Вокзалы», через которые можно указать откуда поедет клиент, если необходимо забрать с вокзала или аэропорта.
4. Увидеть все заполненные поля и нажать кнопку «Подтвердить»
5. После того как заказ принят системой, клиент видит сообщение о том, что заказ принят системой ии происходит поиск автомобиля.
6. После успешно найденного автомобиля клиент увидит его в своих заказах

Ожидание подачи автомобиля или текущий заказ

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

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

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

1. Нажав на автомобиль.
2. Перейдя в текущий заказа через меню — текущие заказы — заказ.

Экран приложения «текущий заказ» имеет следующий функционал:

• Подача машины — указаны когда (дата и время) и когда (адрес) подачи машины
• Информация о водителе — миниатюра фото водителя, фамилия имя отчество водителя и дата его рождения.
• Кнопки связи — копка «карта» — показывает текущие местоположение подаваемого автомобиля. И кнопка иконка «Позвонить» — связь с водителем по телефону. Стоит особо отметить тот факт, ч то связь идет через сервер ip телефонии в целях сокрытия номера клиента от водителя. Конфиденциальность во всем.
• Информация о подаваемом автомобиле — марка, государственный регистрационный знак.
• Фотографии — галерея фотографий подаваемого автомобиля.

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

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

После поездки, и при следующем входе в приложение клиент видит модальное окно с просьбой оценки качества поездки, автомобиля и водителя, отвечая на несколько вопросов.

Мобильное приложение для водителей такси

Мобильное приложение для водителей такси. На этапе постановки задачи, требовалось реализовать только под Android.

Вход и авторизация водителя в приложении.

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

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

Получение заказа

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

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

Когда появляется новый заказ, то водитель видит информацию о нем, а именно:

• Информацию о клиенте
• Вид оплаты
• Место и время подачи автомобиля
• Адрес конечного пункта
• Комментарий к заказу, если он есть.
• Если выбрали именно данного водителя, то в поле оплата стоит двойная сумма подачи авто + значок, информирующий, что конкретно его заказал клиент.

После того, как водитель принял заказ у него появляется возможность проложить маршрут до клиента в приложении.

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

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

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

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

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

Сухие итоги по разработке проекта

Создали классный проект. Переделали его несколько раз по прихоти заказчика. Ушли от основной задумки и концепции. Пришли к обычному и очередному агрегатору такси. Предоставили рассрочку.

Отработали проект в минус. Пытаемся получить остаток денег через суд.

Хороший проект, давший нам отличный опыт как правильно нужно работать с заказчиками.

Общий срок разработки проекта составил 65 рабочих дней

В рамках работы над проектом мы реализовали:

• Клиентское приложение — мобильное приложение под iOS и Android
• Приложение водителя — мобильное приложение под Android
• Back-end (сервер)
• Панель администрирования и диспетчерский пункт — web/ react native
• Подключены смс сервис, банковский эквайринг и интегрированы я.карты

Стек разработки мобильного приложения

Разработка приложения iOS — swift, objective C

Разработка приложения Android — Kotlin

Разработка серверной части приложения — node js

Разработка web панели администрирования — react native, css

Создание дизайна — Sketch, Figma

Команда разработки

Менеджер проекта — 1 чел

Разработчик iOS — 2 чел

Разработчик Android — 2 чел.

Back end разработчик (Серверная часть) — 2 чел

Front end разработчик (верстка web) — 1 чел

Дизайнер-проектировщик — 1 чел.

Тестировщик — 1 чел + вся команда

Общее время разработки мобильного приложения: от заключения Договора, до готовности приложения к публикации в Google Play (Android) и AppStore (iOS), согласно изначального и согласованного технического задания составило 2 месяца или 47 рабочих дня.

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

Источник: app-labs.ru