Приложение для водителя и курьера: что включить в MVP

MVP — рабочий цикл, а не набор экранов

Первая версия приложения водителя должна позволять выполнить реальное задание: получить заказ, найти адрес, передать результат и убедиться, что он принят системой. Если после красивой демонстрации диспетчер всё равно собирает статусы по телефону, основной процесс ещё не автоматизирован.

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

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

Опишите смену по шагам

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

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

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

Что включить в первую версию

Базовый состав для проверки сценария доставки
Функция	Зачем нужна	Как проверить
Вход и разграничение доступа	Исполнитель видит только доступные ему задания	Чужой заказ недоступен, заблокированная учётная запись не получает новые данные
Список и карточка задания	Адрес, контакт, груз и ограничения собраны в одном месте	Водитель может выполнить заказ без поиска сведений в переписке
Переход в навигатор	Не нужно переносить адрес вручную	Открывается нужная точка; предусмотрен некорректный адрес
Статусы и причины отклонений	Диспетчер понимает результат и следующий шаг	Проверены успех, отказ, перенос и допустимые переходы
Подтверждение результата	Материалы привязаны к заказу	Фото или иное согласованное подтверждение не теряет связь с событием
Локальное сохранение и синхронизация	Результат не зависит от мгновенной доступности сети	После восстановления связи событие передаётся без дублирования

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

Офлайн-режим: что именно должно работать без связи

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

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

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

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

Геолокация и удобство работы

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

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

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

Основные действия должны иметь крупные зоны нажатия и понятные подписи. Причины отказа лучше выбирать из короткого согласованного списка с возможностью комментария. Интерфейс следует проверять на стоянке и при работе на точке; он не должен требовать взаимодействия с телефоном во время движения.

Что требуется кроме мобильного приложения

Нужен источник заданий и место, где диспетчер увидит результат. Это может быть существующая TMS, 1С или небольшой веб-кабинет. Если такой системы нет, её минимальные функции входят в состав проекта: назначить заказ, изменить его, увидеть задержку и разобрать ошибку.

Заранее определите, кто управляет статусами, как передаётся отмена и что происходит при смене водителя. Техническую сторону обмена разбираем в статье «Интеграция приложения доставки с 1С».

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

Что обычно можно оставить на следующий этап

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

Откладывать следует не сложные функции вообще, а функции, без которых выбранный процесс остаётся полноценным. Если главный предмет проверки — автоматическая маршрутизация, её нельзя заменить ручным назначением и затем объявить гипотезу подтверждённой.

Как принять MVP на пилоте

Проводите пилот на ограниченном участке с обычными и проблемными заказами. До старта зафиксируйте исходные показатели и критерии продолжения проекта. Пример набора измерений:

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

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

Частые вопросы

Нужно ли сразу делать приложение для двух платформ?

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

Сколько стоит такой MVP?

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

Что передать для обсуждения проекта?

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