MÓDULO 2 — ANTES DO PRIMEIRO DESENHO – ARTIGO 5/40
Você recebeu o projeto, abriu a pasta do cliente e encontrou plantas antigas, levantamentos e um Termo de Referência. A tentação é conhecida: fazer uma leitura rápida, entender “mais ou menos” o pedido e partir logo para o desenho.
É aí que muitos problemas começam.
Semanas depois, o cliente cobra uma entrega que o escritório não considerava incluída. Em seguida, descobre-se que falta um levantamento. Mais adiante, alguém percebe que determinada aprovação deveria fazer parte do trabalho. E surge a pergunta clássica:
“Mas isso não estava no escopo?”
Antes de desenhar qualquer linha, existe uma tarefa fundamental: entender o que foi contratado, o que precisa ser entregue, quem responde por cada atividade e quais informações ainda faltam.
O Termo de Referência (TR) não é burocracia de abertura. Ele ajuda a transformar uma demanda ainda abstrata em um processo profissional organizado.
Leia procurando obrigações
Um TR pode citar arquitetura, estrutura, instalações, aprovações e levantamentos. Mas reconhecer os assuntos não basta.
Se o documento menciona “projeto de instalações elétricas”, por exemplo, você ainda precisa saber: quem desenvolve? Está no escopo do escritório? Será contratado pelo cliente? Qual nível de desenvolvimento é esperado? Que informação a arquitetura fornece?
Uma leitura ativa procura verbos e responsabilidades: ENTREGAR, FORNECER, COMPATIBILIZAR, APROVAR, VALIDAR, CONTRATAR.
Isso ajuda a separar três questões:
- Escopo: o que precisa ser desenvolvido?
- Limite de atuação: até onde vai o serviço contratado?
- Responsabilidade: quem responde por cada atividade?
Quando essas respostas não estão claras, o projeto começa com uma dívida de informação que costuma reaparecer como atraso, retrabalho ou conflito.
Entenda os entregáveis — e os limites
“Projeto de arquitetura” pode significar coisas muito diferentes. Pode envolver apenas determinadas etapas ou chegar ao Projeto Executivo, compatibilização, memoriais, quantitativos e documentação para aprovação.
Por isso, é preciso entender o produto final: etapas, nível de detalhamento, formatos, prazos e critérios de aprovação.
Também existe uma distinção essencial: uma coisa é o empreendimento precisar de determinado serviço; outra é esse serviço fazer parte do seu contrato.
Topografia, cadastro, sondagem, estrutura ou instalações podem ser indispensáveis ao projeto sem serem responsabilidade contratual do arquiteto.
O coordenador precisa responder a duas perguntas ao mesmo tempo: “eu preciso dessa informação?” e “quem deve fornecê-la?”
Isso evita assumir tarefas não contratadas e impede que uma atividade essencial fique esquecida.
Procure o que está faltando
Uma boa leitura do TR não identifica apenas obrigações. Ela também revela ausências.
Existe levantamento topográfico? Há cadastro confiável da edificação? A sondagem foi feita? Os projetistas complementares estão definidos? Há padrões de entrega ou prazos de aprovação? Alguma informação depende do cliente?
O resultado da análise não precisa ser “entendi tudo”. Um diagnóstico mais útil é:
“Isso está claro. Isso está inconsistente. Isso está faltando. Isso depende de confirmação.”
Perguntar no início não demonstra insegurança. Uma pergunta bem formulada mostra que você percebeu uma dependência antes de ela virar problema.
- “Quem fornecerá o levantamento?”
- “A aprovação nos órgãos competentes faz parte do escopo?”
- “Quem contratará os projetos complementares?”
- “O Projeto Executivo inclui quantitativos?”
A pior dúvida não é a que aparece na primeira reunião. É a que fica escondida até o meio do projeto.
Em trabalhos com muitos agentes, vale transformar a leitura em uma matriz simples:
atividade → responsável → informação necessária → validação → prazo
Não é burocracia. É uma forma de tornar dependências visíveis.
ERRO COMUM
Ler o Termo de Referência uma única vez e confiar na memória.
Quando isso acontece, o escopo passa a ser “descoberto” durante o projeto e, mais tarde, aparecem discussões sobre prazo, responsabilidade ou honorários.
A melhor defesa é extrair as exigências do TR para uma lista de controle. Exigências técnicas, normas citadas, formatos de entrega, prazos, critérios de aprovação e pontos ambíguos precisam sair do PDF e entrar no sistema de trabalho do escritório.
NA PRÁTICA
Imagine um escritório contratado para desenvolver uma reforma até o Projeto Executivo. Durante o planejamento, a equipe percebe que precisa de um levantamento cadastral preciso da edificação.
O cliente acredita que o levantamento está incluído no contrato. O escritório entende que deveria ser fornecido pelo cliente. Ninguém esclareceu isso no início.
Sem o levantamento, a arquitetura perde uma base confiável. Se a equipe avançar com desenhos antigos, uma ambiguidade contratual começa a produzir risco técnico: incompatibilidades, retrabalho e problemas na obra.
Por isso, o primeiro produto do projeto pode não ser um croqui. Pode ser uma lista de pendências e perguntas.
Antes de produzir soluções, você está melhorando a qualidade das informações sobre as quais essas soluções serão construídas. E a lógica continua a mesma:
informação → decisão → documentação → compatibilização → execução
Se a informação inicial estiver frágil, toda a cadeia também estará.
NO PRÓXIMO ARTIGO
Depois de compreender o que fomos contratados para fazer, surge outra pergunta: o que o empreendimento realmente precisa atender?
É aí que entra o Programa de Necessidades. No próximo artigo, veremos por que uma lista de ambientes não basta e como transformar pedidos e desejos do cliente em requisitos capazes de orientar decisões de projeto.
Texto de Álvaro Letelier
