{"id":14285,"url":"\/distributions\/14285\/click?bit=1&hash=346f3dd5dee2d88930b559bfe049bf63f032c3f6597a81b363a99361cc92d37d","title":"\u0421\u0442\u0438\u043f\u0435\u043d\u0434\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u043c\u043e\u0436\u043d\u043e \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0442\u044c \u043d\u0430 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u0438\u043b\u0438 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u044f","buttonText":"","imageUuid":""}

Как за 90 дней с помощью no-code упростить жизнь водителя грузовика в США. Кейс Expresica

Привет, я Игорь Озеров, создатель Swiftle. Мы помогаем стартапам свести к минимуму time to market, для чего используем no-code подход в сочетании с классической разработкой. Сегодня хочу рассказать, как мы создали и запустили сервис Expresica, который облегчил жизнь американским дальнобойщикам.

С чего все началось

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

Анар, наш заказчик, работает в тракинговом бизнесе — занимается перевозками по США.

Транспортная система Штатов перевозит около 50 миллионов тонн грузов в день. Грузовики водят приблизительно 3,5 миллиона дальнобойщиков.

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

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

Задача

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

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

Девизом сервиса, который еще только предстояло разработать, стала фраза «no more paperwork» — проект должен был автоматизировать бумажную работу. По задумке создателя, платформа сама формирует необходимые документы и позволяет нужной стороне их подписывать — для этого ей необходим статус электронного брокера, чтобы соответствовать требованиям законодательства.

Рынок грузоперевозок США и Канады де-факто един, однако законы этих стран отличаются, поэтому для MVP было принято решение ограничиться только перевозками в пределах США. Кроме того, мы решили сфокусироваться на относительно небольших грузах и машинах — обычных грузовиках и холодильниках. Это отсекает довольно большой сегмент компаний и водителей, работающих с длинными траками, зато позволяет создать продукт, с которым легче выйти на высококонкурентный рынок.

Решение

Первый этап — сбор бизнес-требований, формирование логики и структуры проекта. Нам нужно было действовать быстро, поэтому вместо 100-страничного громоздкого ТЗ мы собрали референсы — проекты из сферы грузоперевозок: Сonvoy, Trucker Path, Doft. Далее зафиксировали ключевые функции и проработали CJM для заказчиков услуг грузоперевозок и для дальнобойщиков. И сразу приступили к воплощению.

Для разработки нам понадобилось несколько сервисов: основой проекта стала no-code платформа Bubble, к которой мы подключили PDF-Monkey, Google Карты, Stripe и Twilio. Дизайн и интерфейсы проектировали с помощью Figma.

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

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

Визуальная часть

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

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

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

Ключевые особенности и «фишки» проекта

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

  • Добавили автоматический расчет расстояния.
  • Цена перевозки и необходимые налоги рассчитываются на стороне сервиса.
  • Клиент может выбрать несколько автомобилей с водителями.

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

Оформление заказа

Expresica сама ведет пользователя от экрана к экрану, от формы к форме. Информация, уже имеющаяся в системе, автоматически подставляется в нужные поля, ее не нужно вносить вручную.

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

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

Заявка заказчика, в которой он заносит всю информацию о грузе: локацию, тип транспорта, который требуется, цену

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

Интерфейс дальнобойщика. Он может согласиться с заявленной ценой или предложить свою

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

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

Когда груз доставлен, водитель меняет статус на «Unloaded» и прикрепляет фотографии груза

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

Выбор времени

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

Но порой грузоотправитель указывает интервал, и тогда все превращается в гонку на скорость — первый водитель, приехавший на адрес в обозначенный промежуток времени, отправляется к месту доставки с грузом, а все остальные остаются ни с чем. На английском это звучит как «First-come-first-serve» и обозначается как FCFS. Ближайший русский аналог этого выражения: «Кто первый встал, того и тапки».

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

Автоматический расчет расстояния

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

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

Расчет цены. Налоги

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

Что получилось в результате

