Приложение для строительной компании.

Выбор решения / строительная компания

Начните с одной операции
на объекте.

Если нужно передавать замечания подрядчикам и проверять исправления, первую версию приложения можно построить вокруг этого пути: место на объекте → задание → фото результата → решение проверяющего.

Сначала проверьте, можно ли настроить такой процесс в системе, которой команда уже пользуется. Для сравнения: Procore описывает доступ к чертежам, полевые записи и фотографии без связи, а также работу с актуальным комплектом чертежей. Это возможности внешнего продукта по описанию производителя. Они не подтверждают доступность сервиса для вашей компании или интеграцию BORNLI.

Описание управления строительными проектами Procore ↗

Модельный сценарий / замечание на объекте

Фото сделано.
Исправление ещё не принято.

Представим отделочную компанию. Прораб создал замечание З-014: повреждение покрытия в помещении 203, корпус Б. Подрядчик устранил дефект и приложил фотографию на телефоне, но связь пропала. Проверяющий пока не получил результат.

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

1. 01 / Прораб

   Назначить

   З-014 · корпус Б · помещение 203

   Место, описание, исходное фото, исполнитель и версия задания.

2. 02 / Подрядчик

   Подготовить результат

   Сохранено на устройстве

   Новое фото и комментарий. Без связи показано ожидание отправки.

3. 03 / Система

   Подтвердить получение

   Результат получен · на проверке

   Файлы и запись приняты сервером. Подрядчик видит подтверждение.

4. 04 / Проверяющий

   Принять или вернуть

   Принято / нужна доработка

   Решение, автор и комментарий сохраняются в истории замечания.

Модельный сценарий: объект, номер замечания и роли условные. Схема иллюстрирует предлагаемое поведение, не выполняет отправку и не является клиентским внедрением BORNLI. Отметка в приложении здесь означает внутреннюю проверку задания, а не оформление юридической приёмки строительных работ.

Состав данных / ответственность

Кто вправе менять
место, срок и результат.

• Прораб: создаёт замечание, уточняет место и назначает исполнителя. Изменение задания получает новую версию, чтобы сохранить контекст старых фотографий.
• Подрядчик: видит назначенные ему объекты и задачи, добавляет результат и комментарий. Закрытие задачи проверяющим — отдельное действие.
• Проверяющий: сверяет результат с актуальным заданием, принимает его либо возвращает с понятной причиной.
• Руководитель: видит просроченные и ожидающие проверки задачи; состав доступных объектов определяется его ролью.

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

Связь и изменения / границы офлайн-режима

Что произойдёт,
когда телефон вернётся в сеть.

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

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

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

Здесь описаны требования к будущей реализации. Прототип экрана не подтверждает сохранность файлов, работу без сети или защиту от повторных операций: эти свойства проверяют на устройстве и сервере.

Приёмка приложения / проверяемые сценарии

Пять проверок
до выхода команды на объект.

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

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

Первая версия / оценка

От замечания
до решения проверяющего.

На оценку влияют обмен с текущими системами, объём файлов, правила доступа и требования к работе без связи. Ориентиры стоимости BORNLI помогут подготовиться к разговору; смету и срок для строительной компании определяем после согласования состава.

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

Первое обращение / один пример

Покажите путь
одного замечания.

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

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

Опишите процесс в форме BORNLI — разберём границы задачи и обсудим прототип. До разработки можно согласовать путь пользователя, но надёжность обмена потребуется проверить отдельно.