Кейс продуктовой команды «Везёт»: как мы сделали дистанционный фотоосмотр в такси
Привет! Меня зовут Дмитрий Поташников, я продакт-менеджер в ГК “Везёт” (сервис заказа такси). Ранее мои коллеги уже писали про MVP и о том, как устроен наш продуктовый процесс. В этой статье я расскажу, как это работает на практике, на примере создания сервиса дистанционного фотоосмотра в водительском приложении.
Что такое фотоосмотр и зачем мы решили его делать?
Вызывая такси, мы все рассчитываем, что к нам приедет самый лучший автомобиль. Ну ладно, пусть не лучший, но точно целый и чистый. Для этого сервис заказа такси регулярно контролирует состояние автомобилей, которые выходят на линию.
В каждом городе присутствия у сервиса “Везёт” есть офисы, куда регулярно приезжают водители для показа автомобиля. Команда водительского приложения решила пересмотреть этот процесс и реализовала дистанционный фотоосмотр, в котором водитель отправляет фото автомобиля через мобильное приложение, а менеджер на основе фото проверяет:
соответствует ли автомобиль тому, который указан в системе;
есть ли на автомобиле обязательные для такси обозначения (например, шашки на крыше и на крыльях), а также фирменная оклейка сервиса;
- соответствует ли автомобиль требованиям сервиса (отсутствие повреждений и наклеек сервисов-конкурентов).
Фотоосмотр стал важнейшим шагом в реализации стратегии цифровой трансформации процессов и улучшил работу операционных подразделений компании.
Исходные условия и требования
100+ городов по всей РФ: сервис должен корректно работать для 100% водителей в любом городе.
Должна быть возможность постепенного внедрения фотоосмотра среди водителей, чтобы не допустить недостатка водителей на линии.
- 2 отдельные платформы ПО (мы рассказывали о нашем наследии в статье Redmadrobot): единый сервис должен работать с обеими платформами.
Прежде чем приступить к реализации, мы рассмотрели фотоосмотр с точки зрения метрик и их влияния на бизнес компании:
количество офисов и задействованных в них сотрудников: операционные затраты могут быть снижены за счет применения технологий;
- время, которое водители тратят на проведение регулярного осмотра в офисе с учетом дороги: чем больше времени водитель проводит на линии, тем больше заказов он выполняет;
- повторные заказы пассажиров: качество и состояние автопарка напрямую влияет на клиентский опыт и безопасность поездок.
Первый шаг: этап исследования (Discovery)
Мы провели тестирование в 2-х городах, чтобы убедиться, что процесс фотоосмотра приживется в “Везёт” и принесет пользу. Тест совпал с началом изоляции: за 1 день был сделан бот в “Телеграм”, с помощью которого водители отправляли фото автомобиля, а менеджеры смотрели их через платформу “Юздеск”. Согласно плановому базовому качеству время ожидания ответа не должно было превышать 1 час, на практике обращения обрабатывались в среднем за 10 минут.
Мы рассказали водителям о телеграм-боте с помощью PUSH-уведомлений, и в течение недели 80% перевозчиков, получивших сообщения, успели воспользоваться им.
Проанализировав результаты, мы перешли ко второму этапу.
Проектирование (Define)
Проектирование началось с разбора текущего процесса. Я обратился к менеджерам наших офисов в нескольких городах и сформировал историю “AS IS”, где была описана последовательность действий водителя и менеджера.
На основе текущего процесса, пожеланий и просмотра аналогов была сформулирована первая версия продукта и ее поэтапное улучшение. Каждый этап последовательно улучшал предыдущую версию продукта и повышал базовое качество.
Для записи истории, разбитой на этапы, я использовал Google Sheets:
столбцы – это итерации проекта;
верхняя часть строк – описание выборки, объем доработок, цель и базовое качество;
- нижняя часть строк – описание последовательных шагов процесса (цветом выделено изменение по сравнению с предыдущей итерацией).
Для передачи требований команде разработки было сформировано итоговое описание, охватившее несколько итераций (для этого используем Confluence) и подготовлены макеты интерфейсов. Это дает возможность сразу проектировать систему с заделом на будущее.
Разработка (Develop)
Состав команды:
1 backend-разработчик
- 1 Android-разработчик
- 1 frontend-разработчик
- 2 тестировщика
- 1 дизайнер
- 1 продакт-менеджер
Для разработки первой версии были приняты следующие ограничения:
- 3 города на одной платформе ПО;
- только Android;
- единые настройки для всех городов.
Разработка в себя включала:
- серверную часть – логика и базы данных;
- сборка водительского приложения Android – новые экраны и взаимодействие с сервером;
- изменения в “админке” – новый раздел “Фотоосмотр”.
Реализация первой версии заняла 2 спринта (1 месяц). Далее начался этап Delivery, а команда инженеров занялась подготовкой к подключению фотоосмотра ко второй платформе ПО.
Тестовый запуск регулярного фотоосмотра (Delivery)
Успешность прохождения фотоосмотра влияет на возможность выхода водителя на линию, следовательно, любая техническая ошибка приведет к снижению доступных автомобилей для пассажиров. Для минимизации этого риска регулярный фотоосмотр запускался постепенно в течение недели, в 3-х городах. Отдел обучения подготовил видео-инструкцию для водителей, а для менеджеров провели инструктаж.
Для контроля метрик функциональности мы использовали:
Amplitude
Отчет по базовому качеству на основе выгрузки из БД
Результаты запуска первой версии фотоосмотра
фактическое базовое качество: 80% фотоосмотров проводилось в течение 1 часа, вместо запланированных 2-х;
более 80% водителей сделали корректные ракурсы фото;
- была выявлена и в последствии устранена проблема в сжатии фото, которая ухудшала качество полученных изображений, в результате чего менеджеры не могли принять решение и водителям необходимо было пройти фотоосмотр еще раз;
- были выявлены 15 моделей смартфонов, на которых водители не могли пройти фотоосмотр – это составило около 12% от всего парка устройств (перед масштабированием эта проблема была устранена);
- получили от менеджеров обратную связь по интерфейсу рассмотрения фотоосмотров и сформировали перечень планируемых доработок.
Вторая версия продукта
Состав версии:
- подключение второй платформы ПО для запуска на следующих 4-х городах;
- гибкие настройки проведения фотоосмотра для каждого города, поскольку требования к автомобилям могут отличаться в зависимости от ситуации в регионе;
- возможность добавления новых ракурсов, чтобы настраивать фотоосмотр для контроля салона и состояния отдельных частей автомобиля;
- уведомление менеджеров через бота в “Телеграм” о появлении новых фотоосмотров для снижения времени рассмотрения;
- единый интерфейс проведения фотоосмотра, работающий с обеими платформами для экономии ресурсов разработки и тех.поддержки.
Запустив вторую версию, мы убедились, что единый процесс может работать с обеими платформами ПО, а благодаря уведомлениям, базовое качество продукта возросло 90% осмотров стали проводиться в течение 15 минут.
Развитие фотоосмотра заключается в его масштабировании и оптимизации. Для этого мы готовим:
привлечение аутсорса (внешних исполнителей) для проведения фотоосмотров при масштабировании на случай, когда своих операционных ресурсов не хватает;распознавание гос.номера – оптимизация времени проведения фотоосмотра;
- распознавание гос.номера – оптимизация времени проведения фотоосмотра;
- контроль загрузки дубликатов – борьба с фродом.
Фотоосмотр станет неотъемлемой частью процесса дистанционной регистрации водителей без визитов в офис, что позволит быстрее привлекать новых перевозчиков и еще больше снизит нагрузку на офис.
Также на базе фотоосмотра мы планируем провести эксперимент по влиянию состояния автопарка на retention пассажиров.
Выводы (промежуточные)
- Проведение фотоосмотра для менеджера требует в 10 раз меньше времени, чем при очном осмотре в офисе. Таким образом, при тех же ресурсах компания контролирует состояние автопарка гораздо эффективнее.
- Более 90% водителей отметили, что прохождение фотоосмотра гораздо удобнее и требует меньше времени, чем визит в офис.
Методологии запуска новых продуктов не просто теория – она работает, позволяя создавать “космолет” частями в короткие сроки.
Самоизоляция послужила катализатором активных действий, а благодаря устоявшемуся продуктовому процессу, MVP фотоосмотра был реализован всего за 2 месяца.
Нужен еще фотоотчет салона делать, чтобы там без ковров всяких...
Он уже есть. Для прохождения фотоосмотра водители делают и отправляют фото заднего сидения.
Вроде во всех такси уже такое есть. Яндекс Такси кажется уже года 3 просит фотоотчеты. У вас 3 года отставание ребята, надо что-то предпринимать.
1 backend-разработчик ...грустно)
Уже более 10-ти лет в в офисах "Везёт" проводится очный осмотр автомобилей, сейчас мы оцифровываем этот процесс.
У нас нет повода для грусти, в статье указан состав только части команды, которая работала именно на этом проекте. Это далеко не все ресурсы компании.
Ну по оцифровке вы отстаете на 3 года, так лучше?)
Ну зачем вы так открыто врете, тут же не только пассажиры но и водители сидят) Работаю с везет с 2016 года, регистрировал в системе 5 машины разных годов выпуска и марок. Ни разу не проводился очный осмотр.
Скажите, возможно вы знаете кто отвечает за работу приложения, почему когда оно свернуто и ты на линии, тебе приходит заказ, но он не выскакивает на экран как это было раньше. Такая проблема существует у многих моих знакомых, на разных телефонах, разных операторах и в разное время суток.
К кому можно обратиться?
В любом процессе могут быть ошибки. Если вы ни разу не проходили очный осмотр - это точечная недоработка менеджеров офиса. Именно поэтому вводится дистанционный фотоосмотр, чтобы снизить влияние человеческого фактора при контроле всех автомобилей.
С вопросом по приложению в будущем вы можете обращаться в поддержку или в офис. По конкретному вопросу подскажу - вам необходимо дать приложению разрешение на отображение окон поверх других используемых приложений: Настройки -> Приложения -> выбрать приложение (TAXI) -> «Разрешить отображать поверх», либо « Всегда сверху», либо «Отображение поверх других приложений» (название зависит от модели телефона) -> включить галочку.
Дистанционный осмотр был пол года назад, он был один раз за все это время. Я понимаю что вы гордитесь своим делом и работой, но между вами и реальностью огромная пропасть. На самом деле все работает по другому. Недоработка менеджеров офиса это самое мало что происходит) Низкие тарифы убивают весь сервис и качество, низкие зарплаты менеджеров офиса тоже не способствуют его повышению)
Спасибо за совет на счет всплывающих окно)!
Комментарий недоступен
Комментарий недоступен
Фотоосмотр как может определить что автомобиль действительно данного водителя , возможно ведь смена гос номеров либо других махинации , как быть в таком случае , если только верить по фотоосмотру
Как правило, обман происходит с целью получения приоритета за брендирование, которого на самом деле нет. Выявлять такие случаи можно как с помощью фотоосмотра (требование определенных ракурсов, внеплановый осмотр и т.д.), так и с помощью других инструментов ("тайный покупатель", например).
Борьба с фродом - это целое направление нашей деятельности, мои коллеги недавно рассказали как это происходит в отношении поездок https://habr.com/ru/post/512752/
Спасибо за ответ , но водители умудряются сейчас и Яндекс такси обмануть при фотоконтроле , хотя и Яндекс не дремлет и борются с этим но не могут
Так же была новость что Яндекс.Такси хочет купит Везет , система там ваша понадобиться ли , просто антимонопольная служба отклоняет эту сделку
Сейчас уже AI проверяет нормально косяки по кузову меньше чем за минуту, тем более с таким кейсом в 100+ городов, а у вас до сих пор люди в 1 час, сильно нечем гордиться, как мне кажется
Применение AI в этом проекте - вопрос для будущих итераций. В любом случае для обучения потребуется массив размеченных фотоосмотров. На текущий момент мы сделали необходимое, чтобы база данных начала формироваться, а у водителей появилось больше времени на выполнение заказов. Статья как раз про то, как сделать большое по частям, не забывая о целях и метриках.
«НаличиНе брендированиЕ конкурента».... в команду ещё нужен редактор)
Ян, благодарю за пристальное изучение макета (а в статье именно макет из фигмы). Вы правы, в нем допущена ошибка, но до пользователей она не дошла - у нас и разработчик грамотный, и тестирование за этим смотрит, и на демо такие недочеты выявляет вся команда.
Очень сухо и по-деловому, как отчет начальнику. Фе.