В создании Expresica принимали участие 4 разработчика. Сейчас сервисом пользуются более 1300 дальнобойщиков с 2500 грузовиками по всей территории США. Более 50 заявок обрабатывается каждый день.

Сейчас сервисом пользуются более 1300 дальнобойщиков с 2500 грузовиками по всей территории США. Более 50 заявок обрабатывается каждый день.

С ростом сервиса наш клиент запустил бесплатную программу по обучению грузовых диспетчеров «Expresica Academy», после прохождения которой можно трудоустроиться к ним. Сейчас по ней обучается около 40 человек.

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

С компанией Swiftle мы работаем уже больше года. Обратился к ним после неудачного опыта с похожей компанией по поводу другого моего продукта. Игорь (CEO Swiftle) и его команда помогли исправить все недочеты, оставленные предыдущим исполнителем. Мне понравился его подход, внимание к качеству продукта и к построению взаимоотношений с клиентом.

Спустя время я задумался о создании платформы Expresica на базе моего оффлайн-бизнеса, и я снова обратился к Swiftle. Рассказал про идею, Игорь подключил меня к команде и мы начали работу над платформой. Спустя короткое время была запущена первая версия.

У меня нет знаний в программировании и IT, поэтому иногда мои предложения по разработке продукта могли быть не совсем рациональны или последовательны. Но команда Swiftle показала и убедила, что no-code адаптивен к быстрым изменениям и очень гибок. Поэтому все, даже невыполнимые на первый взгляд задачи, получилось реализовать

Анар Сеидов, Founder Expresica

No-code помогает стартапам минимизировать time to market, запустить MVP и на практике выстроить юнит-экономику проекта — это особенно важно сейчас, когда обстановка и потребности аудитории меняются еще быстрее, чем обычно. Кейс Expresica подтверждает, что для запуска сервиса не обязательно тратить месяцы и годы — сделать процесс технологичнее и проще можно меньшими усилиями.

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

Остаемся на связи!

0
64 комментария
Написать комментарий...
Валентин Потапов

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Constantine

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

Ответить
Развернуть ветку
Дмитрий Перепёлкин

Ну объективно, PHP отличен для сайтов, магазинов и прочей бурды. VC, кстати, на PHP, и новостные сайты / порталы тоже идеально подходят.
Но когда речь о SaaS, лучше всё же что-то, что поддаётся адекватному дебагу, и это явно не PHP.

Ответить
Развернуть ветку
Constantine

Эм, я думал кто-то напишет про более явные проблемы/особенности php, а вот про дебаг не ожидал. В чем проблема с дебагом?

Ответить
Развернуть ветку
Дмитрий Перепёлкин

Более явные проблемы в виде непредсказуемости интерпретатора слишком очевидны :)
Сравнение переменных и типов, прочие приколы, надо ли об этом здесь писать?

Мне приходится периодически сталкиваться с legacy кодом на PHP, и лично меня смущает именно отсутствие дебаггера. Spring / ROR / Django легко поднимаются в тестовой среде без дополнительных махинации, фреймворки под это заточены. Ладно, абстрагируемся от фреймворков, много ли проектов на PHP упаковано в Docker, 1%? Что делать с самописными PHP сайтами, которые завязаны на кучу всего..?
Во-первых, тестовую среду не так просто поднять, надо идти по переменным и всё менять, а то нежданчик подкрадётся незаметно, даже в локалке, и письмо улетит с тестовой среды, неприятно же.
Во-вторых, нет нормального IDE с дебаггером, где можно отследить переменные. Ок, всё это можно, в теории, предусмотреть прописывая дебаг код прямо на проде, но cookbook далеко не всегда работает, например если страница ссылается на AJAX, там как ни крути, либо лезть в JS код, либо очень хитровы***нно пытаться поймать что POST передаёт с форм.

Опять же, это legacy, коих на PHP подавляющее большинство. На PHP можно писать складно и интуитивно, но таких проектов мизер.

Я к счастью (или сожалению) не программист на PHP и проекты по ремонту даются с трудом, хотя в целом переход между языками и средами разработки не вызывает какого-либо дискомфорта. Возможно Вы развеете мой миф, что нормального дебага в PHP нет.

