Концепт «Выезд»

Задания, фотографии и отчёты, которые сохраняются на объекте даже без интернета.

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

О заказчике

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

Задача

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

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

Главный риск не в красивом списке заданий, а в потере результата. Поэтому сценарии закрытия приложения, нехватки места, просроченной сессии и параллельного изменения задания диспетчером рассматриваем вместе с основным маршрутом.

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

Интернет пропадает на объекте

Сохраняем заполненные поля и статус операции локально. Плашка «На устройстве» отличается от «Синхронизировано», чтобы сотрудник понимал, что увидит диспетчер.

Фото не связано с заданием

Снимок добавляется из карточки выезда и хранит идентификатор задания. Перед загрузкой можно проверить изображение; отсутствие фотографии имеет понятную причину.

Отчёт приходится переписывать

Чек-лист и использованные материалы формируют черновик отчёта по мере работы. Итоговая проверка оставляет возможность исправить ошибку.

Задание меняется параллельно

Версия сервера сравнивается с локальной. Перенос адреса или отмена выезда не затирают уже выполненные действия без уведомления.

Решение

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

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

Чек-лист зависит от типа оборудования. Обязательная фотография или измерение блокируют завершение только по заранее согласованным правилам. Перед отправкой инженер видит итог: что сделано, какие материалы списаны, что требует повторного визита. Диспетчер получает структурированный отчёт, а не набор несвязанных сообщений.

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

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

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

Задание доступно заранее

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

Короткое закрытие работы

Отчёт собирается из чек-листа, фото и материалов. Перед закрытием показываем только недостающие обязательные пункты, а не повторяем всю анкету.

Повторный выезд с историей

Причина незавершённой работы остаётся в карточке. Новое задание наследует контекст, но имеет собственный идентификатор и отдельный отчёт.

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

Принять выезд

Инженер готовит рабочую карточку до поездки.

На входе: Назначенное задание, адрес, контакт объекта и инструкция по оборудованию.

1. Проверить окно визита и состав работ
2. Загрузить карточку и вложения
3. Подтвердить готовность к выезду

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

Если что-то пошло не так: Если часть файлов не загрузилась, это видно до выезда; система не обещает полный офлайн-доступ.

Критерий приёмки: После отключения сети загруженная карточка открывается. Отмена задания при синхронизации видна сотруднику.

Работать без связи

Инженер выполняет чек-лист и сохраняет результат локально.

На входе: Загруженная карточка, обязательные измерения и разрешение на использование камеры.

1. Заполнить чек-лист
2. Приложить фото и использованные материалы
3. Проверить черновик отчёта

На выходе: Отчёт на устройстве, ожидающий подтверждения сервером.

Если что-то пошло не так: При закрытии приложения черновик восстанавливается; недостаток места блокирует снимок с объяснением.

Критерий приёмки: Перезапуск не теряет введённое. На экране нет ложного статуса «Диспетчер получил отчёт».

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

Связь восстановилась, операции передаются диспетчеру.

На входе: Локальная очередь, актуальная сессия и версия задания.

1. Отправить изменения с исходными идентификаторами
2. Дождаться подтверждения вложений
3. Разрешить конфликт, если задание изменилось

На выходе: Один серверный отчёт с подтверждёнными вложениями и временем приёма.

Если что-то пошло не так: При тайм-ауте повторяем ту же операцию. Конфликт не исправляется молчаливой перезаписью.

Критерий приёмки: Повторное соединение не создаёт дубль. Статус «Синхронизировано» появляется только после подтверждения всех обязательных данных.

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

Выездной инженер

Выполняет работу и фиксирует результат на объекте.

Сохранился ли мой отчёт, если связи нет?

Диспетчер

Назначает исполнителя и разбирает переносы и повторные визиты.

Какие задания подтверждены, а какие ещё синхронизируются?

Руководитель сервиса

Проверяет полноту отчётов и повторяющиеся проблемы.

Где теряется время: в дороге, работе или оформлении?

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

Flutter и платформенные модули

Предлагаем общую часть интерфейса для iOS и Android. Доступ к камере, файлам и фоновой работе проверяется отдельно на поддерживаемых версиях ОС.

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

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

API синхронизации

Идемпотентные операции, версия задания, отдельная загрузка вложений и контроль конфликтов. Сервер подтверждает каждый принятый результат.

Безопасность и наблюдаемость

Сессии сотрудников, ограничение доступа к объектам и журнал ошибок без контактных данных клиента. Срок хранения локальных материалов определяется до пилота.

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

• Карта процесса выездного сервиса и матрица ролей
• Прототип основных экранов и офлайн-состояний
• Мобильный клиент, локальные черновики и очередь операций
• API заданий, вложения и разрешение конфликтов
• Связь с существующей CRM или диспетчерским кабинетом
• Проверка на устройствах, пилот и инструкция для диспетчера

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

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

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

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

Стек

Flutter и платформенные модули, Локальное хранилище, API синхронизации, Безопасность и наблюдаемость.

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

Визуализация продукта

Изображение создано с помощью ИИ для демонстрационного проекта. Компания, задания и параметры вымышлены; это не скриншот работающего клиентского продукта.