Как организовать хранение файлов. Подход Симплоера

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

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

В этой статье рассказываем, как устроено хранение файлов в Симплоере.

Сразу скажем: универсального подхода к хранению файлов не существует. У всех разные задачи, пользователи и габариты, поэтому разрабатывать такие решения нужно индивидуально. То, что опишем в статье, работает отлично для нас, но может не подойти другим командам (например, если служба безопасности компании не разрешает хранить документы в облаке).

Папки

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

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

Структура такой проектной папки всегда одинаковая:

📌 Если с одним и тем же клиентом у нас несколько разных проектов, то самая крупная единица — отдельная папка для каждого проекта;

📌 На следующем уровне:

• папка с техническими документами — клиентский договор и т. п. документы;
• папка Original Docs — исходные документы, которые присылает клиент;
• папка Documents in Progress — для документов, которые станут результатом нашей работы.

📌 Внутри папки Documents in Progress обычно несколько внутренних папок. Их создаём по разным критериям. В проектах по лигал-дизайну структура зависит от архитектуры документооорота (т. е. для каждого вида документов своя папка). В остальных проектах — от их этапов.

Отдельное внимание — папке Versions. В блоке про версии мы расскажем, что сохраняем версии документов каждые 30 минут. Бывает, что за пару недель работы над одним документом получается 50+ версий (а если документ объёмный, то может быть и 100+). Чтобы не засорять основную папку промежуточными версиями, мы храним в папке Versions всё, что не вошло в финальную версию документа.

Название папки всегда пишем в квадратных скобках, вот так: [Versions]. Это нужно, чтобы всегда стояла первой в списке, потому что файлы сортируются по алфавиту.

Этот подход помогает:

• быстро и безошибочно находить актуальную версию;
• компактно хранить все версии документа (ниже в блоке про версии расскажем, зачем это нужно).

Название файлов

Знаем, что у многих изнутри папка выглядит примерно так:

На картинке выше мы видим две большие проблемы:

• нет никаких стандартных правил для названий файлов;
• по названиям файлов невозможно понять, что там внутри.

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

Мы разработали модульную структуру названия, которая подстраивается под специфику файла.

Название каждого файла состоит из одних и тех же структурных элементов:

Название контрагента — Симплоер — суть документа — номер документа (если есть) — номер версии (без «в», «v» и т. п.)

Все запчасти названия отделяем друг от друга длинным тире (—).

Количество элементов может меняться в зависимости от специфики файла (например, в файле с Книгой Симплоера нет названия контрагента и номера документа). Главное — не менять последовательность элементов.

Ниже примеры, как ещё могут называться файлы:

Версии

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

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

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

Выглядит это, например, так: 1.3.20.

Мы адаптировали семантический подход под свои задачи. Как это работает — на картинке:

Симплоер в телеграме — https://t.me/simplawyer