Структура хранения проектов

cover! white

О том, как больше не мучать себя беспорядком в рабочей папке и находить проект со скоростью обслуживания болида на пит-стопе

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

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

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

Не усложняй

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

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

Базовые правила

  1. Должен быть универсальный шаблон для новых проектов;
  2. Каждый проект хранится в отдельной папке;
  3. Имя папки должно содержать имя клиента и проекта;
  4. Все файлы, относящиеся к проекту разбиваются на 5 категорий и хранятся в соответствующих директориях;
  5. Версии рабочего файла идут через двойную нумерацию с префиксами -001-01, -002-01 и т. д.;

Шаблоны

Для экономии времени на организацию каталога в новом проекте, использую папку-шаблон _Inc Project. Нижний слэш переносит папку вверх списка.

В ней хранятся ряд других папок, для дополнительных файлов:

Approved — Финальные файлы, на передачу;

  • Data — Для документации, заданий и исходников высланных клиентом;

Revision — PNG макеты для обсуждения и комментариев. Если проект идет в сбор на Invisionapp, каждую итерацию правок я сохраняю в поддиректоритою с указанием даты и времени. Например, «2016-05-17 13.20»;

  • Source — содержит в себе все данные, которые я нашел для данного проекта или посчитал интересными: Скриншоты, ссылки на сайты-примеры, фотографии с фотостоков. Все это опять же сортируется в поддиректории buy, search, url.
Помимо папок, корень содержит в себе еще два файла-шаблона для Illustrator и Sketch и служит основной директорией для рабочих файлов.

Ранее для рабочих файлов я использовал папки с именами WIP (work in progress), затем просто work, пока не понял что эту папку использовал строго для того чтобы файлы не пошли вперемешку с остальными. А раз все прочие уже раскиданы по другим дополнительным папкам, то зачем делать лишние телодвижения и двигаться в отдельную папку, когда корень проекта идеально подходит для основных исходников?

Имена файлов

Все достаточно просто. Люди придумали много вариантов того, как называть файл (особенно для верстки), но я как человек чаще творящий и значительно реже верстающий (и то сугубо для своего бложика) никаких особых правил по именам не придумывал.
Их всего 3:

  1. Называть файл понятно и доступно: call-me-latter.psd — значит картинка для блока «перезвонить» на сайте;
  2. Приоритетный файл проекта включать вверх нижним слешэм, вспомогательным исходникам давать простые имена;
  3. Использовать дедуктивный метод сортировки, в котором первое число — итерация для клиента, а второе — личная.
Проект прошел одну итерацию с заказчиком. Его имя _store-new-tp-002-02.ai

Сортировка проектов

Я пробовал сортировать проекты по годам и месяцам. Это было худшим решением за всю жизнь, потому что если для одного и того же клиента делался ряд проектов и мы не помнили когда именно решали задачу — поиск исходников становился неэффективным и затратным по времени. Чаще всего именно так и происходило.

Затем стал заводить одну общую папку для конкретного клиента и уже в ней держал проекты, а в начале писал дату формата гггг-мм.
При обслуживании постоянных клиентов это обретало смысл. Хотя сейчас понимаю, что достаточно было просто писать версию «переиздания», а не ссылаться на даты.
Ниже можно наблюдать структурирование папок с 2009 по 2016 года.

Структура образца 2009-11, когда было все раскидано по годам. В 11 году начал добавлять папку Source. Структура была старой, как в прошлом слайде. Позже в 2012 году просто навел порядок. Ближе к концу 2012 составил полный список папок. В 2013 список папок утвердился до необходимого минимума. 2016, Обновленная структура папок. Удалена папка WIP, которая до удаления уже звалась work.
В качестве примеров прилагаю скриншоты папки клиента SDI Solution. Именно тут видно как я пробовал различные варианты и отказывался от разных функций.

Согласитесь, удобнее искать по имени, а не привязке к дате.

Кто-то спросит: Зачем в папке имени проекта фигурирует имя клиента?
Ответ: Папка с конкретным проектом, отправленная по почте теряет часть структуры и начинается боль, если таких папок больше чем одна. Я сохранил однажды на флешку несколько проектов от разных клиентов, а имена папок были «A4 акция» и «А4 + Диск», ругался на себя пока не надоело путаться и не переименовал папки по-человечески.

Сортировка папок

Итак, с внутренними папками клиентов мы разобрались. А как быть, когда число клиентов перешло за первую десятку?

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

При переходе на мак, я не стал дублировать проекты с компьютера и просто создал новую папку. Это фигурирует во всех скринах, но смысла на это обращать внимания нету.

Компании прописываю капсом. Так оказалось проще отличать компанию от частного лица или того хуже от кого-то залетного, но требующего остаться на сохранении.

Поделиться
Отправить
Запинить
Популярное