Смета, планировки и подрядчики в одном месте: проектный сервер дизайнера

MAATRIX

К середине проекта у дизайнера интерьеров обычно уже штук пять источников правды: смета живёт в облачной таблице, последние планировки — в почте одним письмом, переписка с мебельщиком — в WhatsApp, с электриком — в отдельном чате, а фото с объекта — в галерее телефона. Когда клиент спрашивает «а какая версия сметы актуальная», приходится вспоминать, куда её в последний раз отправляли. Ниже — про то, как собрать всё это в один проектный сервер: с полным доступом у вас и с точечным — у каждого подрядчика.

Где расползается один проект дизайнера

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

Смета почти никогда не остаётся в одном месте. Черновая версия рождается в Excel на компьютере, потом уходит клиенту письмом, потом пересчитывается заново после торга с поставщиком мебели — и эта новая версия уже не попадает автоматически ни в облако, ни клиенту. Через месяц у вас три файла «Смета_финал», «Смета_финал2», «Смета_для_Иванова_01.06», и без даты в имени файла не разобраться, какая из них последняя.

Планировки и чертежи обычно приходят из другого инструмента — AutoCAD, ArchiCAD, SketchUp — и экспортируются в PDF или JPG под конкретную задачу: одна версия для клиента (красиво, с мебелью), другая для замерщика (только стены и размеры), третья для электрика (только точки и группы). Если хранить их вперемешку с фотографиями референсов и перепиской, через пару итераций правок никто не может быстро сказать, какая планировка ушла электрику в последний раз — а какая осталась только в почте у клиента.

Переписка с подрядчиками — отдельная головная боль, потому что она физически размазана по разным каналам. С мебельной фабрикой вы общаетесь в почте, потому что там удобно пересылать спецификации. С прорабом — в WhatsApp, потому что он не открывает почту. С электриком — в Telegram, потому что так исторически сложилось. Когда клиент спрашивает «а мы точно согласовали именно этот оттенок плитки с сантехником», ответ приходится искать в трёх разных приложениях сразу, а иногда файл с финальным решением вообще был отправлен голосом или на словах при личной встрече и нигде не зафиксирован.

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

Что теряется, когда информация в десяти местах

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

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

Ошибки из-за устаревшей версии. Самый дорогой сценарий: подрядчик получил планировку до последней правки и заказал материал не под тот размер проёма, или мебельщик изготовил гарнитур по старой версии сметы с другой комплектацией. Переделка стоит денег заказчику и репутации — вам, причём объяснить клиенту, что «версия была не та, потому что мы отправили её три недели назад в почте», звучит не как форс-мажор, а как недоработка процесса.

Разрыв ответственности между подрядчиками. Когда переписка с мебельщиком, отделочником, электриком и сантехником идёт в четырёх разных каналах, у вас нет единой картины — кто, что и когда согласовал. Если позже возникает спор («мы же договаривались о другой розетке»), доказать факт согласования сложно, потому что нужного скриншота может не найтись, а память у всех участников избирательная.

Уязвимость при смене инструмента. Если переписка держится на личном аккаунте Google или личном облаке дизайнера, при смене подрядчика на середине проекта доступ приходится отзывать и раздавать заново вручную, а часть материалов рискует остаться «зависшей» в чужом личном хранилище.

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

Идея простая: один проектный сервер на объект

Альтернатива — завести под каждый проект (а не под всю практику разом) отдельное пространство на своём сервере, куда стекается всё: смета, чертежи, переписка по ключевым решениям, фото с объекта, договор, референсы. У вас — полный доступ ко всему пространству. У каждого подрядчика — доступ только к тем разделам, которые касаются именно его работы.

Технически для этого не нужно ничего экзотического. Достаточно арендовать сервер и поднять на нём файловое хранилище с веб-интерфейсом и разграничением прав — например, Nextcloud (подробный разбор установки есть в статье как установить и настроить Nextcloud на VPS). Это открытое решение с мобильным приложением, синхронизацией на компьютер и публичными ссылками с паролем и сроком действия — ровно тем набором функций, который нужен для проектной работы дизайнера.

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

Практическая разница по сравнению с россыпью сервисов:

Структура папок, которая реально работает

Единое пространство работает только тогда, когда структура внутри него понятна интуитивно, без объяснений «где что лежит» каждому новому участнику. Рабочий вариант для одного объекта — плоская структура из нескольких верхнеуровневых папок:

Объект_Иванова_ул.Ленина_45/
├── 01_Смета/
│   ├── Смета_актуальная.xlsx
│   └── Архив_версий/
├── 02_Планировки_и_чертежи/
│   ├── Для_клиента/
│   ├── Для_замерщика/
│   ├── Для_электрика/
│   └── Для_сантехника/
├── 03_Референсы/
├── 04_Подрядчики/
│   ├── Мебель/
│   ├── Отделка/
│   ├── Электрика/
│   └── Сантехника/
├── 05_Фото_с_объекта/
├── 06_Договор_и_согласования/
└── 07_Переписка_ключевые_решения/

