Controle de Versões em Projeto de Arquitetura: R00 a R0X

Quando o caos começa

Versão sem regra vira arquivo duplicado, envio errado e aprovação sobre material antigo. O time perde tempo tentando descobrir qual é o documento válido. E quando descobrem que o cliente aprovou a planta R01 enquanto o escritório já estava trabalhando na R03, o retrabalho é inevitável.

Se você já viveu a situação de receber um e-mail do fornecedor perguntando "qual é a planta atualizada?" ou de um freelancer que passou duas semanas trabalhando sobre uma versão desatualizada, sabe exatamente o custo de não ter controle de versões. Não é uma questão de organização pessoal — é um problema sistêmico que impacta prazos, custos e confiança do cliente.

O controle de versões não precisa ser complicado. Precisa ser consistente. Uma nomenclatura clara, regras definidas para quando criar nova versão e um ponto único de consulta resolvem 90% dos problemas. Este artigo mostra como implementar isso na prática.

A nomenclatura que funciona: R00, R01, R02

A convenção mais usada em escritórios de arquitetura no Brasil é a numeração por revisão, usando o prefixo R seguido de dois dígitos.

R00 — Primeira emissão. É o documento original, nunca revisado. Quando você emite a planta pela primeira vez para o cliente ou para a obra, ela sai como R00.

R01 — Primeira revisão. Houve alteração formal após a emissão R00. Pode ser uma correção de erro, um ajuste solicitado pelo cliente ou uma alteração de projeto.

R02, R03, R04... — Revisões subsequentes. Cada alteração formal gera um novo número.

Por que R e não V

Muitos escritórios usam "V1, V2, V3" (versão). Funciona também, mas "R" tem uma vantagem: diferencia emissão de trabalho interno. A revisão é algo formal, compartilhado externamente. O trabalho interno pode ter dezenas de salvamentos entre uma revisão e outra, sem que cada um gere um novo R.

Nomenclatura completa de arquivo

Um bom nome de arquivo inclui quatro informações:

• Código ou nome do projeto
• Tipo de documento (planta, corte, detalhe, memorial, 3D)
• Disciplina (arquitetura, elétrica, hidráulica, interiores)
• Revisão

Exemplos:

• PRJ042-PLANTA-LAYOUT-ARQ-R00.dwg
• PRJ042-PLANTA-LAYOUT-ARQ-R01.dwg
• PRJ042-CORTE-AA-ARQ-R00.dwg
• PRJ042-MEMORIAL-DESCRITIVO-R02.pdf

A data não precisa estar no nome do arquivo. A data está nos metadados do arquivo e no registro de revisão. Incluir a data no nome cria situações como PRJ042-PLANTA-LAYOUT-ARQ-R01-15MAR2026-FINAL.dwg — nomes enormes que confundem mais do que ajudam.

Quando criar uma nova revisão

Nem toda alteração precisa gerar nova revisão. Se a cada salvamento você cria um novo R, em uma semana estará na R17 — e ninguém vai acompanhar.

Crie nova revisão quando

• O documento foi compartilhado externamente (com o cliente, fornecedor ou obra) e precisa ser atualizado
• Houve alteração no escopo aprovada pelo cliente
• Erro técnico foi identificado após a emissão
• O cliente solicitou alterações que foram incorporadas

Não crie nova revisão quando

• Você está trabalhando internamente e fazendo ajustes menores
• O documento ainda não foi emitido para ninguém
• A alteração é cosmética (ajuste de layer, cor de prancha, posição de selo)

A regra de ouro

Se o documento já foi visto por alguém de fora do escritório, qualquer alteração gera nova revisão. Se ainda está em trabalho interno, mantenha na mesma revisão.

O registro de revisões

Toda revisão deve ser acompanhada de um registro que explica o que mudou. Sem isso, ninguém sabe por que a R03 é diferente da R02 — e ninguém vai comparar 47 pranchas para descobrir.

O que registrar

Para cada revisão, documente:

• Número da revisão: R01, R02, etc.
• Data da emissão
• Responsável: quem fez a alteração
• Descrição da alteração: o que mudou e por quê
• Solicitante: quem pediu a alteração (cliente, fornecedor, decisão interna)

Exemplo de registro

• R00 — 10/fev/2026 — Ana — Emissão inicial do layout para aprovação do cliente
• R01 — 18/fev/2026 — Ana — Cliente solicitou mudança na posição da ilha da cozinha. Alterada planta de layout e corte AA
• R02 — 03/mar/2026 — Pedro — Compatibilização com projeto elétrico. Ajustados 4 pontos de tomada na cozinha e 2 na lavanderia

