Развитие онлайн-диспетчерской такси
ЗаказчикСибирская служба такси, пользующаяся готовым программным комплексом для организации перевозок.ЗадачаОформить хотелки клиента в ТЗ, придумать решения и реализовать.
Крупные операторы такси постепенно захватывают рынок. Во многих сибирских городах они пока еще не зашли. Но клиент отслеживает ситуацию в других городах и понимает, что если условный яндекс зайдет на территорию, то ему придется туго. Поэтому решил действовать на предупреждение. Чем могут конкурировать такси, кроме стоимости поездки? Сервисом.
У клиента был ряд идей для улучшения сервиса, которые не предоставлялись программным комплексом. К сожалению, первая команда, к которой он обратился, не справилась с задачей. Обратились к знакомому — где взять толковых прогеров на проект? И ему порекомендовали нас.
Задача №1 — форма заказа такси на сайте
? Проблема
Разработчики комплекса предлагали для использования на сайте только такой вариант: два поля для ввода адресов и кнопка «заказать». Как стандартная форма заявки. Что-то типа этого:
Так же думали предыдущие разработчики, на чем и завалились. Мы, в ходе детального обсуждения, выяснили массу неочевидных моментов. По факту подразумевалось небольшое веб-приложение, в котором будет:
- поиск,
- отложенные заказы,
- отслеживание заказа на карте,
- использование бонусов,
- дополнительные опции
- и прочее.
Этого не было в программном комплексе такси в API. Программный комплекс предлагал:
- сервер,
- приложение водителя,
- приложение клиента,
- диспетчерская и т.д.
При всем богатстве предлагаемого функционала не было возможности прикрутить готовый подходящий вариант. Клиентам сильно не хватало этого функционала.
Все это можно реализовать с помощью API. Но API-функции дают отдельные кусочки, а уже из этих кусочков надо собрать саму логику. Помимо прочего, нужно параллельно отображать динамически все изменения. И не только, дело в том что некоторые функции реализованные нами вообще отсутствуют в стандартном API. Пришлось изрядно попотеть.
? Решение
Пришлось спроектировать это веб-приложение — сценарий использования не совсем простой. Не просто «забил адрес 1, забил адрес 2».
- Во-первых, это зависимость от городов, поиск заказа как должен работать, то что должны назначаться определенные экипажи в разных городах, разные цены в разных городах.
- Во-вторых, получается 2 экрана состояния — когда ты только заказываешь машину и когда уже нажал на кнопку «поиск машины», то уже другой экран — все параметры заказа выводятся, тут же в реальном времени выводится:
- Машина назначена — тебе надо подтвердить что ты увидел уведомление.
- Машина подъезжает, водитель у себя нажимает кнопку «я на месте».
- На сайте тут же появляется уведомление о том, что машина уже на месте, подтверждаешь что уже выходишь.
- При чем, это должно работать хоть после закрытия вкладки и заново зайти на сайт, хоть сразу несколько вкладок — информация о заказе должна быть одна и та же. Чтобы с одного устройства нельзя было случайно сделать несколько заказов или потерять заказ, закрыв браузер. Должно быть актуальное состояние заказа.
- Так же добавили аутентификацию по номеру телефона и подключили бонусы.
Задача №2 — Подключить онлайн-оплату
? Проблема
Чтобы повысить лояльность водителей, решили немного упростить им жизнь.
- Основное неудобство водителям доставляло пополнение счета через терминалы типа «Киви». Учитывая то что на условный сибирский город подобных аппаратов в среднем всего 2 штуки — такое себе удовольствие. Да и зачем, если можно принимать платежи онлайн?
- Комиссия. Если пользоваться решениями комплекса, то от платежа процент сначала забирал себе платежный шлюз, и потом еще сам комплекс. Получалось весьма не выгодно.
? Решение
Для этого мы сделали интеграцию с платежным шлюзом напрямую через API — у водителей появилась возможность пополнять лицевой счет через сайт, не выходя из автомобиля. И снизились комиссионные издержки.
Задача №3 — такси-бот
? Проблема
Далее продолжили работать с клиентом — подкинули нам еще один незавершенный проект. На этот раз это был такси-бот. Разобрались что уже есть, что хотели, что можем сделать. Подразумевалось, что бот нужен не только для Telegram, но и для Вк. А также с перспективой подключения всех мессенджеров, с которыми бота реально подружить.
Почему нужно делать с нуля? Существуют и конструкторы ботов, но для данной задачи они слишком просты и не достаточны по функционалу.
? Решение
Основные фичи такси-бота:
- Базовые функции — работа с кнопками, отправка сообщений. ты ему вопрос, он тебе ответ.
- Система управления ботом. Реализован бэкенд с системой управления ботом. это мини комплекс, в котором можно настраивать сообщения, пользователей, дату регистрации, историю поездок, где были сделаны заказы — для проведения аналитики. Сделали возможность подключения к другим мессенджерам через драйвера.
- Тарификация по зонам.
- Языковые пакеты — меняются кнопки, диалоги. Менеджеры для языков местных народов. На этой базе можно легко расширить количество поддерживаемых языков.
- Избранные адреса, маршруты — в конце поездки бот предлагает создать любимый маршрут. Удобно если часто ездишь по одному и тому же маршруту, не нужно выбирать начальную и конечную точку.
- Отказоустойчивость. Сделали так, чтобы бот не падал из-за неадеквата, повышенной нагрузки, пропавшей сети. Адекватно реагировал на непонятные диалоги и прочие узкие места.
- Функция «Спросить гео-локацию»: Отслеживание машины к пункту отправления; Где машина находится во время заказа.
Времени потратили — множество часов на тестирование и тестовое использование. Также реализовали механизм отлова ошибок. Если что-то пойдет не так, то пользователь не зависнет в диалоге. Будет уведомление в системе и запись в лог.
Узкие места
Больше всего заморочек обнаружилось у ВК. Причем, заморочки эти отсутствовали в документации. Например: Для стабильной работы ВК сервер пришлось перенести в московский дата-центр, так как отклик из Сибири для ВК слишком долгий. Бот начинал разговаривать с ошибками долгого ожидания и падал. ВК имеет жесткие ограничения: от количества символов в кнопке до длины сообщений. Формат меню — максимум 10 строк. При поиске адреса приходилось пользоваться списками в тексте, а не кнопками, как в телеграмме.
Вывод
С этим клиентом мы работаем уже более двух лет. Этим доверием мы можем гордится. Нам продолжают поступать новые задачи и мы ищем новые решения. В чем секрет успешного взаимодействия? Мы максимально выявляем потребность и релевантность запросу, погружаемся в задачу. Иногда, для того чтобы решить задачу, нужно пролезть не только в голову клиента, но и к разработчикам используемых сторонних решений.
Полный текст статьи читайте на CMS Magazine
