Чому мобільний застосунок для управління проєктами втрачає дані
Типовий збій виглядає так: інженер на об'єкті без мережі закриває задачі, переносить терміни, дописує коментарі — усе це осідає в локальній черзі змін на пристрої.
Коли мережа з'являється, мобільний клієнт проєкту надсилає накопичене, і частина правок не доходить: на сервері вже лежить новіша версія запису, і надіслане мовчки затирається.
Користувач бачить «збережено», а в загальному списку задачі стоїть старий термін — втрату правок виявляють через день, на планірці.
Друга половина проблеми — дублі. Повторне надсилання після тайм-ауту створює задачу вдруге, до неї прив'язуються два виконавці й два набори чек-лістів, а лічильники трудовитрат розходяться.
Якщо офлайн-синхронізація не позначає кожну зміну унікальним ідентифікатором операції, відрізнити справжній новий запис від повторного надсилання вже неможливо, і розбирати це доводиться вручну.
Конфлікти версій оголюються там, де двоє правлять одну задачу з різних пристроїв. Злиття за окремими полями — статус, термін, виконавець — зберігає обидві правки, а злиття «за всім записом цілком» залишає лише останню: чужа робота зникає без сліду й без запису в історії.
Окремо ламається робота без мережі на довгих змінах: черга зростає, пристрій агресивно економить живлення, і фонове надсилання просто не встигає завершитися до виходу із застосунку.
Ціна цього збою вимірювана: терміни в системі перестають збігатися з реальністю, керівник ухвалює рішення за застарілою картиною, а команда заводить паралельну таблицю «про всяк випадок».
Довіра до системи падає швидше, ніж зростає обсяг втрачених даних, і повернути її складніше, ніж полагодити саму синхронізацію. Розбираємо, як це закривається.
Що дає офлайн-синхронізація: втрачені правки, простій, терміни
Раніше офлайн-зміна виглядала так: правки накопичуються в телефоні, а при виході в мережу частина затирається — перемагає той, хто зберіг останнім.
Коректна синхронізація прибирає клас відмов цілком: кожна дія потрапляє до локального журналу з автором і часом і досилається в початковому порядку. Питання «правка не доїхала чи її не було» перестає виникати.
Час синхронізації вимірюється не фактом з'єднання, а затримкою до того, як чужі зміни побачить уся команда. Досилка йде дельтою — лише змінені поля — і у фоні, тому короткого вікна мережі на об'єкті вистачає.
Накопичене за зміну сходиться за секунди після появи каналу, а не при наступному запуску застосунку.
Простій бригад — друга стаття втрат: поки наряд не підтверджено на сервері, виконавець або чекає, або працює з пам'яті й потім перепитує. Локальна копія підтвердженої версії проєкту та черга вихідних правок знімають очікування: простій зміщується з годин на хвилини.
Повторне введення даних раніше було нормою: зміну закривали на папері, ввечері переносили в систему. Коли правки зводяться за полями, дві правки однієї задачі — одна змінює термін, інша виконавця — зберігаються обидві, і переписувати нічого.
Що вимірювати після впровадження: частку втрачених правок, час від появи мережі до зведення даних, кількість повторних введень і кількість конфліктів, які все ж доходять до людини.
Останній показник чесніший за інших — він показує, скільки розбіжностей система не змогла вирішити сама.
Режими офлайн-синхронізації: повна, часткова, подієва
Режим обміну обирають не за зручністю платформи, а за трьома вхідними: скільки даних потрібно людині в полі, скільки вона готова чекати при першому вході й наскільки стійкий канал зв'язку. Нижче — три робочі схеми, які ми комбінуємо в одному застосунку управління проєктами.
| Режим | Коли підходить | Чим обмежений на практиці |
|---|---|---|
| Повне вивантаження | Виїзна робота, де задачі, терміни та зв'язки між ними потрібні цілком і одразу | Перший вхід розтягується, локальне сховище займає помітну частку пристрою, кожен обмін пересилає зайве |
| Часткова синхронізація | Людина веде 2-3 проєкти й бачить лише свою ділянку: завантаження за проєктом, командою або періодом | Межі треба описати заздалегідь — що робити із задачами, які випали з вибірки, і як дотягувати їхні зв'язки |
| Подієва синхронізація | Після первинного завантаження змінюються окремі поля: статуси, коментарі, оцінки, вкладення | Без базового шару подію нема до чого застосувати; потрібен журнал операцій і однозначне правило розв'язання конфліктів |
На практиці чистий режим трапляється рідко: базовий шар завантажується один раз, далі йде подієвий обмін, а часткова вибірка обмежує обсяг для тих, хто працює лише у своєму напрямі. Ключове тут — версіонування записів і правило пріоритету правок, інакше зміни губляться мовчки.
Межі обирають під сценарій, а не «на майбутнє»: зайві дані в локальному сховищі — це час синхронізації й конфлікти на рівному місці.
Етапи впровадження: від аудиту сценаріїв до передачі регламентів
Порядок робіт вибудувано так, щоб поведінка без мережі перестала бути сюрпризом у промисловій експлуатації.
Спочатку фіксуємо, що співробітник реально робить в офлайні, і лише потім проєктуємо обмін — інакше схема синхронізації обростає окремими випадками, які неможливо перевірити.
-
Аудит сценаріїв. Розбираємо операції, які виконуються без зв'язку: правка задачі, зміна статусу, коментарі, вкладення, списання часу. Позначаємо те, що не можна відкладати, — такі дії блокуємо до появи мережі.
-
Схема синхронізації. Визначаємо одиницю обміну й джерело істини, формат локального журналу змін і позначку останнього узгодження. Від цього залежить, скільки даних іде при поверненні в мережу і як швидко відкривається проєкт із сотнями задач.
-
Налаштування обміну. Задаємо тригери — поява зв'язку, таймер, дія користувача, — розмір порції та кількість повторів при обриві. Окремо описуємо, що буде, якщо пристрій вимкнули до завершення вивантаження.
-
Розв'язання конфліктів. Правила задаються за типами полів: де достатньо останнього запису, де значення об'єднуються, де рішення віддається людині з показом обох версій. Правки двох інженерів в одній задачі не перетворюються на втрачені дані.
-
Перевірка на реальних даних. Ганяємо копію робочого проєкту: довгі ланцюжки правок без мережі, одна задача з двох пристроїв, переведення часу, оновлення застосунку поверх локальної бази. Кожен збій розбираємо до відтворюваного випадку.
-
Передача регламентів. Віддаємо правила експлуатації: як читати стан черги, що робити із завислим записом, як вивантажити журнал для розбору. Підтримка отримує інструкції до запуску, а не після перших звернень.
Що передаємо на руки: схеми, правила синхронізації, регламенти
Передача проєкту — це не архів з вихідниками, а набір артефактів, за якими ваш штат або інша команда продовжує роботу без розбору чужої логіки. Усе, що визначає поведінку застосунку, фіксується письмово й переходить на руки разом із доступами. Нижче — що саме входить до комплекту.
- Схеми даних — структура локального сховища, зв'язок із серверними сутностями, порядок міграцій: нове поле не ламає застосунок на старих версіях.
- Політика доступу — матриця ролей і прав на читання, запис і видалення, поведінка системи при відкликанні доступу в співробітника.
- Правила синхронізації — що і коли йде на сервер, як поводиться черга операцій в офлайні, за якими тригерами запускається обмін.
- Розв'язання конфліктів — за яким полем порівнюються версії запису, чия зміна пріоритетна, як конфлікт бачить користувач.
- Регламент роботи — порядок випуску оновлень, перевірок і узгодження релізу, зони відповідальності.
- Інструкції для співробітників — сценарії мовою користувача: конфлікт, повернення з офлайну, повідомлення про збій.
- Порядок підтримки — рівні звернень, терміни реакції, відповідальні, передача доступів до репозиторію й моніторингу.
Комплект залишається робочим документом: за ним вводять нового розробника, проходять перевірку безпеки й планують розвиток продукту.
Кейс: виїзні роботи та синхронізація задач бригад
Замовник — сервісна компанія з виїзними бригадами: монтажники працюють на об'єктах, де зв'язок є лише в прорабській. Заявки й фотозвіти йшли через месенджери, а диспетчер увечері переносив їх у Битрикс24. До кінця тижня черга перенесення розтягувалася на дві доби.
Що ламалося до впровадження
Двоє монтажників брали одну заявку й виконували роботу двічі: правки затирали одна одну при збереженні. Фотозвіти зникали, якщо застосунок закривався без мережі. Диспетчер розподіляв задачі з пам'яті, бо не бачив, хто вже на об'єкті.
| Що міряли | До | Після |
|---|---|---|
| Заявки з розбіжністю статусів | 1 із 6 | менш ніж 1 із 100 |
| Затримка перенесення наряду | до 2 діб | хвилини після появи зв'язку |
| Втрачені фотозвіти | щотижня | 0 |
| Звірка даних у диспетчера | 3–4 години на день | близько півгодини |
Що змінилося в механіці
Дії бригад пишуться в локальну базу й ідуть на сервер чергою, коли зв'язок з'являється. Кожна операція має власний ідентифікатор, тому повторне надсилання після обриву не створює дубліката.
Конфлікти розв'язуються за часом останньої зміни: правка, зроблена в тунелі пізніше, не затирається ранішою.
Сценарії обриву проганяли вручну: вимикали зв'язок на середині обходу, перезапускали застосунок, дублювали надсилання — дані сходяться. Повторювані відмови пішли: подвійні призначення, втрачені фото, ручна звірка. Диспетчер займається розподілом задач, а не зіставленням двох версій списку.
Чим офлайн-синхронізація відрізняється від звичайного кешування?
Різниця в тому, де під час роботи перебуває джерело істини. Кеш — це копія даних для читання: вона прискорює список задач і картки проєктів, але будь-яка зміна йде в мережу, і поки відповідь не повернулася, запис вважається непідтвердженим.
Обірвався зв'язок — інтерфейс показує дані, але прийняти правку не може, і співробітник бачить «збережено», якого насправді не було.
Офлайн-режим улаштований інакше: запис іде в локальну базу, а операції — створення, перейменування, зміна статусу, коментар, вкладення — складаються в чергу з порядком застосування.
Поки мережа недоступна, джерелом істини для клієнта стає пристрій, і застосунок продовжує працювати повноцінно, а не в режимі перегляду.
Коли зв'язок повертається, вмикається зворотне злиття: черга розбирається за порядком, операції застосовуються на сервері, а результат повертається на пристрій — уже з серверними версіями записів.
Ключове тут — розв'язання конфліктів, коли ту саму задачу на сервері встиг змінити хтось інший: потрібні версії записів і позначки часу, щоб рішення було передбачуваним, а не «перемагає той, хто синхронізувався останнім».
Підміна одного іншим і дає втрати. Кеш поверх конкурентної роботи із задачами створює дублі й «воскреслі» картки при повторному надсиланні, губить правки при очищенні сховища й не вміє пояснити користувачеві, що сталося з його зміною.
Тому в застосунку для управління проєктами офлайн-режим проєктується окремо: з журналом операцій, правилами злиття і явною індикацією стану синхронізації.
Розбір технічних питань перед стартом робіт
Перед стартом замовник перевіряє три речі: що станеться з даними, якщо співробітник тиждень не вийде в мережу, хто побачить задачі при втраті планшета і скільки від наявного застосунку залишиться живим. Нижче — короткі відповіді з кожного пункту; нестандартні сценарії розбираємо окремо, вже на оцінці.
Як довго застосунок працює без мережі?
Обмеження не в обсязі локального сховища, а в розв'язанні конфліктів. Доступні користувачеві проєкти, задачі й коментарі лежать на пристрої цілком, тому правки вносяться офлайн, а черга операцій програється за порядком, коли зв'язок з'явився.
Якщо той самий пункт змінили двоє, перемагає пізніша правка, а попередня версія залишається в історії задачі — переписати чи втратити текст неможливо.
Наскільки захищені дані на самому пристрої?
Локальна копія шифрується, ключ зберігається в захищеному модулі пристрою й назовні не віддається; вхід — за біометрією або системним кодом.
Перевірку прав ми будуємо за рекомендаціями OWASP для мобільних застосунків: сервер залишається джерелом істини й переперевіряє доступ при кожній синхронізації, а не довіряє рішенню, ухваленому на пристрої.
Пристрій втратили — дані витечуть назовні?
Робочу копію стирають віддалено: застосунок знищує і локальне сховище, і ключ, після чого прочитати залишки без сервера неможливо. Єдине, чим ризикує компанія, — правки, які не встигли піти на сервер; їхній обсяг обмежений вікном між останньою синхронізацією і втратою. Це вікно ми налаштовуємо під ваш регламент.
Наявний застосунок доведеться переписувати заново?
Починаємо з аудиту: карта екранів, шари даних, обсяг коду, який можна перевикористати. Найчастіше інтерфейс і бізнес-логіка переносяться, а замінюються зберігання, синхронізація й розбір конфліктів — плюс разова міграція даних без простою. Обсяг переробки фіксуємо етапами, щоб ви бачили, що отримуєте на кожному.
Обговоримо задачу й повернемося з планом синхронізації
Щоб повернутися з оцінкою робіт, а не із загальними словами, на першій розмові нам потрібно зрозуміти, як улаштовані ваші дані й як співробітники працюють у полі. Відповіді можна давати приблизно — деталі уточнимо за вашими схемами й серверними інтерфейсами.
- Які сутності правляться в офлайні — задачі, коментарі, вкладення, статуси — і що критично не втратити при обриві зв'язку.
- Як зараз іде обмін із сервером: повне вивантаження чи інкрементальне, чи є позначки змін і стабільні ідентифікатори записів.
- Хто з ким конфліктує: два інженери в одній задачі, правка з телефона й із веб-панелі, пакетні оновлення на сервері.
- Який режим розв'язання конфліктів прийнятний: перемагає остання правка, злиття за полями чи ручний розбір.
- Вимоги до доступів і зберігання: офлайн-вхід, шифрування локальної бази, строк життя черги невідправлених операцій.
- Що вже є в проєкті: мобільний клієнт, серверна частина, розмежування прав, тестовий контур — від цього залежить обсяг робіт.
- Обсяг первинної синхронізації: скільки записів і вкладень пристрій забирає при першому вході.
У відповідь надсилаємо план впровадження за етапами: схему синхронізації з правилами злиття, порядок підготовки даних і міграції, склад робіт по клієнту й серверу, критерії приймання й терміни. Оцінка спирається на ваші сценарії, а не на середні числа по ринку.
