Розробка мобільного застосунку для кур'єрської служби: вузькі місця
Кур'єрська доставка ламається не на етапі «довезти», а на стику між диспетчером і кур'єром. Адреси розподіляють вручну — за таблицею або в листуванні, і на кожну зміну маршруту йде дзвінок. Поки диспетчер пояснює під'їзд, наступна точка чекає, а вікно доставки зсувається.
Друге вузьке місце — статуси. Кур'єр закриває замовлення, але за слабкої мережі позначка не доходить до сервера й губиться: замовлення висить «у дорозі», клієнт телефонує в підтримку, оператор з'ясовує фактичний стан по телефону.
Чим більше точок у зміні, тим вища частка таких розбіжностей і тим менше часу залишається на саму доставку.
Третє — зворотний зв'язок. Диспетчер не бачить реального положення кур'єрів і роздає замовлення з пам'яті, а не за завантаженням: один перевантажений, другий простоює, а облік замовлень кур'єра ведеться одразу в двох місцях.
Тому розробка мобільного застосунку для кур'єрської служби — це не «гарний екран зі списком адрес», а перебудова потоку даних між диспетчером, кур'єром і клієнтом.
Застосунок для кур'єрів бере на себе приймання й підтвердження замовлень, локальну чергу змін на час без мережі, автоматичну передачу статусів і підказки щодо маршруту: автоматизація кур'єрської доставки прибирає ручні дзвінки та ручний розподіл адрес. Нижче розбираємо, як це закривається.
Що дає застосунок кур'єрської служби: вимірюваний ефект
Розподіл замовлень перестає бути ручною роботою диспетчера. Заявка надходить з облікової системи, застосунок підбирає кур'єра за зоною, поточним завантаженням і залишком зміни — маршрут на 10-15 адрес збирається за секунди замість десятихвилинних обдзвонів.
Диспетчер підключається лише до винятків: адреса поза зоною, скасування, перенесення вікна доставки.
Скорочення ручних дзвінків тримається на статусній моделі. Переходи — прийняв, забрав, у дорозі, доставив — фіксуються в застосунку й одразу видимі клієнту на карті відстеження, з повідомленням у разі зміни статусу.
Без дзвінка проходить більшість замовлень, а голосові уточнення залишаються на нестандартних випадках: зміна адреси, відмова, повторна доставка.
Робота кур'єра без зв'язку — окрема вимога, а не дрібниця.
Застосунок пише статуси, фото підтвердження й координати в локальну чергу з ключами ідемпотентності; коли з'являється мережа, вона йде на сервер одним пакетом, а конфлікти розв'язуються за часом події, а не за порядком надходження.
Карти кешуються заздалегідь: маршрут будується за OpenStreetMap і не залежить від постійного каналу.
Що видно в метриках після переходу:
- збирання маршруту — секунди замість хвилин, розподіл без участі людини;
- частка замовлень без дзвінка диспетчеру зростає з одиниць до більшості;
- простої на вивантаженні падають: кур'єр бачить порядок адрес і вікна доставки, а не уточнює їх голосом;
- зникає клас відмов — загублені позначки про доставку й подвійні призначення на одне замовлення.
Ефект від автоматизації доставки складається з цих чисел, і кожне перевіряється за логами та звітами на стороні замовника.
Готове рішення, доопрацювання чи розробка з нуля
Три підходи відрізняються не обсягом робіт, а тим, кому належить код і скільки унікальної логіки доведеться на нього навісити.
Перш ніж обирати, варто чесно розкласти кур'єрський застосунок на типове — статуси замовлення, маршрут, підтвердження доставки, приймання оплати — і на те, що справді ваше.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Готове рішення для доставки | Процеси стандартні, потрібно швидко запустити маршрути й статуси на своїй території | Логіка вшита в чужі сценарії, змінюється лише через налаштування; частина оновлень і даних залежить від постачальника платформи |
| Доопрацювання застосунку кур'єрів | База вже ходить маршрутами, але потрібні власні правила розподілу замовлень і зв'язка з обліковою системою | Успадковуються архітектурні рішення платформи; зміни зачіпають її ядро, строки залежать від відкритості інтерфейсів власника |
| Розробка з нуля | Нестандартна логіка — тарифи, зони, кілька складів, робота кур'єра без стійкого зв'язку | Довше до першого робочого релізу і далі потрібна своя команда, яка оновлює застосунок услід за платформами |
Вибір підходу визначає частка нестандартної логіки та вимоги до контролю над кодом. Якщо унікальних сценаріїв менше третини, розумніше взяти готову базу й доопрацювати її; якщо більше — з нуля, інакше кожна зміна буде впиратися в чужі архітектурні рішення.
Як відбувається впровадження: етапи інженерної роботи
Починаємо не з коду, а з того, як влаштована диспетчерська сьогодні: хто розподіляє замовлення і за якими ознаками, які статуси замовлення реальні, а які живуть лише в голові диспетчера. На виході — схема процесу й список місць, де застосунок знімає ручну роботу, а не додає її.
- Обстеження процесів диспетчерської. Розбираємо розподіл замовлень, роботу з відмовами й перенесеннями, зони відповідальності змін. Фіксуємо, де губляться замовлення і скільки часу з'їдають ручні обдзвони.
- Статусна модель і ролі. Єдині статуси замовлення від приймання до вручення, права кур'єра, диспетчера й складу — одне джерело правди для всіх учасників.
- Налаштування застосунку кур'єра. Маршрутний лист на зміну, підтвердження вручення, фотофіксація, підпис отримувача. Позначки накопичуються на пристрої й надходять у систему, коли з'являється зв'язок.
- Інтеграція з обліковою системою. Двосторонній обмін замовленнями та статусами, щоб диспетчер не працював у двох вікнах. Повторну синхронізацію перевіряємо окремо — дублі й загублені замовлення неприпустимі.
- Тестування на реальних маршрутах. Прогоняємо сценарії в підвалах, промзонах і зонах з поганим покриттям: як поводиться черга позначок і скільки триває синхронізація.
- Дослідна експлуатація. Обмежена група кур'єрів і змін, звірка факту за замовленнями з попереднім процесом. Доопрацювання йдуть короткими циклами, без зупинки основної роботи.
- Передача. Регламенти для диспетчерів і кур'єрів, документація щодо обміну даними, розбір типових збоїв.
Пакет передачі: документація, схеми, регламенти оновлення
Застосунок кур'єрської служби живе довше, ніж команда, яка його зробила: змінюється склад кур'єрів, облікова система обростає новими статусами, картографія переїжджає на інший сервіс.
Якщо після здачі залишається лише репозиторій, кожна зміна перетворюється на археологію за кодом. Тому передача проєкту — окремий етап із фіксованим комплектом, за яким інженер служби випустить версію й розбере збій без нас.
- Архітектурна схема — карта екранів і модулів, шари застосунку, точки розширення, залежності від платформи.
- Схеми інтеграцій — обмін з обліковою системою замовлень, картографією, службою геолокації та доставкою повідомлень: формати, коди помилок, повтори й час очікування відповіді.
- Матриця ролей і доступів — права кур'єра, диспетчера, адміністратора й сервісних облікових записів, обмеження на доступ до адрес і персональних даних.
- Модель даних — замовлення, маршрутний лист, статус доставки, локальна черга відправлення в разі зникнення мережі та правила синхронізації із сервером.
- Регламент оновлень — гілкування, підпис збірок, канали випуску (внутрішнє тестування, закрита група, бойовий контур), порядок погодження й відкат до попереднього випуску.
- Регламент підтримки — класи збоїв і час реакції за ними, чергування, де дивитися журнали й вивантаження падінь, як передати звернення кур'єра інженеру.
- Інструкція зі збірки та середовищ — ключі, змінні й профілі конфігурації для тестового й бойового контурів, щоб новий інженер зібрав застосунок без доступу до листування.
Кейс: прибрали ручні дзвінки та ручний розподіл замовлень
Замовник — регіональна служба доставки Кур'єр-Лайн: близько сорока кур'єрів, 300–400 замовлень за зміну і один диспетчер, який збирав маршрути вручну з таблиці. Кожен ранок починався з перерозподілу вже призначених адрес і дзвінків тим, хто ще не виїхав.
Кур'єри змінювали статуси голосом по телефону, тому «вручив» і «не застав клієнта» доходили до системи із затримкою в десятки хвилин. Диспетчерська приймала близько 180 звернень за зміну — половина була не про нові замовлення, а про уточнення статусу.
Що змінили
Застосунок кур'єра отримав локальну чергу подій: статус, геопозначка й підпис отримувача пишуться на пристрій і йдуть на сервер, коли зв'язок повертається.
Диспетчеризація доставки стала автоматичною — замовлення призначається за зоною, завантаженням кур'єра й типом транспорту, а диспетчер підключається лише до винятків: відмова клієнта, адреса поза зоною, зірване вікно.
| Метрика | До | Після |
|---|---|---|
| Середній час на маршрут | 3 год 40 хв | 2 год 50 хв |
| Доставки в узгоджене вікно | 78% | 94% |
| Звернення до диспетчерської за зміну | ~180 | ~35 |
| Спірні «клієнта не застали» | 9% замовлень | 4% замовлень |
Що стало
Частка замовлень зі статусом у строк зросла з 78% до 94%, навантаження на диспетчерську впало приблизно вп'ятеро — вивільнений час пішов на складні адреси й постійних клієнтів.
Конфліктні статуси розв'язуються за часом події на пристрої, тому повторне відправлення не створює другого запису про вручення.
Що робити, якщо у служби вже є застосунок і облікова система
Уже працюючі застосунок і облікова система — це актив, а не перешкода: у них накопичені довідники адрес і тарифних зон, історія замовлень, база кур'єрів, права доступу диспетчерів.
Починаємо з інвентаризації: дивимося, які дані реально використовуються й які процеси закриває кожна система, щоб не переносити в новий контур те, що давно не працює.
Основна перебудова — інтеграція з диспетчерською. Поки обмін тримається на вивантаженнях за розкладом, статуси розходяться, і диспетчер уточнює доставку дзвінком.
Переводимо обмін на події: замовлення створене, призначене, прийняте, доставлене або скасоване — кожна зміна йде окремим записом з ідентифікатором. Тоді повторне відправлення не створює дубль, а розбіжність видно в журналі звірки.
Перенесення даних доставки йде за зіставленням ключів: замовлення, клієнти, адреси, кур'єри, статуси. Окремо розбираємо «хвости» — завислі замовлення, дублі адрес, застарілі статуси, які не можна мігрувати автоматично.
На перехідний період обидві системи працюють паралельно: стара версія застосунку продовжує обмінюватися даними, поки оновлення не дійде до всіх пристроїв, тому кур'єр не залишається без замовлень посеред зміни.
Модернізація застосунку кур'єра — насамперед про надійність у полі: локальна черга дій (зміна статусу, фото, підпис отримувача) з досиланням у разі появи зв'язку, фонова передача місцеположення з розрахунком на довгу зміну, зрозуміле повідомлення про помилку замість «замовлення не надіслано». Звичні екрани, які не впливають на результат, залишаємо як є.
Порядок робіт: інвентаризація та звірка даних, потім тіньовий режим обміну, і лише потім перемикання за підрозділами з можливістю відкату на попередній контур.
Інтеграції, офлайн-режим, відстеження: часті запитання
На розборі майже завжди випливають три запитання: що буде із замовленням, якщо в кур'єра зник зв'язок, як застосунок ділить дані з обліковою системою і наскільки точно видно місцеположення кур'єра. Відповіді визначаються не екранами, а правилами обміну й геозон — їх фіксуємо до старту розробки.
Як застосунок працює в зонах без зв'язку?
Кур'єр продовжує роботу на локальних даних: завдання, адреси й статуси лежать у сховищі пристрою, а кожна дія пишеться в журнал операцій. Коли зв'язок повертається, журнал іде на сервер пакетом у вихідному порядку, і статуси в обліковій системі оновлюються.
Дублів не буде — кожна операція має свій унікальний ідентифікатор, повторне відправлення розпізнається як той самий запис.
Чи не почне застосунок сперечатися з обліковою системою за дані?
Джерело істини — облікова система: замовлення, адреси й склад доставки ведуться в ній, застосунок відповідає лише за хід виконання. Обмін іде захищеним каналом через шар інтеграції, де описано зіставлення довідників, ролей і статусів, а розбіжності потрапляють у звіт для розбору. Нові поля й статуси додаються в цей шар без переписування самого застосунку.
Як влаштовано відстеження кур'єра й геозони доставки?
Точки маршруту збираються на пристрої й надсилаються пакетами, тому трек залишається безперервним, а витрата батареї — передбачуваною.
Геозона описана полігоном: у разі її перетину застосунок формує подію, клієнт отримує повідомлення «кур'єр поруч», диспетчер бачить зміну статусу. Картографію й координати беремо з OpenStreetMap, щоб межі зон збігалися з реальною забудовою.
Обговорімо задачу: що потрібно знати перед оцінюванням
Щоб повернутися з оцінкою проєкту застосунку та планом робіт, нам потрібен не список побажань, а фактична картина процесів кур'єрської служби.
Чим точніші вхідні дані щодо парку, логіки замовлень і поточних систем, тим менше припущень в оцінці й тим реалістичніші строки розробки застосунку. Нижче — те, що розбираємо на першій зустрічі.
- Склад і режим парку: скільки кур'єрів працює за зміну, піші вони чи на транспорті, штат чи підрядники, чи потрібен окремий інтерфейс диспетчеру й логісту.
- Життєвий цикл замовлення: які статуси проходить доставка, хто і в який момент їх змінює, що відбувається в разі відмови, перенесення й повторної спроби вручення.
- Географія та типи доставки: міста й зони, доставка день у день чи інтервальні слоти, правила розподілу замовлень між кур'єрами.
- Інтеграції: з якої системи надходять замовлення, чи має вона відкритий інтерфейс обміну, як передаються адреси, вага й склад відправлення.
- Підтвердження вручення: фото, підпис на екрані, код отримувача — і що кур'єр зобов'язаний зафіксувати за відсутності зв'язку.
- Гроші в полі: готівка, термінал, розрахунок зміни й чайових, чи потрібне вивантаження в бухгалтерію.
- Контроль і звітність: які метрики керівництво дивиться щодня — час у дорозі, запізнення, частка невдалих доставок.
Частина даних зазвичай є лише в голові операційного керівника — це нормально.
Опишіть задачу так, як вона виглядає сьогодні, а невідоме ми зафіксуємо як ризики й уточнимо на старті: за підсумками розмови повернемося з оцінкою та планом робіт по застосунку, розбитим за етапами й залежностями.
