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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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