Существует ли стандартное соглашение об именах для этапов проектирования, например, для раундов ревизий, а не просто Концепция 1, Концепция 2 и т. д .?
Я знаю, что мое агентство использует стадию концепции , затем копирует макет, затем Keyline 1, 2, 3 и т. д ., но я чувствую, что это не имеет смысла, когда я сообщаю о текущей фазе работы, когда отправляю ее клиентам. .
Пример: «Вот изменения, которые вы запросили из последней фазы ключевой линии. Сейчас мы переходим к ключевой линии 2 с любыми дальнейшими изменениями».
Соглашения об именах зависят от того, что работает для каждого сотрудника/отдела/компании.
Я использую соглашения, которые имеют смысл для меня. Я либо отмечаю дату, например rev0807 , либо _draft, _revision, _final и т. д.
Важно, чтобы их можно было идентифицировать, поэтому я стараюсь быть довольно конкретным. Если кто-то помимо меня будет вносить изменения, я могу использовать _sarah_rev_0807 .
Не думайте, что существует какой-то стандарт, но могут быть внутренние стандарты, созданные вашей организацией или вашими собственными.
После 12 лет работы в бизнесе и использования различных схем именования я обнаружил, что наиболее полезным для меня является называть черновики числами. Например. 01, 02, 03 и т. д. Будет отдельная папка с превью, отправленными клиенту на разных этапах, и они также будут называться 01, 02, 03 и т. д.
Что касается даты, каждому из этих файлов назначена системная дата, которая хорошо видна в файловом браузере, поэтому я не буду указывать дату в именах файлов, хотя иногда это бывает полезно при отправке черновиков клиентам.
Для проектов, разрабатываемых в течение более длительного периода (несколько месяцев), я в какой-то момент сбрасываю этот счетчик и называю последний черновик «01» и удаляю старые черновики, особенно если промежуточный этап согласован с клиентом.
Затем, когда работа будет завершена и доставлена, в большинстве случаев я просто оставлю окончательный вариант для редактирования (в большинстве случаев без более старых версий), а также сделаю резервную копию окончательных результатов (jpg, pdf и т. д.).
Поскольку я работал в ИТ-фирме в течение достаточно долгого времени (и до сих пор работаю, кстати), я адаптировал соглашения о программном обеспечении точечных обновлений и обновлений версий. Я использую дату в качестве первой дифференциации, а номера версий в качестве второй.
Я также использую имя клиента и имя проекта, поэтому моя окончательная структура папок выглядит примерно так:
Конечно, выбор того, когда использовать обновление версии и когда использовать точечное обновление, является произвольным. Но обычно вы знаете, что есть что. И поскольку большинство людей знакомы с этой системой (особенно с учетом того, что обновления приложений настолько распространены и быстры), они поймут ее и будут придерживаться ее.
джуджа