Esse registro simples responde a perguntas como "quando foi que o cliente mudou a cozinha?" ou "por que a posição do ponto elétrico é diferente do que eu lembro?" sem que ninguém precise vasculhar e-mails antigos.

Organização de pastas

A estrutura de pastas é o complemento da nomenclatura. De nada adianta ter nomes padronizados se os arquivos estão espalhados em 5 pastas diferentes. Se o seu escritório ainda não tem uma estrutura de pastas por etapas do projeto, comece por aí.

Estrutura recomendada

PRJ042-Apartamento-Itaim/
├── 01-Briefing/
├── 02-Levantamento/
├── 03-Estudo-Preliminar/
├── 04-Anteprojeto/
├── 05-Projeto-Executivo/
│   ├── Arquitetura/
│   ├── Elétrica/
│   ├── Hidráulica/
│   └── Interiores/
├── 06-Acompanhamento/
├── 07-Entregues/
│   ├── R00/
│   ├── R01/
│   └── R02/
└── 08-Referências/

A pasta "Entregues"

A pasta 07-Entregues é o ponto de verdade do projeto. Cada subpasta contém exatamente o que foi enviado ao cliente naquela revisão. Isso serve para:

• Rastreabilidade: saber exatamente o que o cliente recebeu em cada emissão
• Proteção jurídica: se houver disputa sobre o que foi aprovado, o registro é claro
• Referência para a obra: o mestre de obras ou o fornecedor recebem o link da pasta da revisão atual, não um arquivo solto

Regra importante

Nunca edite arquivos na pasta "Entregues". Ela é um registro histórico. Se precisar fazer alteração, copie o arquivo para a pasta de trabalho (05-Projeto-Executivo), altere, e quando estiver pronto, emita uma nova revisão com cópia na pasta "Entregues/R0X".

O ponto único de verdade

O maior problema de versionamento não é nomenclatura — é distribuição. Quando o cliente tem uma versão no e-mail, o fornecedor tem outra no WhatsApp, e o freelancer tem uma terceira que baixou da nuvem há duas semanas, o caos está instalado.

O princípio

Deve existir um único lugar onde a versão atual de cada documento pode ser consultada. Não importa se é uma pasta na nuvem, um sistema de gestão ou um servidor de arquivos — o que importa é que todo mundo sabe onde ir e que esse lugar está sempre atualizado.

Na prática

• Defina onde ficam os arquivos oficiais (ex: pasta compartilhada do projeto, módulo de arquivos do sistema de gestão)
• Quando emitir nova revisão, atualize nesse local imediatamente
• Avise as partes envolvidas que há nova revisão disponível
• Nunca envie arquivos por e-mail como fonte principal — envie o link para o local onde o arquivo está

O problema do e-mail

E-mail é péssimo para versionamento. O arquivo fica "congelado" na caixa de entrada do destinatário. Se você envia a R01 por e-mail em fevereiro e emite a R02 em março, o fornecedor que não viu o segundo e-mail continua trabalhando com a R01. Por isso, sempre que possível, compartilhe links em vez de anexos.

Versionamento com freelancers

Freelancers são o ponto mais vulnerável do versionamento. Eles entram e saem do projeto, nem sempre têm acesso ao sistema do escritório, e frequentemente trabalham com arquivos baixados uma vez.

Boas práticas

Defina a versão base no briefing. Ao enviar o trabalho para o freelancer, especifique exatamente qual revisão é a base: "Trabalhe sobre a R01 do layout, que está na pasta X."

Bloqueie o acesso à pasta após o envio. Se possível, dê acesso somente leitura à pasta de referência. O freelancer baixa, trabalha no seu ambiente e devolve. Ninguém edita o original.

Cheque a versão na entrega. Antes de aceitar o trabalho do freelancer, confirme que ele trabalhou sobre a revisão correta. É mais rápido conferir no início do que descobrir o erro depois de incorporar.

Nomeie a entrega do freelancer de forma clara. O freelancer deve devolver o arquivo com o nome padronizado do escritório, não com o nome que ele usa internamente.

Versionamento no fluxo de aprovação

O ciclo de aprovação com o cliente é o momento onde o versionamento mais importa — e onde mais falha.

O fluxo ideal