Ключевая идея — папка 04_Подрядчики с подпапками под каждое направление. Именно её вы будете расшаривать точечно: мебельщику — только 04_Подрядчики/Мебель, электрику — только 04_Подрядчики/Электрика. Каждая подпапка — самодостаточная: там лежит нужная версия чертежа (уже экспортированная под конкретную задачу из 02_Планировки_и_чертежи), спецификация, переписка по этому разделу и фото хода работ.

Папку 01_Смета/Архив_версий стоит завести отдельно от актуальной сметы: так «Смета_актуальная.xlsx» всегда одна и без цифр в названии, а история изменений остаётся доступной, если понадобится вспомнить, что менялось и почему выросла итоговая сумма.

07_Переписка_ключевые_решения — это не замена мессенджеру для повседневного общения, а место, куда вы (или клиент) сохраняете скриншот или файл в момент принятия важного решения: выбор оттенка плитки, финальное согласование планировки, замена поставщика. Пять минут на сохранение скриншота экономят часы на поиск «а мы точно это обсуждали» через два месяца.

Как дать подрядчику доступ только туда, куда нужно

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

В Nextcloud для этого есть два рабочих сценария в зависимости от того, насколько часто подрядчик будет пользоваться папкой.

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

Правой кнопкой на папку 04_Подрядчики/Мебель → Поделиться
→ Создать ссылку
→ Установить пароль
→ Разрешения: "Может загружать и редактировать"
   (или только "Может просматривать", если это лишь чертёж для ознакомления)
→ Срок действия ссылки: например, до даты сдачи раздела

Это удобно, потому что подрядчику не нужно ничего регистрировать — он открывает ссылку в браузере, вводит пароль и видит только содержимое этой конкретной папки, а не весь проект.

Постоянная работа на объекте — отдельная учётная запись с правами на группу папок. Для прораба или отделочника, которые заходят в свой раздел регулярно и сами выкладывают фото хода работ, разумнее завести отдельного пользователя и привязать его именно к нужным папкам через приложение групповых папок (Group folders):

occ user:add podryadchik-otdelka --display-name "Отделка — бригада Петрова"
occ group:add podryadchik-otdelka-group
occ group:adduser podryadchik-otdelka-group podryadchik-otdelka
occ groupfolders:create "04_Подрядчики/Отделка"
occ groupfolders:group <id_папки> podryadchik-otdelka-group read-write

Команды выполняются от имени пользователя веб-сервера (в Docker-установке — через docker exec -u www-data <контейнер> php occ ...); точный синтаксис уточняйте по документации на момент настройки. Смысл в том, что у подрядчика появляется свой логин, который открывает только его раздел с правом загрузки файлов, а всё остальное дерево проекта для него просто не существует.

Для клиента логично сделать промежуточный вариант: доступ на чтение к папкам 02_Планировки_и_чертежи/Для_клиента, 03_Референсы, 05_Фото_с_объекта и текущей смете — то есть ко всему, что касается его лично, без внутренней кухни по подрядчикам.

Матрица доступа для типового проекта выглядит примерно так:

Версии, история и кто что менял

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

В Nextcloud версионирование включено по умолчанию для всех файлов: при каждом сохранении отредактированного файла (через десктопный клиент, веб-редактор или простую перезапись при загрузке) создаётся снимок предыдущей версии, доступный через историю файла. Это работает и для сметы в Excel, и для чертежа в PDF — если планировка менялась пять раз за проект, каждую промежуточную версию можно поднять из истории, не спрашивая никого «а у тебя не сохранилась старая планировка».

Практическое следствие: файл Смета_актуальная.xlsx можно смело перезаписывать новой версией при каждом пересчёте, не плодя копии с датами в названии — история версий и так покажет, что менялось, а название файла остаётся стабильным, и все ссылки на него (в том числе выданные подрядчикам) продолжают работать без пересылки нового файла заново.

Для файлов, изменения в которых особенно важно проследить (финальная планировка, договор с правками), стоит взять за привычку добавлять короткий комментарий при загрузке новой версии — например, прямо в переписке с клиентом указывать «загрузил версию от 28 августа, изменил расстановку в спальне». Сама история версий покажет факт изменения, но не причину — а причина обычно и есть предмет будущих споров.

Полезная смежная привычка — фиксировать не только файлы, но и факт передачи доступа подрядчику: когда именно вы открыли ему папку и когда закрыли по завершении раздела работ. Это касается не только дизайна интерьеров — та же логика разбирается в статье про NDA и доступ подрядчика к серверу, и архитектурные бюро с похожей задачей — общий доступ к проекту у бюро и клиента — решают её похожим образом, это описано в статье про общий сервер архитектурного бюро для BIM. Если вам, как дизайнеру, приходится ещё и физически перемещаться между объектом, офисом и домом с одним и тем же проектом на руках, пригодится и разбор про доступ архитектора к проектам с любой точки — принцип для дизайнера интерьеров тот же самый.

Что касается объёма — типовой проект интерьера редко бывает по-настоящему «тяжёлым»: смета, планировки в PDF и DWG, референсы, фото с объекта обычно укладываются в единицы, реже — в первые десятки гигабайт. Это ориентир, а не измеренная норма: у проекта с 3D-визуализациями в высоком разрешении объём может быть заметно больше, так что тариф сервера стоит выбирать с запасом на несколько параллельных проектов.

Частые вопросы