Ответить
Развернуть ветку
Constantine
непредсказуемости интерпретатора

В чем именно непредсказуемость?

Сравнение переменных и типов

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

приходится периодически сталкиваться с legacy кодом

Не стоит по legacy делать выводы о языке в целом.

отсутствие дебаггера

100 лет уже существует xdebug.

Spring / ROR / Django

Это же фреймворки, а не чистый язык. Сравнивайте тогда с Symfony / Laravel. Уверен, что все будет так же удобно.

много ли проектов на PHP упаковано в Docker

Последний раз видел проект без докера в 2018 году. И то его тоже контейниризировали. В php уже давно все пишут микросервисы, без докера никак.

Во-первых, ...

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

нет нормального IDE с дебаггером

Самый популярный и удобный PHPStrom. Из бесплатного Netbeans, иногда будет достаточно VS Code (не IDE). Все отлично работают с xdebug. Ставим брекпоинты, перемещаемся по ним, смотрим контекст. Такой же дебаг как везде.

если страница ссылается на AJAX, там как ни крути, либо лезть в JS код

Даже без дебагера всегда можно вывести POST простым принтом.

legacy, коих на PHP подавляющее большинство

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

миф, что нормального дебага в PHP нет

Повторюсь про xdebug. Можно посмотреть как работает здесь: https://youtu.be/5QrdFpxbkzA?t=6m01s

Ответить
Развернуть ветку
Дмитрий Перепёлкин
Наверное имеется ввиду сравнение переменных разных типов? Вроде этот момент весьма докладно описан в документации языка и он особо не отличается от других слаботипизированных языков.

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

Это же фреймворки, а не чистый язык. Сравнивайте тогда с Symfony / Laravel. Уверен, что все будет так же удобно.

Чистый питон или руби не умеет в сайты, PHP же задумывался как язык для сайтов и работает из коробки под эти нужды. Laravel неплох, но когда я познакомил разработчиков на нём с ROR, это было сравнимо с открытием нового мира :)
Потом, сколько сайтов написанных на Ruby используют ROR? 100%. Сколько сайтов написано на Laravel? В основном это Wordpress, Joomla, Netcat, Drupal и пр., и дай бог если эти сайты действительно используют функционал CMS, а не имеют кучу чёрти-какого кода в обёртке.

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

Вероятно Вам везёт с проектами. Проблема языка всё же есть — его простота и доступность, что в нулевых привело к куче школьников пилящих сайты без каких-либо принципов и code style, и таких проектов подавляющее большинство. Даже в корпоративе картина не лучше. Хрен с ним с корпоративом, многие на amo сидят, это тот ещё демон с своими приколами. Python хорош для новичков за счёт отступов, Ruby придерживается KISS, Java тоже довольно строгий язык, нода не подводит. В PHP всё куда хуже. Да, вероятно это не проблема языка, но проблема того подавляющего большинства, что пишет на нём.

Даже без дебагера всегда можно вывести POST простым принтом.

Можем в ЛС разобрать случаи, когда это не так. Либо я слишком плох в PHP, либо проблема всё же есть.

100 лет уже существует xdebug.
Повторюсь про xdebug.

В том то и дело, что это ненормальный дебаггер. Вероятно с Laravel он ещё сносно работает, для сайтов на CMS это адище, особенно после опыта с адекватным инструментарием.

Ответить
Развернуть ветку
Constantine
я слишком плох в PHP

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

Ответить
Развернуть ветку
Дмитрий Перепёлкин

Вряд ли навык как-то повлияет на то, что в legacy творится, но спасибо.

Ответить
Развернуть ветку
Валентин Потапов

Кто на чем умеет, тот так и делает. Бэкендер пхп освоил и пилит. Между бэком и фронтом все равно апи лежит.

Ответить
Развернуть ветку
Дмитрий Перепёлкин

Внезапно, но в точку!

Ответить
Развернуть ветку
61 комментарий
Раскрывать всегда