Концепт «Обход»

Маршрут продолжается без сети. Осмотр, фотографии и очередь отправки имеют понятное состояние на каждом шаге.

Концепт-проект: «Обход» — вымышленная компания. Результатов работы здесь нет: только решения и гипотезы.

О заказчике

• Сценарий: Осмотр инженерного оборудования в зданиях с нестабильной связью
• Участники: Техник, диспетчер и руководитель технической службы
• Первая версия: Один тип обхода, парк согласованных устройств и один источник заданий
• Данные: Объекты, сотрудники и замечания демонстрационные; оборудование на иллюстрации вымышленное

Задача

В учебном сценарии техническая служба осматривает оборудование в зданиях с нестабильной связью. На маршруте сотрудник открывает список точек, сверяет объект, заполняет чек-лист и прикладывает фотографии. Если форма требует постоянного соединения, работа превращается в заметки на бумаге с повторным вводом в конце смены.

Опаснее всего неопределённый результат отправки. Сотрудник видит заполненный экран, но не понимает, где именно сохранён осмотр. Повторная отправка может создать копию, а изменение задания диспетчером во время обхода требует отдельного решения. Локальная запись ещё не означает, что сервер принял актуальную редакцию.

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

Риски исходного процесса

Заполнение зависит от интернета

Задание и форма доступны локально. Сохранение не требует обращения к серверу после каждого пункта.

Запись есть, а фото потеряно

Текст и каждое вложение получают отдельное состояние. Завершение загрузки осмотра требует подтверждения всего обязательного состава.

Повтор выглядит как новый осмотр

Операция сохраняет идентификатор между попытками. Сервер распознаёт повтор и возвращает прежний результат.

Задание изменили во время обхода

Версия задания проверяется при отправке. Введённые данные остаются доступны для разбора конфликта.

Решение

Первую версию ограничиваем одним типом обхода и согласованным набором устройств. До выхода сотрудник загружает маршрут, редакцию чек-листа и сведения об объектах. На месте приложение пишет изменения в локальное хранилище и показывает статус рядом с конкретным осмотром. Изображения получают собственное состояние загрузки, чтобы заполненный текст не скрывал недоставленные вложения.

У каждой операции есть устойчивый идентификатор. После восстановления связи очередь повторяет отправку, но не создаёт новый осмотр при каждой попытке. Статус «Принято сервером» появляется только после ответа сервера. Если задание изменилось, приложение сохраняет введённые данные и предлагает разобрать конфликт; незаметная перезапись не считается допустимым решением.

Нативную реализацию выбирают после проверки камеры, локального хранения, фоновых ограничений и парка устройств. В демонстрационном HTML-макете можно пройти маршрут и увидеть состояния. Макет не является приложением Swift или Kotlin и не доказывает работу фоновой синхронизации: эти свойства проверяются отдельным устройственным прототипом до промышленного запуска.

Как устроен продукт

1. Маршрут смены. Точки, версия программы и статус локальной загрузки. Зачем: До выхода понятно, готов ли телефон к работе без сети.
2. Объект осмотра. Идентификатор, местоположение и утверждённый чек-лист. Зачем: Похожее оборудование не подменяет нужную точку.
3. Замечание и материалы. Ответы, комментарий и снимки с подтверждением локального сохранения. Зачем: Контекст замечания остаётся рядом с записью.
4. Очередь синхронизации. Осмотры и вложения с причинами задержки и повтором. Зачем: Сотрудник понимает, что ещё не принято сервером.
5. Разбор расхождений. Редакция задания, сохранённые ответы и решение ответственного. Зачем: Изменение задания не уничтожает результаты обхода.

Что помогает пройти сценарий

Сначала локальная запись

Промежуточное состояние «Сохранено на устройстве» не маскируется под доставку.

Объяснимый повтор

Очередь сохраняет запись и показывает результат следующей попытки. В HTML-макете переход между состояниями демонстрационный.

Контекст конфликта

Ответы и редакция задания доступны одновременно. Разбор не начинается с повторного заполнения.

