Короткий ответ: приложение для доставки — это не только каталог и кнопка «заказать». Рабочая система связывает клиента, оператора, склад или ресторан, курьера и оплату в один маршрут со статусами. Самые дорогие ошибки возникают на стыках: заказ создан, но не попал в обработку; курьер видит старый адрес; клиент получил уведомление, а статус не изменился.
У доставки есть несколько параллельных ожиданий. Клиент хочет видеть статус, оператор — управлять исключениями, курьер — короткий маршрут и сообщение о проблеме, бизнес — понимать отмены и задержки. Один интерфейс не решит все задачи одинаково хорошо: нужны роли, права и разные рабочие сценарии.
Минимальный контур доставки
| Участник | Задача | Проверка |
|---|---|---|
| Клиент | создать, оплатить и получить заказ | адрес, сумма, отмена и уведомление |
| Оператор | принять и решить исключение | ручное изменение и журнал |
| Курьер | получить задачу и завершить | назначение и подтверждение |
| Склад | подготовить передачу | готовность и состав |
| Руководитель | видеть качество процесса | согласованная аналитика |
Для MVP выберите один основной маршрут: заказ, оплата, подготовка, передача, доставка и подтверждение. Затем отдельно опишите отмену, нехватку товара, неверный адрес, задержку и недоступность платежного сервиса.
Paladin Engineering может перевести этот процесс в мобильное приложение, веб-интерфейс оператора и интеграции. Объём первой версии определяется ролями, исключениями и внешними системами, а не только числом экранов.
Статусы заказа — единый язык
Статус — это основа уведомления, действия оператора, маршрута курьера и отчёта. Если разные системы называют одно состояние по-разному, пользователи исправляют данные вручную, а аналитика перестаёт объяснять задержки.
| Статус | Кто меняет | Что дальше |
|---|---|---|
| Черновик | клиент | изменить состав и адрес |
| Принят | система или оператор | передать на подготовку |
| Готовится | склад или ресторан | указать готовность |
| Передан курьеру | оператор или склад | открыть маршрут |
| В пути | курьер | сообщить о задержке |
| Доставлен | курьер и система | закрыть заказ |
| Отменён | роль по правилу | зафиксировать причину |
До разработки договоритесь, что происходит при повторном событии. Курьер может нажать кнопку дважды, сеть вернуть ответ с задержкой, а интеграция прислать старый статус позже нового. Нужны правила порядка событий, идемпотентности и ручного разбора конфликтов.
Каталог, корзина и заказ
Каталог усложняется, когда появляются филиалы, зоны доставки, остатки, модификаторы, минимальная сумма, расписание и разные цены. Клиенту важно, чтобы итог корзины совпадал с итогом оплаты; оператору — понимать, почему позиция исчезла и кто может изменить заказ.
- разделите доступность позиции и её видимость в каталоге;
- зафиксируйте момент подтверждения цены и состава;
- показывайте ограничения зоны доставки до ввода всех данных;
- сохраняйте снимок состава и цены для созданного заказа;
- предусмотрите человека при конфликте остатков или цены;
- не связывайте финальный статус только с ответом платежного сервиса;
В техническом задании описывайте не только поля, но и события: заказ создан, оплата подтверждена, подготовка начата, курьер назначен, адрес изменён. Для каждого события нужен владелец, допустимый переход и способ повторной обработки.
Карта и маршрут курьера
Курьерскому сценарию нужен короткий путь: список задач, адрес, порядок, контакт, отметка статуса и сообщение о проблеме. Карта не заменяет правила маршрутизации. Заранее решите, кто назначает заказ, можно ли менять порядок остановок, что делать при недоступном адресе и какие данные видит курьер.
| Вопрос | Почему влияет на разработку |
|---|---|
| Кто назначает? | автоматическое правило требует контроля исключений |
| Можно ли объединять? | меняется модель маршрута и ответственность |
| Что видит курьер? | нужно ограничить данные |
| Как подтвердить? | код, фото и подпись дают разные риски |
| Что при потере связи? | нужна безопасная синхронизация |
Не обещайте точное время, если нет устойчивых данных о загрузке, маршруте и готовности. Честный диапазон лучше визуально точного, но ненадёжного таймера.
Оплата, данные и права
Платёжный путь должен иметь отдельные состояния: не начат, ожидает подтверждения, успешен, отклонён, возврат в процессе и возвращён. Нельзя считать заказ оплаченным только потому, что пользователь вернулся из платёжной формы.
OWASP ASVS даёт основу проверяемых требований безопасности, NIST SSDF — язык для безопасных практик в жизненном цикле, а WCAG 2.2 — ориентир для доступных форм и ошибок. Для доставки это означает минимальный доступ, защищённые сессии, контроль входящих событий, проверку API, журналирование изменений и тесты повторной отправки.
| Зона | Договорённость | Проверка |
|---|---|---|
| Клиент | видит свои заказы и адреса | открытие чужого объекта |
| Курьер | видит назначенные задачи | смена роли и прямой API |
| Оператор | меняет допустимый статус | запрет обратного перехода |
| Платёж | callback доверенного источника | подделка и повтор события |
| Логи | событие без лишних данных | доступ и срок хранения |
Как принять приложение
Приёмка моделирует обычный и плохой день: создать заказ, изменить состав, оплатить, подготовить, назначить курьера, пройти маршрут и завершить доставку. Затем повторить путь с задержкой, отменой, неверным адресом, нехваткой позиции, разрывом сети и повторным платежным событием.
- цена, состав, адрес и статус согласованы на ключевых экранах;
- каждая роль видит только нужные действия;
- повтор запроса не создаёт вторую оплату или заказ;
- оператор исправляет исключение без прямого редактирования базы;
- уведомление не обещает неподтверждённый результат;
- есть метрики отмен, задержек и ручных вмешательств;
Как Paladin Engineering может помочь
Paladin Engineering может подключиться на этапе discovery: описать роли, статусы, интеграции, границу MVP и критерии приёмки. Оставьте заявку, если нужно сравнить архитектуру до оценки бюджета и сроков.
FAQ: приложение для доставки
Что включить в MVP?
Создание заказа, корзина, оплата, статусы, уведомления, операторский сценарий и маршрут курьера; состав зависит от зон и источников данных.
Нужна ли карта сразу?
Не всегда. Если карта не является основной ценностью, важнее адреса, статусы и обработка исключений.
Как не потерять заказ при сбое оплаты?
Разделить состояния заказа и платежа, получать подтверждение из доверенного источника и поддержать повторную обработку без второго списания.
Какие данные видит курьер?
Только нужные для назначенных задач и безопасного контакта; прямой доступ ко всей базе не нужен.
Как оценить готовность?
Проверить сквозные и негативные сценарии, роли, статусы, оплату, уведомления, сеть, повторы и доступность.
Комментарии