Вы готовы отправить проект, но редактируемый файл лежит на рабочем столе, утверждённый PDF сидит в «Загрузках», а ещё один экспорт похоронен в папке под названием Final_New. Что тут произошло, вы, скорее всего, вспомните. Тот, кто откроет проект после вас, — нет.
Продуманная структура папок проекта делает эти решения менее зависимыми от памяти. У входящих материалов, редактируемой работы и готовых файлов появляются предсказуемые места, а проект можно спокойно закрыть, не потеряв контекст. На Mac начните с имён и папок. Визуальные подсказки добавляйте только тогда, когда сама схема уже имеет смысл.
Возьмите шаблон и постройте верхний уровень
Выберите ближайший к вашей работе шаблон из таблицы ниже. Это отправные схемы, а не требования macOS.
| Тип проекта | Папки верхнего уровня | Куда попадают финальные файлы |
|---|---|---|
| Дизайн | 01_Brief, 02_References, 03_Source, 04_Working, 05_Exports, 99_Archive | 05_Exports, с подпапкой под каждый формат |
| Разработка ПО | docs, src, tests, assets, build, 99_Archive | build, отдельно от src и системы контроля версий |
| Исследование | 01_Admin, 02_Data_Raw, 03_Data_Clean, 04_Analysis, 05_Outputs, 99_Archive | 05_Outputs, с версионными отчётами |
| Работа для клиента | 01_Contract, 02_Brief, 03_Working, 04_Deliverables, 05_Invoices, 99_Archive | 04_Deliverables, только отправленные копии |
Главное здесь — разделение на входящее, редактируемое и выходное. Скачанная референсная картинка — это не ваш рабочий макет, а экспортированный PDF не заменяет редактируемый исходник. Когда эти роли разведены, проще понять, что можно воссоздать, а что нужно беречь.
Apple проводит и более фундаментальное различие в своём File System Programming Guide: в /System лежат ресурсы, необходимые для работы macOS, и менять их не следует, а в /Users находятся домашние папки пользователей. Корень проекта держите в пользовательском хранилище, а не среди ресурсов операционной системы.
Выбирайте шаблон под свой способ работы
В дизайн-проекте заранее определите разницу между 03_Source и 04_Working, пока никто ещё ничего не сохранил. Рабочее правило такое: в Source лежат присланные материалы и переиспользуемые мастер-файлы, а в Working — композиции и текущие правки. Если не можете чётко объяснить эту разницу, объедините обе роли в одну, чем поддерживать двусмысленные места.
В исследовании исходные данные храните в 02_Data_Raw. Преобразованные наборы кладите в 03_Data_Clean и записывайте, как вы их получили. Тогда при исправлении анализа не придётся гадать, не правил ли кто-нибудь оригинальную таблицу.
Разработка ПО — осознанное исключение из схемы с нумерацией. Используйте имена каталогов, которых ждут ваш репозиторий, фреймворк и сборочные инструменты. Считайте build сгенерированным результатом и настройте исключения в системе контроля версий; не переносите вручную файлы, которые инструмент ожидает в другом месте.
В работе для клиента Deliverables — это то, что вы отправили. Презентация-кандидат остаётся в Working, пока её не передали. Так вы не выдадите неутверждённый черновик за запись о сдаче.
Создайте проект в Finder
Выберите постоянный корень. Создайте папку Projects внутри «Документов» или в домашней папке и складывайте активные проекты туда. Причина практичная: нужно место, которым вы будете пользоваться, даже когда торопитесь. Типичная ошибка — начать работу на рабочем столе и пообещать себе разобрать всё потом. Хранить файлы на рабочем столе не запрещено, но там слишком легко принять временное сохранение за осознанное раскладывание по местам.
Дайте проекту узнаваемое имя. Сочетайте код клиента или осмысленную дату с коротким описанием, например
Acme_RebrandилиYYYY-MM_Acme_Rebrand. Берите тот идентификатор, которым люди пользуются в разговорах и при передаче дел. Избегайте расплывчатых корней вродеNew_Projectи не добавляйте уровень клиента, если вы не ведёте регулярно несколько проектов для одного клиента.Создайте папки из выбранной строки. Для нумерованных шаблонов используйте двузначные префиксы и подчёркивания. Считайте
01административной частью, брифами или договорами;02— референсами или входящими материалами;03— рабочим содержимым, где это уместно; следующие позиции отданы анализу, результатам, экспортам или счетам в зависимости от шаблона.99_Archiveоставьте для выведенных из работы материалов. Номера задают порядок, а не универсальную классификацию.Напишите README в корне. Укажите назначение проекта, его владельца и что должно лежать в каждой папке. Добавьте различия, которые новичок может понять неправильно, особенно Source и Working или Outputs и Deliverables. Типичная ошибка — написать просто список папок. Объясните решения: можно ли править сырые данные, где хранятся согласования и в каком каталоге лежит запись о передаче.
Сохраните пустую копию как шаблон. Перед повторным использованием удалите специфичные для проекта файлы, закрытые договоры и данные клиента. Оставьте описания папок, а владельца и назначение замените понятными подсказками. Если скопировать старый живой проект без чистки, в следующую работу перекочуют устаревшие файлы и допущения.
Не создавайте заранее все возможные подпапки. Начните с тех мест, которые можете объяснить, а детали добавляйте, когда в них появится реальная потребность. Шаблон должен избавлять от повторяющихся решений, а не заставлять продираться через пустые категории.
Закончите проверкой в режиме колонок в Finder. Отсортируйте по имени, откройте корень проекта и прочитайте верхний уровень по порядку. Вы должны суметь описать путь от входящих материалов через работу к сдаче, не открывая каждую папку.
Правила имён, которые сохраняют порядок папок
Имя должно помогать отличить соседние элементы, не открывая их. Оно же должно иметь смысл, когда элемент всплывает в результатах поиска вне своей папки.
Пользуйтесь коротким чек-листом, а не выдумывайте соглашения при каждом сохранении.
- Единообразные префиксы. Смешанная разрядность усложняет поддержку упорядоченного списка. Плохо:
1_Admin,02_References,3_Working. Хорошо:01_Admin,02_References,03_Working. - Предсказуемые разделители. Используйте подчёркивания между значимыми словами и дефисы внутри дат или кодов. Плохо:
Acme / Brand & Web. Хорошо:Acme_Brand_Web. - Даты — от крупной единицы к мелкой. Пишите
YYYY-MM-DD, когда важна хронологическая сортировка. Плохо:DD-MM-YYYY_Review. Хорошо:YYYY-MM-DD_Review. - Оставляйте различающие слова на виду. Убирайте воду вместо того, чтобы вводить произвольный лимит символов. Плохо:
All_The_Working_Documents_For_The_Acme_Rebrand. Хорошо:Acme_Rebrand_Working. - Меньше лишней пунктуации. Простые буквы, цифры, подчёркивания и дефисы удобнее для скриптов. Плохо:
Client's Draft (Approved?). Хорошо:Acme_Proposal_v03. - Один термин — одна роль. Не чередуйте Exports, Output и Rendered, когда имеете в виду одно и то же место. Плохо: соседние папки
ExportsиExported_Files. Хорошо: одна задокументированная05_Exports. - Отделяйте версию от утверждения. Плохо:
logo FINAL new 2.ai. Хорошо:Acme_Logo_v03.aiвнутри03_Source, если это ваше определённое место для редактируемых мастер-файлов. Утверждение фиксируйте в записи о сдаче, а не дописывая Final ещё раз.
Переименовывайте осознанно
Номер версии обозначает ревизию, но не доказывает утверждение. Точно так же папка Old не объясняет, заменено ли её содержимое, отклонено или хранится для справки.
Хорошее имя описывает элемент. Хорошая запись объясняет, что с ним произошло.
Имена сохраняют смысл, когда файлы копируют, синхронизируют или архивируют. Цвет и значки такую ответственность в одиночку нести не могут.
Для уже накопленной коллекции используйте процесс с предпросмотром, например описанный в нашем руководстве по пакетному переименованию файлов на Mac. Перед применением изменений проверьте дубли в назначении и связанные файлы.
Назовите папку проекта при создании и не меняйте имя, пока не изменился объём работ. Любое переименование фиксируйте в README: прежнее имя и причина.
Почему у папок, тегов и смарт-папок разные задачи
Папки — это библиотечные полки. Теги — стикеры, приклеенные к книгам. Смарт-папки — сохранённые поиски, которые показывают все книги, подходящие под условие, не снимая их с полок.
Это различие важно, потому что вы отвечаете на разные вопросы: Где это должно лежать? Что требует внимания? Что я хочу видеть вместе? Руководство Apple по организации файлов в Finder описывает вложенные папки, теги и смарт-папки как взаимодополняющие способы организации и поиска.
| Механизм | Перемещает файлы? | Подходит для | Где даёт сбой |
|---|---|---|---|
| Вложенные папки | Да, когда вы переносите в них элементы | Устойчивая принадлежность: клиент, этап или тип ресурса | Слишком много уровней или слова-статусы, меняющиеся каждую неделю |
| Цветные теги | Нет | Временные приоритеты: Review или Urgent | Навешены на каждый файл, и тег теряет смысл |
| Смарт-папки | Нет | Сохранённые представления по правилам: PDF, изменённые в этом месяце | Правила настолько широкие, что показывают вообще всё |
Создание пустой папки ничего не перемещает. Различие в таблице в том, что раскладывание по папкам меняет физическое расположение элемента, а теги и сохранённые поиски — нет.
Постоянный дом и меняющийся взгляд
Допустим, вы готовите презентацию для клиента. Редактируемая презентация живёт в папке Working проекта. Пока ждёте отзывов, повесьте на неё тег Review, а когда проверка закончится, снимите.
Переносить презентацию в отдельное дерево Needs_Review не нужно. Это поставило бы её расположение в зависимость от временного состояния, и коллеги могли бы потом искать файл там, где он лежал раньше.
Смарт-папка отвечает на более широкий вопрос. Например, соберите недавно изменённые PDF по всем активным проектам или покажите файлы с тегом Work. Дорабатывайте правила, пока результат не начнёт помогать в конкретной задаче, а не воспроизводить всю вашу коллекцию файлов.
Приёмы навигации, поддерживающие такие представления, ищите в наших советах по Finder на Mac. Выбирайте вид под задачу: режим колонок — чтобы проследить расположение, визуальный предпросмотр — чтобы узнать ресурс по внешнему виду.
Не злоупотребляйте сигналами внимания
Urgent перестаёт работать, когда он висит на всём. Определите, что заслуживает каждого рабочего тега и кто его снимает; иначе вчерашний приоритет превратится в постоянное украшение.
Если трудность отчасти в том, чтобы удерживать внимание, советы Яна Кучеры по организации для основателей с СДВ — полезный дополнительный ресурс для размышлений о личной организации. Держите свой словарь тегов достаточно небольшим, чтобы применять его, не споря с самим собой о названии.
Правило выбора такое: если ответ меняется за время жизни проекта — используйте тег. Если остаётся прежним до конца проекта — папку. Если нужно переиспользуемое представление поверх всех этих мест — смарт-папку.
Насколько глубоко вкладывать папки, пока структура не сломалась
Глубина должна определяться потребностями поиска, а не привычкой. Отдельная папка оправданна, когда сужает поиск понятным людям образом. Меньше пользы, если она лишь добавляет ещё один контейнер под названием Project, Files или Assets.
Статья Evaluate, Reorganize, and Share описывает семантическую организацию как способ помочь пользователям рассуждать о расположении, а не запоминать точные пути. Это правильный тест для нового уровня: делает ли его имя оставшийся выбор яснее?
На схеме видно, как растут затраты на навигацию по мере роста дерева.
Дайте каждому уровню свою роль
Считайте это рекомендуемыми схемами, а не измеренными пределами. Считайте уровни ниже корня проекта и добавляйте новый, только когда он выражает полезное различие.
| Ситуация | Уровни | Когда добавлять уровень |
|---|---|---|
| Небольшой личный проект | Категория, затем файлы | В категории есть отдельные группы, которые вы регулярно ищете по отдельности |
| Постоянная работа для клиента или студии | Категория, группа ресурсов, затем файлы | У этапа или типа ресурса есть собственные отдельные результаты |
| Командный проект с отдельными владельцами | Зона ответственности, категория работ, затем файлы | Участникам нужны отдельно управляемые области и права доступа |
| Многолетнее исследование или архив кода | Период, проект, категория, затем файлы | Повторяющиеся трудности с поиском выявляют недостающую группировку |
Папка с именем коллеги сама по себе ничего не защищает. Где нужна защита, права доступа настраивайте отдельно.
Представьте гипотетический путь, зарытый под Working, Concepts, Campaign, Digital, Social, Approved, Revised и Export. Сплющите его до 04_Working/Social/Acme_Campaign_v03.ai, а сгенерированную копию для сдачи положите в предназначенное для экспорта место. Имя файла указывает ревизию, и не нужна отдельная папка под каждое решение.
Проверяйте поиск, а не считайте клики
Попросите коллегу найти референсный ресурс, редактируемый файл, запись об утверждении, сданный результат и архивную ревизию. Понаблюдайте, где он замешкается, и отметьте, нашёл ли он именно нужный элемент, а не просто что-то похожее.
- Постоянные возвраты назад говорят о пересекающихся названиях категорий.
- Открывание всех соседних папок подряд говорит о том, что группировка не соответствует задаче поиска.
- Нахождение устаревшей ревизии говорит о том, что записям о версиях или сдаче нужно внимание.
Лишние уровни ещё и усложняют совместную передачу дел и затрудняют проверку того, что попало в резервную копию. Добавляйте подпапки там, где их оправдывает содержимое, а не там, где симметричное дерево выглядело бы аккуратнее.
Добавьте слой цвета и значков, ничего не сломав
Цветной корешок папки помогает заметить папку. Подпись всё равно говорит, что внутри. Оформление папок должно работать так же: быстрая подсказка, а не главный источник истины.
Аналогия с бумажными папками хорошо показывает это различие.
Выберите цветовую гамму для стадии жизненного цикла и значок для роли содержимого. Эти измерения уживаются вместе: рабочая видеопапка может получить цвет активной работы и значок плёнки.
| Значение | Цвет или значок | Типичные папки |
|---|---|---|
| Активная работа | Одна цветовая гамма, например синяя | 03_Working, 04_Analysis |
| Результаты для сдачи | Одна цветовая гамма, например зелёная | 04_Deliverables, 05_Outputs |
| Архив | Нейтральный серый | 99_Archive |
| Видеоматериал | Значок плёнки | Папки с исходным видео |
| Дизайн-ресурсы | Значок кисти | 02_References, 03_Source |
| Код | Значок кода | src, tests |
| Документы | Значок страницы | 01_Admin, 01_Contract |
Используйте небольшой повторяемый словарь
Не придумывайте для каждого проекта совершенно новый визуальный язык. Осмысленные различия оставьте для тех отличий, которые вам нужно замечать, пролистывая Finder.
Документация Apple о расширенных атрибутах подтверждает, что элементы файловой системы могут нести связанные метаданные. Относитесь к оформлению папки как к такой вспомогательной информации, отдельной от содержимого проекта и расположения в каталогах.
В Tintd наш Folder Watcher отслеживает новые папки в выбранных местах и автоматически применяет подходящие цвет и значок по их именам. Наш пакетный редактор может применить значок сразу к выбранным папкам, а контекстное меню Finder отвечает за отдельные изменения; любую настроенную папку можно вернуть к исходному значку macOS одним щелчком.
Смена значка или цвета папки — чисто косметическая. Она не затрагивает файлы и вложенные папки внутри и не меняет их пути.
Видео ниже показывает, как применяется визуальный слой.
Подумайте о других Mac и других инструментах
Пользовательские значки папок хранятся локально на каждом Mac, поэтому настраивайте их отдельно на каждом Mac, которым пользуется ваша команда. Передавайте соответствия в виде письменной инструкции и не считайте, что у всех будет одинаковый внешний вид.
Подробнее об этом подходе читайте в нашем руководстве по визуальному файловому менеджеру. Полезно различать более быстрое узнавание и надёжную интерпретацию: знакомый значок помогает заметить каталог, но новичку всё равно нужны его имя и задокументированное назначение.
Копии, синхронизация или архивы, сделанные инструментами, которые отбрасывают метаданные, могут потерять оформление. Проверьте реальный способ передачи, прежде чем полагаться на внешний вид, и держите README как запись того, что означают визуальные соглашения.
Раз в квартал разбирайте архив, чтобы всё продолжало работать
Структура папок проекта — это живая система. Новые участники, пересмотренные результаты и неожиданные исходные материалы могут сделать разумную начальную схему менее удобной.
Рекомендации Университета Аризоны по организации данных поддерживают разделение оригиналов и рабочих файлов и документирование того, как устроен материал. Сделайте это постоянной обязанностью, а не задачей на этапе настройки, к которой вы больше не возвращаетесь.
Используйте жизненный цикл ниже как ритм проверок.
Переносите проект, когда меняются его задачи
- От входящего к активной работе: переносите входящие материалы в нужную категорию, как только определили их назначение и владельца.
- От активной работы к проверке: пересматривайте схему, когда заканчивается этап, подключается новый участник или люди раз за разом кладут материалы не туда.
- От проверки к сдаче: зафиксируйте утверждённый результат и сохраните точную переданную копию.
- От сдачи к архиву: архивируйте, когда владелец подтвердил, что активные обязательства выполнены.
- От архива к удалению: удаляйте только после окончания применимого срока хранения и с одобрения ответственного владельца.
Архивирование — это не резервное копирование, и ни то ни другое не даёт разрешения на удаление. Держите эти решения раздельно.
Назначьте в README владельца организации, указав имя конкретного человека, а не расплывчатое название команды. Он одобряет реорганизации и записывает, что изменилось, чтобы коллеги не перекраивали общие пути каждый по-своему.
Проводите квартальную проверку
Сравните активный верхний уровень с шаблоном, затем изучите исключения.
- Устраните дрейф: переименуйте непонятные добавления, проверив ссылки, скрипты и зависимости коллег.
- Уберите пустую структуру: удалите ненужные пустые папки и объедините пересекающиеся категории, предварительно изучив их содержимое.
- Выведите завершённую работу: перенесите проект целиком в
99_Archiveна уровне родителя или на архивный том. - Сохраните контекст: оставьте README с датой, статусом проекта, владельцем, местом сдачи и инструкциями по хранению.
Не кладите проект в архивную подпапку внутри него самого. Внутренний архив используйте для заменённых материалов во время работы, а архив уровня родителя — для завершённых проектов.
Если планируете визуально, загляните в заметки о визуальных конспектах от Walling — там есть дополняющие способы фиксировать решения. Результаты обязательно возвращайте в запись о проекте.
Последовательность не значит одинаковую глубину везде. Оставляйте полезные исключения и убирайте категории, которые больше не помогают. Сегодня поставьте в календарь регулярную квартальную проверку, запланируйте проверку по завершении текущего проекта и на этой неделе сохраните чистый шаблон для следующего.
Tintd добавляет собственные цвета и значки папок к структуре, которую вы уже определили, с пакетным управлением для существующих папок и автоматическим оформлением новых. Загляните на Tintd, чтобы дать активной работе, сдаваемым материалам и архивам единые визуальные подсказки, не трогая файлы внутри.