Ключевые сценарии

Завершить осмотр без сети

Сохранить ответы рядом с объектом.

На входе: Маршрут заранее загружен; связи на объекте нет.

1. Открыть точку и сверить код.
2. Заполнить обязательные пункты.
3. Добавить замечание и фото.
4. Сохранить осмотр на устройстве.

На выходе: Запись доступна локально и ожидает синхронизации.

Если что-то пошло не так: Недостаточно места: сохранение не подтверждается, сотрудник видит причину.

Критерий приёмки: После перезапуска запись и файлы доступны без сети.

Синхронизировать очередь

Различить попытку и принятие сервером.

На входе: Устройство снова подключено; есть локальные осмотры.

1. Проверить состояние очереди.
2. Передать операцию с прежним ID.
3. Дождаться приёма ответов и файлов.
4. Показать подтверждённый статус.

На выходе: Осмотр принят сервером; повтор не создаёт копию.

Если что-то пошло не так: Вложение не загружено: статус остаётся неполным.

Критерий приёмки: Повтор той же операции возвращает тот же осмотр.

Разобрать новую редакцию

Сохранить проделанную работу при конфликте.

На входе: Диспетчер обновил задание, пока техник был без сети.

1. Сопоставить версии.
2. Сохранить локальные ответы.
3. Показать изменённые пункты.
4. Передать спорный осмотр ответственному.

На выходе: Данные доступны для решения, автоматической перезаписи нет.

Если что-то пошло не так: Объект исключён из маршрута: дальнейшие действия определяет ответственный.

Критерий приёмки: Ни один заполненный ответ не исчезает при конфликте.

Роли пользователей

Техник

Пройти маршрут и зафиксировать замечание рядом с объектом.

Моя запись точно осталась на телефоне?

Диспетчер

Отличить невыгруженный осмотр от незавершённой работы.

Какие задания требуют связи или уточнения?

Руководитель службы

Проверить полноту осмотров и происхождение замечаний.

Какие данные приняты и по какой программе?

Как устроено технически

Устройство и разрешения

На этапе реализации проверяются камера, файловое хранилище, разрешения и ограничения фонового выполнения целевых ОС.

Локальное хранение

Данные и ссылки на вложения записываются до показа успешного локального сохранения. Тестируется восстановление после принудительного закрытия.

Протокол синхронизации

Идентификатор операции и версия задания передаются с запросом. Повторная доставка и конфликт обрабатываются разными ответами.

Эксплуатация

Регламент определяет хранение фотографий, права на объекты и отзыв доступа. Диагностика не должна раскрывать содержимое осмотров посторонним.

Что входит в разработку

• Один тип маршрута и редакция чек-листа
• Локальные ответы и фото
• Очередь отправки и разбор конфликтов
• API выдачи и приёма осмотров
• Проверка на согласованных реальных устройствах

План реализации

1. Обследование: проверяем маршруты, регламенты и реальные условия связи.
2. Прототип на устройстве: испытываем локальное сохранение, камеру и восстановление после остановки.
3. Первая версия: реализуем один тип осмотра, выдачу заданий и очередь синхронизации.
4. Приёмка: воспроизводим потерю сети, повтор отправки, конфликт редакций и незагруженное фото.

Что замеряем после запуска

• Сохранность без сети — Открываем сохранённый осмотр после остановки приложения; сверяем ответы и файлы.
• Полнота синхронизации — Разрываем отправку между текстом и фото; принятым считается только подтверждённый состав.
• Повтор без копии — Повторяем запрос с тем же идентификатором и сверяем число записей на сервере.
• Конфликт без потери — Меняем задание до синхронизации и проверяем сохранение введённых данных.

Стек

Swift, Kotlin, Локальная база данных, API синхронизации.

Все кейсы · Услуга · Калькулятор стоимости

Шесть экранов и рабочие состояния

Четыре настольных и два мобильных экрана авторского HTML-макета. Демонстрационные данные показывают логику решения, а не работающий продукт заказчика.