Техническое задание

1. О проекте

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

Ключевая метрика запуска: доля доставок, статус которых проставлен без участия диспетчера.

2. Целевая аудитория и сценарии использования

Пользователи: штатные и подрядные курьеры, диспетчер на стороне заказчика.

• Курьер утром открывает приложение → видит маршрут дня со списком адресов и окнами доставки → строит навигацию до первой точки.
• Курьер на точке → отмечает «доставлено» или причину недоставки → фотографирует накладную → подпись получателя на экране.
• Курьер в подвале без сети → отмечает статусы офлайн → приложение синхронизирует их, когда связь появится.
• Диспетчер видит статусы в учётной системе в реальном времени и связывается с курьером только при отклонении от маршрута.

3. Функциональные требования

• Авторизация по номеру телефона с кодом из SMS, вход в одно касание при повторном запуске.
• Маршрут дня. Список точек с адресами, окнами доставки, составом заказа и контактом получателя; переход в навигатор по нажатию.
• Смена статуса. Доставлено, частично, отказ с причиной из списка; обязательное фото накладной для отказов.
• Подпись получателя пальцем на экране, сохраняется вместе со статусом.
• Офлайн-режим. Локальная база с очередью изменений и фоновой синхронизацией, индикация несинхронизированных точек.
• Push-уведомления. Новая точка в маршруте, изменение адреса, срочная отмена.
• Экран смены. Итог дня: доставлено, отказов, пройдено точек.

4. Интеграции

• Учётная система заказчика — маршрут на приложение, статусы и фотографии обратно, через REST API на стороне бэкенда.
• SMS-провайдер — коды авторизации.
• Push (FCM / APNs) — уведомления о смене маршрута.
• Карты и навигация — открытие внешнего навигатора по координатам точки.

5. Рекомендуемый стек

• Flutter — одна кодовая база на iOS и Android: у курьеров парк устройств смешанный, две нативные разработки не окупятся.
• SQLite на устройстве — офлайн-очередь статусов и кэш маршрута.
• Laravel на бэкенде — прослойка между приложением и учётной системой: разбирает форматы, хранит фото, держит очередь синхронизации.
• S3-совместимое хранилище — фотографии накладных.

6. Этапы работ

1. Аналитика и прототип (2 недели). Результат: сценарии смены статуса, схема офлайн-синхронизации, прототип экранов.
2. Дизайн (2 недели). Результат: макеты под работу одной рукой и на солнце: крупные зоны нажатия, высокий контраст.
3. Бэкенд и интеграция с учётной системой (3–4 недели). Результат: маршрут отдаётся по API, статусы принимаются и уходят в учёт.
4. Приложение (5–7 недель). Результат: сборка с полным сценарием дня, включая офлайн.
5. Пилот и публикация (3 недели). Результат: две недели на пяти курьерах, исправления, публикация в App Store и Google Play.

7. Что не входит в первую версию

• Построение маршрута внутри приложения — используем внешний навигатор.
• Финансовый модуль курьера (расчёт выплат) — остаётся в учётной системе.
• Приложение для получателя с отслеживанием заказа — отдельный проект.

8. Открытые вопросы к клиенту

• Какая учётная система используется и есть ли у неё готовое API?
• Устройства корпоративные или личные? От этого зависит требование к минимальной версии ОС.
• Нужна ли фотофиксация при успешной доставке или только при отказе?
• Кто будет владельцем аккаунтов разработчика в сторах?