Мобильное приложение для инженеров лифтов: как собрать офлайн заявки, чек-листы ТО и фотоотчеты, синхронизацию и серверные endpoints без лишней сложности.
Когда инженер приезжает на объект, ему важно зафиксировать факты сразу, а не вспоминать их вечером по фото в телефоне. На месте нужны конкретные данные: адрес и подъезд, номер лифта или станции, какой узел проверяли (двери, приводы, замки, контроллер), что сделали, какие материалы и запчасти ушли, кто принял работу. Если это не собрать на объекте, отчет получается «примерный», а спорные моменты потом решаются долго.
Связь в подвале, машинном помещении или шахте часто нестабильная. Поэтому приложение должно нормально работать офлайн: форма открывается, данные сохраняются, фото прикрепляются, а отправка происходит позже, когда сеть появится. Иначе инженер либо откладывает заполнение, либо ведет дублирование на бумаге.
Обычно процесс ломается в трех местах: записи на бумаге теряются или нечитаемы, в мессенджерах смешиваются рабочие и личные чаты, а фото «уезжают» в общую галерею без привязки к заявке. Через неделю найти нужный снимок двери шахты «до ремонта» почти невозможно.
Для старта хватит минимального набора:
Практичный сценарий простой: инженер на месте фиксирует замену ролика, делает два фото, отмечает расходник и закрывает заявку. Приложение сохраняет все локально и отправляет на сервер позже.
Если нужно быстро собрать такой MVP, это удобно делать на TakProsto (takprosto.ai): можно описать экраны и правила офлайна, а затем получить базовый Flutter-клиент и серверные методы приема заявок и фото без долгой ручной сборки.
Чтобы приложение не превратилось в «комбайн», держите структуру простой: один поток работы (заявка) и два вида подтверждения результата (чек-лист ТО и фото). Тогда инженеру понятно, что делать в поле, а диспетчеру и мастеру участка проще контролировать картину.
Роли обычно распределяются так: инженер закрывает работы и прикладывает материалы, диспетчер создает и уточняет заявки, мастер участка смотрит нагрузку и качество, админ ведет справочники и доступы. Это лучше заложить сразу, чтобы права были очевидны. Например, инженер не меняет справочник причин, но может предложить новый вариант через комментарий.
Сущности держите «тонкими» и связывайте напрямую:
По статусам заявки часто хватает четырех: создана, в работе, выполнена, требует уточнений. Последний статус спасает от «фальшивых закрытий», когда на объекте выяснилось, что нужен допуск, запчасть или другой специалист.
Справочники лучше вынести отдельно: виды работ, причины, материалы, типовые дефекты. Тогда инженер в офлайн-форме выбирает из списка вместо длинного текста, а отчеты потом собираются без ручной чистки.
Пример: инженер на выезде отмечает в чек-листе «проверка дверных замков», выбирает материал «смазка», добавляет фото «до/после». В карточке заявки это выглядит как цельная история, а не набор разрозненных сообщений.
В полевой работе выигрывает не самый красивый интерфейс, а тот, который дает закрыть заявку за минуты, одной рукой и без лишних переключений.
Обычно достаточно нескольких экранов: список заявок с быстрыми фильтрами, карточка заявки (адрес, контакт, задача, история), чек-лист работ ТО или ремонта, фото (камера и просмотр прикрепленных снимков), черновики с незавершенными отчетами.
Дальше решает состав полей. Обязательными делайте только то, без чего заявка не может считаться закрытой: статус, причина (если не выполнено), минимум один результат по чек-листу, подпись или отметка о невозможности подписи. Остальное (комментарий, дополнительные измерения, дополнительные фото) лучше оставить опциональным, чтобы не тормозить закрытие.
Чтобы ввод был быстрым, помогают простые приемы: шаблоны работ, подсказки рядом с полем (например, «12 мм», «220 В»), автозаполнение (инженер, бригада, тип лифта, адрес из заявки), кнопка «повторить как в прошлый раз» для регулярных ТО, крупные элементы управления и минимум текста на экране.
Черновик сохраняйте автоматически: после каждого изменения пишите локально и показывайте ненавязчивую метку «Сохранено». Сценарий из жизни: инженер зашел в подвал, связь пропала, он отметил 7 пунктов чек-листа и сделал 3 фото. При возврате приложение открывает тот же черновик и предлагает продолжить.
В поле интернет часто пропадает: в подвале, шахте, машинном помещении, старом доме. Поэтому офлайн режим - не «приятный бонус», а базовая функция. Главное правило простое: инженер должен уехать с объекта с заполненным отчетом, даже если связи не было ни минуты.
Без интернета должно получаться: открыть список своих заявок (хотя бы последние), заполнить форму работ и чек-лист ТО, добавить фото и комментарии. Если приложение требует сеть для каждого шага, люди возвращаются к блокнотам и мессенджерам.
Локальное хранение удобно строить вокруг трех вещей: черновики, очередь отправки и кэш справочников (типы работ, узлы лифта, причины неисправностей). Черновик создается сразу при открытии заявки и сохраняется после каждого важного действия, например после фото или отметки пункта.
Синхронизация должна идти сама, когда сеть появилась, и при этом не терять данные:
Фото почти всегда самые «тяжелые». Полезно сохранять их локально в сжатом виде и отправлять отдельно от текстовой части отчета.
Конфликт возникает, если диспетчер поменял заявку в офисе, пока инженер был офлайн. Простой подход: не пытаться «склеить все автоматически». Сохраняйте обе версии и предложите выбрать: оставить изменения офиса или отправить полевую правку как комментарий или дополнение.
Фото в полевых работах решают споры и экономят время: что было до выезда, что стало после, где именно дефект, какая табличка с серийным номером. Важно не только иметь кнопку «Сфотографировать», но и продумать привязку, ограничения и отправку при плохой связи.
Практичный сценарий для лифта: снимок «до» (общий вид узла), крупно дефект (например, износ ролика), табличка или маркировка, затем «после» с результатом работ. Лучше привязывать фото не просто к заявке, а точнее: к конкретной работе или пункту чек-листа ТО. Тогда в отчете видно, какое фото подтверждает какой шаг.
Фото быстро раздувают размер базы и очередь отправки, поэтому рамки лучше задать заранее:
В офлайне фото нужно сохранять локально и показывать статус: «в очереди», «отправляется», «отправлено», «ошибка». В карточке заявки это должно быть видно сразу, чтобы инженер не думал, что отчет уже ушел.
Если процесс требует подтверждения, задайте минимальное правило: нельзя закрыть работу без хотя бы одного подтверждающего фото (например, «после» или «табличка»). При этом причина должна быть понятной прямо в интерфейсе: чего именно не хватает.
Чек-лист нужен не ради галочки. Он делает стандарт одинаковым для разных инженеров и смен, а руководителю дает понятный итог: что реально проверили и что нашли.
Не превращайте ТО в «анкету на 200 полей». Хороший чек-лист состоит из коротких, измеримых пунктов. В мобильном приложении лучше заранее решить, какие типы ответов действительно нужны.
Обычно хватает 4-5 типов:
Ключевой момент - версии чек-листов. Пункты со временем меняются: добавили новый датчик, поменяли регламент, уточнили формулировку. Если просто «переписать» чек-лист, старые отчеты начнут выглядеть сломанными. Поэтому каждому чек-листу дайте версию, а в отчете сохраняйте, по какой версии он заполнен.
Подпись и итог тоже должны быть частью модели отчета: кто выполнял (ФИО или табельный номер), дата и время (лучше автоматически), результат проверки (норма/есть замечания/заявка создана). Пример: инженер отмечает «есть замечания», прикладывает фото изношенного ролика, и приложение предлагает создать заявку на ремонт.
Чтобы приложение работало в поле, сервер должен быть простым и предсказуемым. Чем меньше «магии» в API, тем легче поддерживать офлайн, синхронизацию и разбор спорных случаев.
Начните с набора, который закрывает один цикл: получить работу, выполнить, сдать с фото. Обычно достаточно:
Фото и отчеты удобнее грузить отдельно: отчет можно отправить быстро даже при слабой связи, а фотографии догрузить позже, когда сеть станет стабильнее.
Не смешивайте справочники, заявки и медиа в одну сущность. Справочники (типы работ, статусы, модели оборудования) меняются редко, заявки меняются часто, а медиа живет своей жизнью (крупные файлы, повторы отправки). Такое разделение упрощает кэширование на устройстве и снижает риск конфликтов при синхронизации.
Доступ должен быть жестким: инженер видит только свои заявки и свои действия, диспетчер видит свой участок или бригаду. Проверяйте права на сервере для каждого запроса, а не только «на экране».
Аудит лучше сделать сразу: кто и когда сменил статус, кто добавил фото, кто отредактировал комментарий. Это помогает, когда появляются вопросы вроде «почему заявка закрыта без фото» или «кто поменял причину отказа».
Для базы данных (например, PostgreSQL) обычно хватает минимального набора таблиц:
Чтобы быстро собрать прототип, не начинайте с десятков функций. Сначала зафиксируйте 2-3 главных сценария одним абзацем, как будто объясняете коллеге: «получил заявку, приехал, сделал осмотр по чек-листу, приложил фото, отправил отчет». Это сразу отсечет лишние экраны и поля.
Дальше набросайте экраны и ввод. Для полевых работ важнее скорость, чем красота: минимум текста, больше выборов из списка, автоподстановка адреса и объекта, понятная кнопка «Сохранить офлайн». На этом этапе полезно заранее обозначить, какие поля обязательны, а какие можно пропустить.
План, который обычно укладывается в короткий цикл:
Офлайн лучше продумать заранее: фото «весят» много, связь может пропадать даже на парковке или в машинном помещении. Решите, будет ли приложение сжимать фото, можно ли отправлять только по Wi-Fi и как показывать пользователю, что именно уже ушло на сервер.
Самая большая проблема полевых приложений не в технологиях, а в том, как ими пользуются в реальной смене: перчатки, грязные руки, лифт в простое, связь прыгает, а диспетчер ждет ответ.
Если карточка заявки превращается в анкету на 30 полей, инженер откладывает заполнение «на потом» и дописывает вечером по памяти. В итоге теряются детали, путаются адреса, фото не совпадают с работой.
Рабочее правило: на выезде оставьте только то, что нужно, чтобы закрыть задачу прямо сейчас. Держите 5-8 обязательных полей максимум, остальное делайте опциональным или автозаполнением. И следите, чтобы один экран отвечал за одно действие: принял, выполнил, не смог.
Типичная ситуация: связь пропала, инженер сделал 6 фото, нажал «Отправить», а потом еще раз. Если нет очереди и идемпотентности, вы получите то пропажи, то дубли.
Каждое действие должно попадать в локальную очередь и иметь понятный статус: «в очереди», «отправляется», «отправлено», «ошибка». Фото лучше догружать отдельным шагом и показывать прогресс.
Если фото просто лежат «в папке заявки» без подписи и связи с этапом, через месяц никто не поймет, что именно на них. Привязывайте фото минимум к заявке, типу (до/после/дефект/табличка), времени и автору. Тогда фотоотчет становится доказательством, а не набором картинок.
Когда статус заявки может менять кто угодно и как угодно, диспетчер теряет контроль: заявка закрыта без причины или зависла в «в работе». Разведите роли (инженер, диспетчер, админ) и ограничьте переходы статусов. Например, инженер может «выполнить» или «не удалось», а отменять или переназначать должен диспетчер.
Слишком умный чек-лист (десятки пунктов, ветвления, обязательные комментарии везде) приводит к тому, что им не пользуются. Люди начинают писать все в комментарий или ставят галочки наугад.
Держите чек-лист простым: короткие пункты, понятные ответы (ОК/не ОК/не применимо) и одно поле «замечания». Сложность добавляйте только после реальных выездов.
Перед тем как отдавать приложение сервисным инженерам, прогоните его в реальных условиях: перчатки, холод, подвал, лифтовая шахта, связь прыгает. На этом этапе важно убрать мелкие раздражители, иначе люди быстро найдут обходные пути.
Проверьте базовые вещи на одном-двух тестовых выездах и заранее зафиксируйте правила: что обязательно, кто подтверждает, когда заявка считается закрытой.
Отдельно проверьте ситуацию, когда инженер заполнил все, нажал «Отправить», а сеть пропала на середине. Приложение должно показать, что данные в безопасности, и предложить повторить отправку позже, не заставляя вводить все заново.
И последний практичный пункт для руководителя: доступ к проекту и исходникам. Если собираете MVP на TakProsto, заранее проверьте экспорт исходного кода и понятный процесс версионирования (снимки и откат), чтобы не зависеть от одной сборки и быстрее чинить полевые баги.
Утро. Инженер открывает приложение на телефоне еще до выезда и делает быструю синхронизацию: подтягиваются новые заявки, список объектов, адреса, типы работ и шаблон чек-листа ТО. Связь уже «плавает», но это не мешает, потому что данные на смену скачаны заранее.
На объекте инженер открывает заявку и видит короткую форму: что сломалось, что нужно проверить, кто ответственный на месте. Дальше он проходит пункты ТО по одному, отмечая «ОК/не ОК» и добавляя пару слов только там, где есть отклонение. В процессе делает 3 фото: одно до работ, одно во время, одно после. Фото прикрепляются к заявке, но отправка не требуется прямо сейчас.
В подвале связь пропадает полностью. Инженер все равно заполняет форму до конца и нажимает «Сохранить отчет». Приложение сохраняет все как черновик на устройстве: ответы чек-листа, комментарии, время, координаты (если доступны) и список фото. Ничего не теряется, даже если приложение свернуть или телефон перезагрузится.
Когда связь появляется, включается фоновая отправка. Отчет уходит не одним большим пакетом, а по шагам:
Диспетчер в офисе открывает заявку и сразу видит заполненный чек-лист и фото «до/после». Ему не нужно звонить инженеру или просить переслать снимки в мессенджер: по отчету видно, что сделано и что осталось.
Чтобы MVP не расползся, начните с одного документа на 1 страницу: что именно должно работать у инженера в подвале или в шахте, когда связи почти нет. Это и есть каркас приложения.
Зафиксируйте требования без «хотелок на будущее». Удобный формат: «экран -> поля -> правила офлайна -> кто видит».
Дальше выберите минимальный релиз: заявки + чек-лист + фото + синхронизация. Все остальное оставьте после пилота. Важно заранее продумать хранение и экспорт: чтобы вы могли забрать данные и исходники, перенести сервер, выгрузить отчеты в файл и не зависеть от одного решения.
Если нужно ускориться, на TakProsto (takprosto.ai) можно описать проект в чате: какие экраны, какие поля, как работает офлайн, и получить Flutter-приложение вместе с backend на Go и базой PostgreSQL. После пилота на 1-2 бригадах добавляйте улучшения по факту: шаблоны работ по типам лифтов, простую аналитику по закрытию заявок, кастомные домены для развертывания, а для безопасных обновлений - снимки и откат, если новая версия мешает работать в поле.
Начните с одного главного сценария: инженер открывает заявку, заполняет чек-лист, делает фото и закрывает работу, даже без связи. Для MVP обычно достаточно списка заявок, карточки заявки, формы работ, экрана фото и синхронизации при появлении сети.
По умолчанию приложение должно сохранять все локально сразу: поля формы, отметки чек-листа и фото. Отправку делайте отложенной, чтобы инженер мог уехать с объекта с готовым отчетом, даже если интернет не появился ни разу.
Держите обязательными только то, без чего нельзя принять работу: статус, минимальный результат по чек-листу, причина при неуспехе и подтверждение (подпись или отметка, почему подписи нет). Остальные поля лучше сделать опциональными или с автозаполнением, чтобы закрытие заявки занимало минуты.
Связывайте фото не просто с заявкой, а с конкретным узлом или пунктом чек-листа, и добавляйте короткую подпись вроде «до», «дефект», «после», «табличка». Тогда снимки превращаются в доказательство по шагам, а не в набор картинок, которые невозможно найти через неделю.
Сжимайте фото автоматически и ограничивайте размер и количество на заявку, чтобы не забить память и очередь отправки. Практичный вариант — отправлять текстовую часть отчета отдельно и разрешать фото догружать позже, когда связь станет стабильнее.
Делайте очередь из отдельных операций и показывайте понятный статус для каждой: что в ожидании, что отправилось, что требует внимания. Повторы должны происходить автоматически, а повторная кнопка «Отправить» не должна создавать дубли, иначе отчеты быстро превратятся в хаос.
Самый безопасный подход — не пытаться «склеить» изменения автоматически. Сохраните полевую версию как черновик, покажите, что в офисе были правки, и предложите выбрать вариант или отправить полевое изменение отдельным комментарием.
Закладывайте версию чек-листа в модель данных и сохраняйте, по какой версии заполнен каждый отчет. Тогда старые отчеты останутся читаемыми, даже если вы позже добавите пункты или измените формулировки регламента.
Минимум обычно включает вход по токену, список назначенных заявок, детали заявки, прием отчета и отдельную загрузку фото. Чем проще и предсказуемее API, тем легче поддерживать офлайн, повторы и разбор спорных случаев.
Базовые роли — инженер, диспетчер, мастер участка и админ, но для старта часто хватает инженера и диспетчера. Права лучше проверять на сервере для каждого действия и сразу вести аудит изменений, чтобы было видно, кто сменил статус, добавил фото или исправил комментарий.
