Чому мобільний застосунок кур’єрської служби буксує в полі
Кур’єр приймає замовлення в підвалі або за містом: застосунок показує «прийнято», а на диспетчерському екрані замовлення немає. Слабкий канал обірвав відправлення, локальна черга запис не втримала, повтор не передбачено — і клієнт чекає на кур’єра, який уже поїхав на іншу адресу.
Формально замовлення прийнято — для системи воно не існує; так виглядає втрата замовлень за слабкого зв’язку.
Статуси доставки зависають до кінця зміни. Офлайн-режим кур’єра працює лише на читання: останні дані показати можна, надіслати новий стан — ні.
Позначки «доставлено», «відмова», «перенесення» пишуться поверх попереднього стану без черги й повторного надсилання, тому під час перемикання між мережами частина подій губиться, а з поверненням зв’язку приходить дублями.
Диспетчер бачить «у дорозі» там, де замовлення закрито годину тому, і обдзвонює кур’єрів, щоб відновити картину дня.
Третє джерело збоїв — ручне введення адреси. Кур’єр набирає вулицю й будинок текстом, помилка в одну цифру перетворюється на виїзд не туди та повторну доставку.
Підтримка тоне в уточнювальних дзвінках: у час пік вони йдуть потоком і витісняють розбір реальних збоїв, а навантаження на диспетчера зростає разом із кількістю кур’єрів на лінії.
Ціна цих дефектів — втрачені замовлення, недостовірні статуси й диспетчер, який вручну склеює дані за дзвінками. Розбираємо, як це закривається.
Що змінюється у зміні кур’єра: чотири вимірювані ефекти
Ефект видно у зміні, а не у відгуках: скільки адрес кур’єр закриває за годину, скільки замовлень іде в підтримку і що відбувається, коли зникає зв’язок. За кожним пунктом нижче є метрика, яку можна зняти до впровадження і після.
Швидкість закриття замовлення
Вручення позначається одним дотиком, статус іде в диспетчерську одразу — без дзвінка й вечірнього зведення накладних. Розрив між фактичною передачею замовлення та його закриттям у системі стискається з годин до секунд, а час, що звільнився, іде на додаткові адреси.
Офлайн-синхронізація: зв’язок зник, зміна триває
Підвал, ліфт, заміська ділянка — позначки, фото й підписи лягають у локальну чергу, і робота не переривається. Коли з’являється мережа, черга йде на сервер за порядком, без дублів і втрачених статусів, тому після збою зв’язку не потрібен ручний розбір зміни.
Контроль статусів доставки без звернень у підтримку
Кожен перехід — «у дорозі», «на місці», «вручено» — фіксується з часом і позицією, а рух кур’єра диспетчер і клієнт бачать на карті в сервісі Яндекс Карты. Питання «де моє замовлення» закривається екраном відстеження, і частка замовлень без дзвінків у підтримку зростає кратно.
Ручних операцій менше, помилок введення немає
Адреса й склад замовлення підтягуються з накладної, вручення підтверджується сканом замість передруковування номера. Розбіжності ловить система на вході, а не розбір наприкінці дня, — клас помилок ручного введення зникає цілком.
Варіанти розробки: готова платформа, конструктор, власна збірка
На старті всі чотири шляхи виглядають схоже: карта, статуси замовлення, повідомлення про призначення кур’єра. Різниця проявляється на обсязі замовлень, під час зміни схеми розрахунків із кур’єрами і коли до застосунку потрібно підключити власний диспетчерський контур.
Як вибрати під розмір парку та логіку замовлень
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готова платформа доставки | Парк до 50 кур’єрів, типові замовлення, запуск у стислі строки | Маршрути й тарифи задані вендором, власні правила — лише через загальну чергу доопрацювань |
| Конструктор застосунків | Потрібен швидкий випуск і проста вітрина замовлень | Екрани збираються з чужих блоків, нестандартний крок оформлення потребує зовнішнього модуля |
| Розробка під задачу | Власна логіка розподілу замовлень, обмін з обліковою системою, парк зростає | Довший вхід, потрібен власний релізний контур і постійна підтримка |
| Доопрацювання поточного рішення | Застосунок працює, але впирається в стелю за функціями | Залежність від коду попереднього підрядника, спочатку ревізія і перенесення збірки |
Де впираються на другий рік
У платформи стеля настає, коли з’являється другий тип кур’єра або зона з іншими правилами — ядро під них не перебудовується. Конструктор починає гальмувати на кількості екранів і зв’язків, а оновлення чужих модулів ідуть за чужим графіком.
Власна збірка вимагає тримати сумісність з актуальними версіями систем і перевіряти роботу на слабкому зв’язку та старих пристроях. Доопрацювання чужого коду без ревізії майже завжди чекає другий виток переробок.
Етапи впровадження: від розбору процесів до передачі проєкту
Поки застосунок не зібрано, процеси доставки живуть у голові диспетчера й у листуванні. Тому починаємо не з коду, а з розбору маршруту замовлення: які статуси змінюються, де з’являється папір, де кур’єр дзвонить в офіс, щоб уточнити адресу.
- Розбір процесів доставки — ідемо у зміну й фіксуємо реальний шлях замовлення: прийом, розподіл, видача, підтвердження, повернення. Позначаємо місця, де дані вводять двічі.
- Схема обміну даними — описуємо сутності замовлення, адреси, інтервалу доставки, статусу й підпису одержувача, напрямки синхронізації та поведінку застосунку без мережі.
- Ролі й права — кур’єр, диспетчер, логіст, адміністратор: що кожен бачить і змінює, які дії потребують підтвердження.
- Збірка та зв’язка з обліковою системою — інтерфейси під роботу однією рукою, черга невідправлених позначок, журнал дій.
- Польова перевірка на реальних змінах — слабкий зв’язок, старі пристрої, вечірні адреси.
- Передача й навчання — інструкції, регламент розбору збоїв, доступи, порядок оновлень.
Пілот на одній зміні
Запускаємо на одному екіпажі й одній зміні з обмеженою кількістю замовлень. Рахуємо час на позначку статусу, дивимося, де рветься синхронізація і скільки кур’єр кличе диспетчера. Так сира збірка не йде на весь парк.
Критерії приймання
Приймання йде за вимірюваними показниками: частка замовлень, закритих без дзвінка в офіс, час на одну доставку, частка позначок, що дійшли до системи без ручної правки, кількість відмов за зміну. Поки збіжності немає, етап не закрито.
Артефакти проєкту: збірки застосунку, схеми, регламенти
Проєкт здається не папкою з вихідним кодом, а комплектом, за яким застосунок можна розвивати без нас. Усе, що створюється по ходу роботи, залишається у сховищах і облікових системах замовника разом з описом, як цим користуватися.
- готові збірки для магазинів застосунків — підписані, з описом версії, яку можна викотити повторно;
- схема обміну з обліковою системою: які сутності синхронізуються, як часто і що відбувається при обриві зв’язку;
- матриця ролей і прав: кур’єр, диспетчер, логіст, адміністратор — що кожен бачить і змінює;
- регламент підтримки: канали звернень, час реакції за класами збоїв, порядок ескалації;
- інструкція для кур’єрів: встановлення, вхід, робота із замовленням, дії при втраті мережі;
- порядок випуску оновлень: хто погоджує, як перевіряється збірка, як виконується відкат;
- опис збірки й середовищ — щоб реліз відтворювався на чистій машині без нас.
Права доступу та матриця ролей
Матриця задає не лише видимі екрани, а й доступ до даних: кур’єр бачить тільки свої замовлення і не править накладну, логіст розподіляє й перепризначає, адміністратор веде довідники. Окремо описані обмеження за точкою видачі та територією.
Порядок випуску оновлень
Збірка спочатку йде в тестовий контур і перевіряється на реальних сценаріях маршруту, потім викочується поступово — спершу на групу кур’єрів, потім на всіх. Відкат розписано покроково: як повернути попередню версію, якщо за зміну зросла частка помилок.
Кейс: як скоротили втрати замовлень у час пік
Кур’єрська служба з парком у кілька сотень виконавців прийшла з проблемою у вечірній час пік: частина замовлень залишалася без кур’єра. Замовлення висіло в черзі, клієнт дзвонив у підтримку, а виконавець відмовлявся від пропозиції, не розуміючи реального обсягу роботи.
Метрики до і після на діючому парку
Рахували не середні за день, а окремо пікові дві години — саме там губилися замовлення. Заміри знімали до запуску і через місяць роботи на тому ж парку, без виділених «еталонних» кур’єрів:
- частка втрачених замовлень у час пік — 11% → 2%;
- час закриття адреси — 8,5 → 5 хвилин;
- звернення в підтримку щодо статусу замовлення — скоротилися втричі;
- замовлень на виконавця в час пік — на 20% більше.
Що змінювали в процесах, а не лише в застосунку
Застосунок не був єдиною точкою правки: переписали правила розподілу — пріоритет найближчому кур’єру з урахуванням часу закриття адреси, а не порядкового номера замовлення.
Ввели зрозумілу статусну модель, щоб диспетчер бачив зависле замовлення до дзвінка клієнта, і навчили зміну працювати з нею. Прогноз часу прибуття перерахували на даних картографічного сервісу Яндекс.Карты з урахуванням заторів.
Результат впровадження тримається на цих двох шарах: інтерфейс знімає зайві дії, а правила розподілу не дають замовленню залишитися без виконавця. Через півроку після запуску частка втрачених замовлень у час пік залишилася на рівні 2-3% при зростаючому обсязі.
Чим доопрацювання готового рішення відрізняється від збірки з нуля
Доопрацювання готового рішення зберігає працюючий контур: довідники, історію замовлень, облікові записи кур’єрів і налаштовані обміни з обліковим контуром 1С.
Перенесення даних тут — передбачувана операція: вивантаження, зіставлення полів, завантаження в нову схему, займає дні, а не місяці. А от логіка переноситься рідко — розширення, написані в обхід ядра, живуть за своїми правилами і часто не мають точки підключення в чужій збірці.
Упори готової платформи починаються там, де вимога розходиться із закладеною моделлю.
Офлайн-робота кур’єра, фонова передача геопозиції, нестандартна черга розподілу замовлень, тонкі права на підміну й передачу зміни — якщо це закрито всередині модуля, доопрацювання перетворюється на надбудову над чужим кодом. Вона тримається до першого великого оновлення.
Сумісність версій — другий обмежувач. Оновлення ядра змінює контракти, і кожне розширення проходить повторну перевірку. Два-три випуски поспіль із поломками доопрацювань — сигнал, що вартість володіння зростає швидше, ніж продукт.
Збірка з нуля виграє, коли більше третини ключових сценаріїв впирається в закриті модулі або строки перезапуску коротші, ніж шлях послідовних доопрацювань.
Тоді ми фіксуємо склад даних для перенесення, проєктуємо схему під реальні сценарії зміни й виводимо перший робочий випуск раніше, ніж надбудова над платформою дійшла б до того ж обсягу. Опишіть вашу ситуацію — повернемося з оцінкою та планом, де саме проходить точка розвороту.
Часті сумніви: зв’язок, батарея, облікова система
Сумніви тут не про інтерфейс, а про зміну загалом: зв’язок у під’їздах і підвалах, заряд до вечора, старі апарати в парку і вже працююча облікова система. Нижче — як ці місця закриті архітектурно, а не обіцянками.
Що буде з нарядом при перебоях зв’язку?
Кур’єр працює в локальній черзі: статуси, позначки про вручення й фото пишуться на пристрій, а йдуть при появі мережі. У кожної операції свій ключ-ідентифікатор, тому повторне надсилання не створює дубль наряду.
Чи потягне застосунок бюджетний апарат?
Екран нарядів — легкий список без важкої карти, фонова активність обмежена, дані приходять порціями. На апаратах минулих років зміна йде без підвисань при великій історії замовлень.
Скільки заряду йде за зміну?
Координати йдуть пакетами з адаптивною частотою: у русі частіше, на стоянці рідше; у фоні опитування сервера немає — події приходять повідомленням. Типовий смартфон витримує зміну без зовнішнього акумулятора.
Як застосунок стикується з обліковою системою?
Застосунок не пише в облікову систему напряму: операції йдуть через шар інтеграції за описаними правилами. Це дає звірку статусів, повтор при збої та розбір розбіжностей, якщо облікова система недоступна.
Оновлення зупинить зміну?
Ні: версії викочуються поетапно, встановлення відкладається до кінця зміни, а попередній клієнт працює із сервером до примусового порогу. Кур’єр не залишається без наряду через випуск оновлення.
Старт робіт: склад змін, схема обміну, порядок оцінки
Щоб повернутися з оцінкою та планом за етапами, а не з широким діапазоном, потрібен мінімальний, але конкретний набір вхідних даних.
Застосунок кур’єра живе на стику пристроїв у полі та облікової системи в офісі — майже вся трудомісткість визначається тим, наскільки докладно описано цей стик.
- Склад ролей і змін: кур’єр, диспетчер, сортувальник, керівник зміни — і як замовлення передаються між змінами, включно з нічними вікнами.
- Приклади обміну з обліковою системою: 3–5 реальних вивантажень — замовлення, статус, скасування, закриття наряду. За ними видно обов’язкові поля та поведінку при недоступності сервісу.
- Обмеження за пристроями: моделі й версії операційних систем у парку, чи потрібен офлайн-режим і на скільки годин, чи є сканери й принтери етикеток.
- Правила роботи з даними: де зберігаються персональні дані одержувачів, чи потрібне підтвердження доставки фото й підписом.
- Точки контролю та порядок погодження: які етапи приймаєте особисто — схема обміну, прототип, збірка, тестовий контур, випуск; під кожну точку — критерій приймання.
- Контур рішень: хто з боку замовника відповідає на питання і в який строк — це впливає на план не менше за обсяг робіт.
З цього збираємо план за етапами з оцінкою трудозатрат і явними допущеннями: видно, що робиться на кожному кроці і де ви приймаєте результат.
