Разработка приложения доставки товаров — проектируем MVP

Денис Гордиенко, генеральный директор Bright Mobile, о проектировании сервиса по доставки без лишних функций и для каких сфер оно может сработать.

Недавно я прочёл статистику от YCombinator – американского фонда, считающегося самым успешным с точки зрения венчурного инвестирования.

У YCombinator есть разбивка на две группы. Первая – компании, которые начинали свою работу 4-9 лет назад, Тут основном b2b-проекты (в т.ч. SaaS проекты для b2b), а также ecommerce. Такие проекты очень сильно выросли во время пандемии, когда люди сидели дома и заказывали товары на дом, и они были обречены на успех.

Во второй группе размещены молодые проекты возрастом от одного года до четырёх лет. Тут собрались ребята другого плана: финтехи, биотехнологии, а также всё, что связано с блокчейном и NFT. То есть акселератор решил, что доставки сейчас — это красный океан и инвестировать в проекты в этой сфере не выгодно.

Приложение доставки

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

Не буду раскрывать детали, чтобы не создавать ему конкурентов, но скажу, что после долгих лет торговли Дмитрий пришёл к пониманию, что работа через личные контакты, телефонные звонки и чат-боты ему неудобна, и гораздо эффективнее будет разработать собственное приложение.

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

Структура MVP

Начнём с базовых экранов. У нас будет две роли: заказчик и исполнитель (курьер). Им нужен ряд общих экранов:

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

Выше перечисленное – это основа, на которую мы вешаем логику.

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

  • Редактирование профиля заказчика;
  • Редактирование профиля исполнителя.

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

  • Просмотр профиля исполнителя;
  • Просмотр профиля заказчика.

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

Взаимодействие происходит следующим образом: заказчик заходит в мобильное приложение и формирует заказ. У него будут следующие разделы:

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

Исполнитель у моря погоды не ждёт, поэтому у него должен быть экран списка актуальных заказов, о которых ему также будут приходить push-уведомления. Добавляем:

  • Все актуальные заказы;
  • Просмотр заказа.

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

Следующий пункт логики – курьер соглашается с этим заказом – после этого клиенту приходит уведомление, что в скором времени к нему придёт курьер. Здесь мы объединяем экраны заказчика и исполнителя: – маршрут, чтобы исполнитель знал, куда идти, а клиент – чтобы видел, где курьер сейчас находится и как скоро он приедет.

  • Статус заказа с картой.

В момент, когда курьер забрал заказ и едет в точку В, остаётся этот же экран, только меняется направление маршрута. А вот когда он отдаст груз получателю, у курьера должен появиться экран отчётности, а у заказчика – просмотр отчёта.

  • Отчёт по заказу;
  • Просмотр отчёта.

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

  • Уведомления;

где будет прописана вся их логика и прописаны сценарии отправки push-уведомлений.

  1. При создании заказа появляется первое уведомление для курьеров, которые подходят под географию – например, для всех, кто сейчас находится в радиусе 5 километров от клиента и готов быстро подъехать. В уведомлении курьеры получают информацию о новом заказе.
  2. Первый курьер, который забирает заказ, инициирует отправку уведомления заказчику, который узнаёт об отклике.
  3. Когда курьер подъезжает и забирает посылку, уведомление приходит о доставке, об отчёте и т.д. – по всем пунктам процесса.

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

  • Экран оплаты.

Итак, всего мы имеем 17 экранов базовой логики доставки. Очевидно, что её можно будет расширять и дальше – к примеру, добавить экраны выполненных заказов у клиента, а у исполнителя – баланс заработанных денег и их вывод на карту. Тем не менее, для основы необходимы вот эти 17 экранов, обойтись без них никак не получится.

Один экран приложения с учётом серверной части, Android/iOS стоит в среднем по рынку около 45-50 тысяч рублей. Наши 17 экранов, следовательно, обойдутся в 850 тысяч. Разработчики, возможно, будут на меня ругаться, потому что обычно за приложение с доставкой средний чек выходит в примерно 1,5 миллиона, но нужно понимать, что в них входит и дальнейшее развитие, а не только наша основа из 17 экранов. Как видите, создать адекватный сервис без излишков вполне можно меньше, чем за 1 млн рублей.

19
9 комментариев

Довольно интересно и подробно так

1
Ответить

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

Ответить

Ну я не согласен.
- Диспетчеры - ну возможно, но для теста идеи они не нужны. Заказы и через систему управления БД можно посмотреть и не обломаться.
- Логика распределения заказов уже заложена. Определить ближайшего не так сложно, например.
- Мы делали несколько сервисов на бесплатной версии карт Яндекса и всё прекрасно работает.

Ответить