1. Emissão: o escritório emite a R00 do documento e disponibiliza para o cliente
2. Revisão do cliente: o cliente analisa, faz comentários e solicita alterações
3. Incorporação: o escritório incorpora as alterações e emite a R01
4. Aprovação: o cliente aprova formalmente a R01
5. Registro: a aprovação é registrada com data, versão e forma de aprovação

O problema da aprovação informal

"Aprovado!" por WhatsApp na R00 não tem valor quando, três meses depois, o cliente diz que nunca aprovou aquela parede na posição que está. Um portal do cliente resolve esse problema com aprovações registradas automaticamente. Sem registro formal vinculado à revisão específica -- e sem uma cláusula clara no contrato -- a palavra do cliente vale tanto quanto a sua.

A melhor prática é usar um sistema que registre a aprovação com timestamp e vinculação à versão exata. Se não tiver sistema, no mínimo registre por e-mail com o PDF da versão aprovada em anexo e a confirmação explícita do cliente.

Erros comuns no controle de versões

1. O clássico "FINAL". Planta-FINAL.dwg, Planta-FINAL-2.dwg, Planta-FINAL-CORRIGIDA.dwg, Planta-FINAL-DEFINITIVA.dwg. Se você usa a palavra "final" no nome do arquivo, já perdeu o controle. Use R00, R01, R02. Sem adjetivos.

2. Não atualizar o ponto de verdade. Você emite a R02, manda por e-mail para o cliente, mas esquece de atualizar a pasta compartilhada. O fornecedor que consulta a pasta continua vendo a R01.

3. Revisão sem registro. A R03 existe, mas ninguém sabe o que mudou em relação à R02. Sem descrição da alteração, a revisão perde metade do valor.

4. Editar o arquivo "original". Em vez de criar nova revisão, alguém edita diretamente o arquivo da R01 e salva por cima. O histórico se perde.

5. Múltiplas fontes de verdade. A planta está no Google Drive, no Dropbox do freelancer e no e-mail do cliente. Três versões, nenhuma confiável.

6. Não comunicar a nova revisão. Emitir R02 e não avisar quem está usando a R01 é tão ruim quanto não emitir.

Perguntas frequentes

Quantas revisões são normais em um projeto?

Depende do porte e da complexidade, mas para um projeto residencial típico, espere entre 2 e 4 revisões por documento principal (planta de layout, planta elétrica, etc.). Projetos com muitas decisões do cliente ou compatibilizações complexas podem chegar a 6-8 revisões. Se está passando de 10, provavelmente há problema no briefing ou na comunicação.

Devo manter todas as revisões antigas ou posso deletar?

Mantenha sempre. As revisões antigas são registro histórico e proteção jurídica. Ocupam pouco espaço e podem ser necessárias em caso de disputa, auditoria ou simplesmente para entender por que uma decisão foi tomada.

Como gerenciar versões quando há múltiplas disciplinas?

Cada disciplina tem sua própria sequência de revisões. A planta de arquitetura pode estar na R03 enquanto a elétrica está na R01. O importante é manter o registro de compatibilização: quando a elétrica atualiza, a arquitetura precisa ser verificada.

Versionamento funciona para 3Ds e renders?

Sim, mas com uma particularidade: renders são mais pesados e geralmente são entregas pontuais, não documentos vivos. Use a mesma lógica de R00, R01, mas considere que renders são "snapshots" de um momento do projeto, não documentos que evoluem continuamente.

Preciso de software específico para controle de versões?

Não necessariamente. Um sistema de pastas bem organizado com nomenclatura consistente resolve para a maioria dos escritórios. Mas se o time tem mais de 3 pessoas ou trabalha com muitos freelancers, um sistema de gestão que centraliza arquivos com controle de acesso e histórico facilita muito a vida.

Controle de versão é infraestrutura

Versionamento não é detalhe operacional. É o que sustenta aprovação, execução e responsabilidade sobre o que foi entregue. Sem controle, cada revisão é uma aposta de que todo mundo está olhando para o mesmo documento. Com controle, é certeza.

Comece pelo básico: nomenclatura R00/R01/R02, estrutura de pastas padronizada e um ponto único de verdade. Se você quer organizar todo o escritório de forma integrada, veja nosso guia de organização de escritório de arquitetura. Depois, evolua para registro de revisões com descrição e fluxo de aprovação formal. O ganho aparece na primeira vez que alguém pergunta "qual é a versão atual?" e você responde em 3 segundos.