Начните со смены, которую офис сможет принять
В конце смены руководителю нужны выполненные работы, нерешённые задачи и понятный расход материалов. Когда задания лежат в одном чате, фотографии в другом, а часы в таблице, сначала приходится собирать отчёт из этих источников. Ошибка в единице материала или потерянное фото добавляет ещё один круг уточнений.
Мы предлагаем оценивать MVP приложения прораба на одном внутреннем сценарии: выбранный объект, бригада, задания, факт выполнения, фото, материалы и отчёт руководителю. MVP означает первую рабочую версию с ограниченным составом. Ниже разберём, какие поля зафиксировать, что включить в смету разработки и как принять результат. Такой разбор пригодится и для настройки готовой системы, и для заказа собственного модуля.
Граница первого релиза: прораб ведёт смену на телефоне, офис получает связанные записи и принимает отчёт либо возвращает его с причиной. По этой цепочке можно проверить каждую строку сметы. Перейти к полям смены, составу сметы или приёмке.
Сначала возьмём один тип работ и привычную форму отчёта. Например, для внутреннего прототипа выберем объект, участок и бригаду с заданиями на смену. Частично выполненная работа останется частично выполненной; причина переноса попадёт в отчёт. Закрытие смены само по себе не подтвердит качество всех работ.
Здесь важен внутренний учёт подрядчика. Паспорт оборудования и сервисный наряд относятся к выездному обслуживанию, а согласование допработ владельцем квартиры требует отдельного кабинета заказчика. Исполнительную документацию, процессы охраны труда и кадровый табель включим в проект после отдельной проверки их требований.
Иллюстрация сценария
Результат работы рядом с записью о нём
Как мы связали приложение, админку и 1С в Бакаеве
В продуктовом магазине «Бакаев» мы разработали мобильное приложение для покупки продуктов и админ-панель, помогли перенести локальную 1С в облако и настроили обмен через API. API позволяет системам передавать данные по согласованным запросам. Сервер синхронизации связывает приложение, панель и учётную систему.
Сотрудник меняет фотографию товара в админке, сервер передаёт изменение в 1С. Заказ через приложение отражается в остатках админ-панели и 1С. Изменения со стороны 1С проходят обратный путь к приложению. Команда работает со связанным каталогом и заказами.
Реальный проект 13FOX · продуктовый ритейл
Каталог в панели связан с 1С
На экране нашей админ-панели видны карточки товаров и инструменты управления каталогом.
В приложении прораба мы определим, откуда приходит название материала, кто подтверждает получение и какой результат уходит в учёт. Сам строительный сценарий ниже показан как прототип состава первой версии. Способ обмена выберем после проверки вашей конфигурации 1С.
Матрица полей: что должно попасть в задание на разработку
Возьмите обезличенный отчёт за вчерашнюю смену и заполните эту матрицу своими названиями. Для каждого поля определим, кто его вводит, кто исправляет и в какой момент офис считает запись принятой. Так «фотоотчёт» и «материалы» получат проверяемый состав.
| Запись | Поля первой версии | Правило |
|---|---|---|
| Смена | Объект, участок, дата, бригада, прораб | Прораб выбирает доступный объект; офис задаёт список бригад и заданий |
| Задание | Работа, плановое количество и единица, ответственный, статус | Прораб указывает факт и причину отклонения; частичный результат сохраняется отдельно от статуса |
| Фото | Связь с заданием, автор, время добавления, комментарий, состояние загрузки | Офис видит, получен ли сам файл; запись с отсутствующим вложением требует внимания |
| Материал | Позиция справочника, количество, единица, вид операции, связь со сменой | Заявка, получение и расход различаются; исправление хранит причину |
| Время и итог | Сотрудник, часы по согласованному правилу, выполненные работы, переносы, решение руководителя | Руководитель принимает отчёт или возвращает; изменение принятого итога оставляет след в журнале |
Например, в прототипе задания по кладке будут план и фактический объём в одной согласованной единице. Если бригада выполнила часть работы, прораб укажет фактический объём; остаток и причина переходят в следующую смену по правилу руководителя. Мы проверим, нужна ли автоматическая новая задача или достаточно ручного переноса. Этот выбор меняет разработку и порядок работы офиса.
На первом прототипе проверим форму с прорабом и руководителем строительства: какие поля человек действительно заполняет на месте, что офис сможет проверить и какие значения берутся из справочника. Нужные действия без связи отметим прямо в задании на разработку.
Заявка, получение и расход требуют разных правил
Допустим, бригада запросила материал для следующей смены. Часть доставили на объект, часть ещё ожидается; из полученного использовали только часть. Один статус «материал учтён» скроет эти различия. Мы предложим три отдельные записи: что требуется, что фактически принято и что израсходовано на работе.
В заявке нужны объект, материал из справочника, количество с единицей, желаемая дата и ответственный за решение. Прораб должен видеть ответ: согласовано, требуется уточнение или отклонено с причиной. Получение фиксирует фактическое количество и того, кто его подтвердил. Расход связывает материал с работой и сменой.
Если закупка идёт мешками, а учёт ведётся в килограммах, заранее согласуем единицу каждой позиции и правило пересчёта. Упаковки могут различаться по массе; мы предложим хранить параметры конкретного материала, чтобы человек не выбирал произвольный коэффициент. Пересорт, возврат и перемещение между объектами добавим в смету, если они нужны для выбранной смены.
Запись расхода в приложении станет оперативным фактом. Для списания в 1С отдельно определим документ, проверяющего и момент проведения. В первом релизе офис может сверять факт вручную либо получать его по согласованному обмену. Оба варианта должны быть явно указаны в смете.
С учётом времени поступим так же: согласуем, кто отмечает часы, кто исправляет запись и кто её подтверждает. Расчёт зарплаты, кадровые документы и нормативная форма табеля потребуют отдельной постановки задачи. Для внутреннего отчёта достаточно тех полей, по которым руководитель проверит смену.
Без связи прораб видит, что сохранено и что получил офис
Для работы без интернета сначала загрузим доступные задания и нужную часть справочника. Новые факты и фото приложение будет сохранять на устройстве. На экране предложим состояния «сохранено на телефоне», «отправляется», «получено офисом» и «требует исправления». Решение руководителя «отчёт принят» появится отдельно, после проверки смены.
В руководстве Android по офлайн-архитектуре локальная запись и последующая синхронизация описаны как отдельные задачи. Сохранение на телефоне ещё не даёт офису копию. Если устройство потеряно до отправки, неотправленные данные можно потерять. После появления сети время передачи зависит от устройства и условий фоновой работы; в приёмке проверим выбранные телефоны.
Представьте проверочный сбой: сервер уже записал заявку на материал, но телефон не получил ответ. При повторной отправке сервер должен распознать ту же заявку по постоянному идентификатору. Мы включим эту проверку в приёмку. Если руководитель изменил задание, пока телефон без связи, согласованное правило покажет конфликт и путь его решения.
Для обмена с 1С сначала проверим конфигурацию, размещение базы, нужные объекты и права доступа. Официальная документация 1С описывает REST-интерфейс на OData как один из способов чтения и записи данных. Возможность доступа к объекту сама по себе не задаёт правило списания материала. Для конкретной базы согласуем операцию и проверим её на тестовых данных.
Связь с CRM, системой учёта клиентов и объектов, определим по тому же принципу: где хранится объект, откуда приходит задание и куда возвращается итог. Мы можем разобрать этот путь в рамках API-интеграции. Права на объекты проверим на сервере, а в журнале сохраним автора, изменение и причину исправления. Ответственный в офисе будет видеть зависшие записи и сможет сообщить прорабу следующий шаг.
Как собрать сравнимую смету разработки
Стоимость приложения для прораба зависит от правил смены, устройств и систем, с которыми оно работает. Для оценки мы предложим состав ниже. У каждой строки будет собственный результат и сценарий проверки. Это позволит сравнить предложения подрядчиков по одинаковым включениям.
| Работы | Результат для приёмки | Что уточнить до оценки |
|---|---|---|
| Разбор смены и прототип | Формы, роли, поля и согласованные состояния | Кто принимает отчёт; какие случаи обязательны |
| Мобильная часть | Задания, факт, фото, материалы и итог смены | Платформы, модели телефонов, камеры, объём вложений |
| Офисная часть и сервер | Назначение, проверка, возврат с причиной, права и журнал | Новая панель или модуль действующей системы |
| Работа без связи | Локальное хранение, очередь, повтор, состояния ошибок | Какие действия доступны офлайн; срок хранения; поведение при выходе из аккаунта |
| Обмен с CRM и 1С | Согласованные направления, объекты и сверка результата | Справочники или документы; кто подтверждает расход |
| Проверка, запуск и поддержка | Контрольная смена, передача системы и порядок восстановления | Тестовые данные, распространение сотрудникам, резервные копии и сопровождение |
Отдельно укажем эксплуатационные расходы: сервер, хранение фотографий, резервные копии, обновление приложения и изменение интеграций. Поддержка имеет свой объём и условия. Если офису нужна полноценная новая система управления строительством, её оценим отдельным составом работ.
До разработки проверим уже используемый продукт на вашей смене. Когда нужные поля, роли, офлайн-запись и передача итога доступны настройками, можно оценить настройку. Если важный переход приходится обходить вручную, сравним доработку и собственный мобильный модуль. Расширение на все объекты разумно обсуждать после приёмки первой версии.
Примите первую версию по контрольной смене
Вместе с руководителем строительства выберем одну обезличенную смену и заранее запишем ожидаемый результат каждого шага. Прототип покажет удобство формы; рабочую версию проверим на устройствах и в офисной системе. Такой сценарий пригодится и при покупке готового решения.
- Назначить работу. Прораб видит свой объект, бригаду, задание и последнюю загруженную версию. Доступ к чужому объекту закрыт на сервере.
- Внести частичное выполнение. Факт, единица и причина отклонения сохраняются; незавершённая работа остаётся видна руководителю.
- Пройти материалы. Заявка, получение и расход имеют отдельные количества и статусы. Повтор отправки после пропавшего ответа распознаётся как та же операция.
- Потерять связь. В заранее загруженной смене добавить факт и фото, закрыть и снова открыть приложение. Локальные записи доступны, состояние отправки видно.
- Вернуть связь и создать конфликт. Офис получает записи и файлы. Правка задания руководителем во время офлайн-работы обрабатывается по согласованному правилу; ошибка вложения видна.
- Принять итог. Руководитель принимает отчёт или возвращает с причиной. Прораб видит решение; исправление принятого итога отражено в журнале. Если обмен с 1С включён, результат сверяют и там.
Эта проверка подтвердит выбранный сценарий. Следующий этап можно оценить отдельно: новые типы работ, возврат материалов, дополнительные роли или расширение обмена.
Вопросы перед заказом
Можно ли начать с готовой системы?
Да. Проведите в ней одну вашу смену: задания, частичное выполнение, фото, материалы и проверку офисом. Если поля, права, работа без связи и обмен подходят, оцените настройку. Собственный модуль имеет смысл при конкретном разрыве в этом процессе.
Нужна ли интеграция с 1С в первом релизе?
Она нужна, если без неё смена заканчивается повторным переносом данных, который вы хотите убрать. Можно начать со справочника материалов или согласованной выгрузки, а запись учётных документов включить отдельным этапом. В смете должны быть указаны направление обмена, объекты и проверка результата.
Можно ли использовать приложение как официальный табель?
Для первой версии мы предлагаем внутреннюю запись времени по согласованным правилам. Чтобы использовать её для кадрового учёта и расчёта зарплаты, отдельно проверьте форму, порядок подтверждения и обмен с кадровой системой.
Что прислать для оценки стоимости?
Обезличенный отчёт за смену, пример задания, список материалов с единицами, роли сотрудников, названия CRM и конфигурации 1С, а также модели телефонов и действия без связи. По ним можно определить состав первого релиза и условия его приёмки.
Источники
Технические условия проверены 3 октября 2026 года. Для сметы конкретного проекта мы проверим конфигурацию 1С и режим работы выбранных устройств.
- Android Developers: условия фоновых задач и повторов.
- RFC 9110: условия безопасного повтора запросов.
- 1С:Фреш: доступ к данным через OData.
Покажите день прораба — оценим первый релиз
Оставьте удобный контакт для разговора о вашей смене. После контакта передайте обезличенный отчёт, пример задания и список материалов с единицами. Мы разберём поля, роли, обмен с офисом и проверки результата, чтобы определить состав первого релиза и работ для сметы разработки.