dicas

Faz tempo que desejo falar sobre como organizar arquivos, mas só tomei coragem hoje, quando o pessoal gente boa da EVCom publicou a imagem abaixo, uma brincadeira com a (des)organização de arquivos por parte do pessoal de criação.

Claro que achei graça, já vivi bastante isto, especialmente quando trabalhava como designer. Mas hoje acho que o pessoal de criação e afins é desnecessariamente desorganizado. Para ser justo, eu tinha o mesmo discurso. E a não ser que trabalhem em algo ou em alguma empresa que exija padronização, quase ninguém se preocupa com nomes de arquivo. E comisso, acaba por passando muitos perrengues.

Já vi negócios serem perdidos por não acharem um arquivo correto, já vi gente deprimida por não conseguir encontrar uma foto importante, já vi gente trabalhando no fim de semana por não ter achado um lay-out certo. Eu também tive minha cota de problemas assim, mas percebi que se eu organizasse e fizesse algo que não toma 2 segundos, me pouparia grandes dores de cabeças e tempo útil, e fiquei “nóia” com organização de arquivos. Depois que trabalhei em empresa de tecnologia, fiquei über nóia.

Padronize

Uma das coisas mais importantes é padronizar. Além de cuidado com grafia, é importante criar um padrão que faça sentido e que possa ser compartilhado com a equipe, de forma que sem muito esforço possam lembrar.

Estou sempre procurando aperfeiçoar mas agora ou uso cliente-projeto-entregavel-versao (e.g. 2aces-site-layout.1.2.1.ai) ou cliente-projeto-entregavel-anomesdia-numerosequencial (e.g. fotografiadiaria-busca-pitch-20160106-10.pdf).

Quando não é coisa de trabalho, adapto o padrão, mas sempre sigo uma sequência lógica do mais geral para o mais específico: a imagem acima por exemplo, nomeei evcom-brincadeira-arquivosdecriativos (quemfez-otipodecoisaquefez-abrincadeiraespecífica)

Versionamento Semântico

Quando uso número de versão, ou é sequencial (i.e. 0, 1, 2, 3) ousigo o padrão de Versionamento Semântico de software (Semantic Versioning) com as devidas adaptações para o contexto (documento, imagens, lay-outs, etc).

Basicamente, são 3 números separados por ponto (e.g. 1.2.1) com cada grupo de número tendo um significado. Em software, o padrão estipula:

Dado um número de versão MAJOR.MINOR.PATCH, incremente a:

1. versão Maior(MAJOR): quando fizer mudanças incompatíveis na API
2. versão Menor(MINOR): quando adicionar funcionalidades mantendo compatibilidade, e
3. versão de Correção(PATCH): quando corrigir falhas mantendo compatibilidade.
   Rótulos adicionais para pré-lançamento(pre-release) e metadados de construção(build) estão disponíveis como extensão ao formato MAJOR.MINOR.PATCH.

Para documentos e planilhas, arquivos de Photoshop ou Ilustrator, imagens, etc, adapto para o contexto, mas basicamente é CONCEITO.MUDANÇA.CORREÇÃO:

1. Incremente o primeiro número apenas quando mudar o conceito ou abordagem para o documento (ou imagem, ou planilha, ou lay-out, etc). Se a versão é rascunho, trabalho em progresso, e não uma versão oficial ou acabada, uso 0 (zero).
2. Incremente o do meio  quando é mudança ou aperfeiçoamento dentro de um documento. Coisas como uma nova seção, novos gráficos, nova fotografia, etc.
3.  Incremente o último da direita quando fizer correção (revisão de texto, número errado, informação errada, etc),

Por exemplo, imagine uma pasta com diversos arquivos PDFs com o lay-outs de site:

Se ainda não apresentei ainda para o cliente, está na 6a versão de rascunho (sem considerar correções) teria versão 0.6.0 (e.g. 2aces-site-layout.0.6.0.pdf) se eu fizer uma correção de teste (estava escrito fodografia ao invés de fotografia) neste mesmo lay-out teria versão 0.6.1 (e.g. 2aces-site-layout.0.6.1,pdf)

No momento que considero o arquivo pronto para envio para o cliente, considero ele 1.0.0. Se antes de enviar eu encontrei um erro no logo do site e vou lá e corrijo, se torna 1.0.1. Se depois do envio o cliente pede uma alteração aqui e ali, esta primeira versão pós alterações se torna 1.1.0 e se passa por uma segunda alteração, 1.2.0, e revisão/correção sobre esta versão se tornaria 1.2.1, 1.2.2, etc.

Se eu fizer lay-outs totalmente diferentes pois o cliente não gostou ou se quero apresentar alternativas para ele escolher, estes serão versões diferentes, como 2.x.x, 3.x.x, etc.

Benefícios de padronização com versionamento semântico

Os benefícios de seguir este padrão são inúmeros:

• é possível dizer do que se trata o arquivo só pelo nome;
• todo mundo na equipe compartilha um padrão e fica fácil de todo mundo achar e saber de tudo (às vezes, até os clientes começam a entender isto);
• quando é preciso alguém pedir uma versão, não há ambiguidade e diminui a margem para erros e mal-entendidos: “A versão que está valendo é  a 1.2.1” é muito melhor que “A versão que está valendo é a alterado_azul22”
• facilita muito buscas no sistema operacional ou gerenciador de arquivo, você não perde um tempão procurando
• ajuda a entender qual mudança foi feita, quando, por quem e por quê
• Se você usar a data no padrão anomesdia, o arquivo fica ordenado corretamente na pasta quando organizada alfabeticamente

E acredite, à parte as tragédias que evitam, estes segundinhos e minutos que você ganha se transformam em horas.

Para finalizar

Duas últimas dicas

1. Evite usar espaço e caracteres especiais/acentuados
2. Evite usar abreviações.

O primeiro por quê nem sempre as buscas identificam um espaço ou caracter especial adequadamente e pode dar erro ao fazer uploads em certos servidores.

O segundo para evitar não encontrar um arquivo por quê não se sabia se estava abreviado, especialmente importante quando trabalhando em equipes. Por exemplo, e.g. o arquivo tem “vc” no nome, mas quem buscou, procurou por “você” ou buscar por SP (São Paulo) e encontrar um monte de arquivos com espaco (Espaço) no nome.

E você, como mantém seus arquivos?