Особенности разработки мобильного приложения для службы доставки: кейс B2B-сервиса Cargo

На примере B2B-сервиса Cargo рассказываю о проблемах, с которыми сталкивается команда,  когда разработка мобильного приложения для доставки начинается после подписания договора с клиентом, и объясняю как с этими проблемами справиться.

Кто из стартаперов не мечтал о том, чтобы получить первых клиентов еще до релиза приложения или сервиса? Кажется, что это гораздо надежнее и перспективнее, чем запускаться в условиях неопределенности, однако все не так однозначно. Например, в B2B-сегменте подобная стратегия требует очень грамотного управления продуктом, в противном случае есть риск не оправдать ожидания клиента. 

Как продать мобильное приложение для доставки без единой строчки кода

За границей продажа ИТ-продуктов на ранних стадиях — распространенная история. Вне зависимости от планов — будь-то разработка мобильного приложения для службы доставки еды или лекарств — если стартапер нащупал боль рынка и готов предложить действительно хорошее решение, у него есть все шансы получить первого заказчика еще до написания первой строчки кода. Не только инвесторы готовы вкладываться в перспективные ИТ-решения, но и клиенты, ведь у покупки продуктов на этапе концептов много преимуществ. Главное из них — возможность получить кастомный сервис за минимальную стоимость.

Продажа еще не готового мобильного приложения для доставки происходит с помощью дизайн-концептов и кликабельных прототипов, которые демонстрируют эффективное решение боли рынка. Однако в отличие от инвесторов, клиенты не готовы рисковать и ждать годами релиза, поэтому они купят только те сервисы, которые через 2-4 месяца будут как минимум стабильно работающими MVP (Minimum Viable Product). 

Наш кейс начался с того, что стартапер Gurpreet Jajj из Арабских Эмиратов обратился в Purrweb за дизайн-концептом мобильного приложения для службы доставки. Планировалось, что решение будет оптимизировать логистику в малом и среднем бизнесе: например, в интернет-магазинах, ресторанах, прачечных. Мобильное приложение для доставки должно было стать приложением-шаблоном (White Label), которое органично интегрируется в бизнес-процессы клиентов, делая доставку по городу прозрачной и эффективной.

Дизайн-концепт​

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

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

Разработка на максимально допустимых скоростях: угрозы и правила безопасности

Мобильное приложение для доставки: планирование и приоритеты

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

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

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

Основной флоу: главный экран, второй, маршрутный лист

Основной флоу в мобильном приложении для доставки Cargo выглядел следующим образом. Курьер приезжает на склад, открывает приложение и начинает работу, отметив свой статус. Второй экран — список посылок, которые надо сегодня доставить. Курьер находит их на складе, затем сканирует бар-код или вводит его вручную: эта процедура означает, что посылка теперь находится под ответственностью курьера. Как только все посылки собраны, курьер получает маршрутный лист, в котором получатели рассортированы максимально удобным образом. Поскольку доставщики чаще всего передвигаются по городу на машине, мы интегрировали в приложение навигатор. Когда курьер вручает посылку адресату, ее опять надо просканировать, и после этого можно ехать в следующую точку.

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

Дополнительный флоу: электронная подпись, профайл

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

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

Frontend driven development: первым делом интерфейсы

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

Чтобы оптимизировать наше взаимодействие с командой бэкенд-программистов, мы решили работать по принципу frontend driven development. Так как главное преимущество нашего приложения — пользовательские сценарии, вначале мы делали клиентскую часть, и только потом серверную. Именно мы решали, когда и какие запросы отдавать на сервер, и определяли структуру ответа.

Одна из самых сложных задач в разработке мобильного приложения для доставки — составление маршрута

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

​Экран навигатора

Минимализм — не только про чистоту и воздух

При дизайне интерфейсов приложений формата White Label надо учитывать, что сервис должен легко мимикрировать под любой брендинг. Фактически приложение White Label — это шаблон приложения, но данный факт не должен сказывается на дизайне, более того, сжатые сроки — не повод жертвовать визуальной составляющей. Чтобы интерфейсы не выглядели, как заготовка, а само приложение было живым и ярким, мы много внимания уделили деталям. Например, даже неинформативный полупустой экран «Отсутствие заданий» мы сделали гармоничным и сбалансированным за счет аккуратной иконки.

Экран отсутствия заданий

Есть и другие нюансы при работе с приложениями White Label: они касаются цветовой гаммы. Традиционное решение — продумать систему из основных и дополнительных цветов, которые будут меняться на фирменные цвета из брендбука клиента.

Но из-за сжатых сроков мы выбрали более простой путь и сформировали максимально универсальную, при этом логичную палитру. Акценты мы расставили с помощью «светофорных» цветов, интуитивно понятных каждому водителю. Зеленый — операция прошла успешно, действие одобрено, а красный — ошибки и недоступные элементы.

Цветовая палитра 

Ручное тестирование 

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

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

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

React Native

Для попадания в дедлайны и обеспечения стабильной работы приложения, крайне важна скорость исправления багов. Именно поэтому весь фронтенд мы решили делать на React Native: несмотря на предубеждения, этому фреймворку практически нет равных в создании кроссплатформенных приложений с красивыми адаптивными интерфейсами в кратчайшие сроки.

К React Native много претензий со стороны разработчиков из-за ряда сложностей с поддержкой библиотек и зависимостей. Однако мы давно работаем с этим фреймворком и научились справляться с его ограничениями и недостатками. В данном случае для навигатора мы использовали готовую открытую библиотеку MapBox, которая после небольшой отладки стала четко и стабильно работать.

Новый уровень: один клиент хорошо, а три — лучше

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

Наш MVP пережил испытание масштабированием: выбранный технологический стек (React Native, Realm, Mapbox) позволил успешно развивать сразу несколько версий приложения. А сам сервис стал популярным решением, которое сейчас предлагается в рамках линейки продуктов IT-компании Illuminate Software Solutions.

[ Оригинальная версия статьи опубликована на vc.ru]