Unindo BIM e Engenharia de Software para transformar a construção civil.
Engenheiro Civil & Engenheiro de Software
1ª Edição - 2026
A engenharia civil é uma das profissões mais antigas da humanidade. Construímos pirâmides, aquedutos e catedrais com precisão matemática muito antes de existir o computador. No entanto, nas últimas décadas, algo curioso aconteceu: enquanto outros setores abraçavam a revolução digital, nós trocamos a prancheta pelo CAD, mas mantivemos os mesmos processos mentais.
Vivemos uma estagnação perigosa. Aceitamos que "engenharia" é sinônimo de planilhas de Excel desconectadas, arquivos DWG perdidos em servidores locais e uma incomunicabilidade crônica entre o projeto e a obra. Chamamos isso de "tradicionalismo", mas o nome correto é ineficiência.
A Engenharia 4.0, o tal "BIM" que todos falam mas poucos praticam em sua plenitude, não é sobre fazer modelos 3D bonitos. É sobre tratar a construção como um problema de dados. É entender que um pilar não é apenas um desenho geométrico, mas uma entidade de informação que deve ser rastreável, quantificável e programável.
Minha trajetória não foi linear. Sou engenheiro civil de formação e vivi o dia a dia da profissão. Trabalhei com ferrovias, lidei com a complexidade de traçados, normas rígidas e a pressão por entregas em projetos de grande escala.
Aos 36 anos, no entanto, a frustração com a repetição manual me empurrou para uma nova direção. Eu me perguntava: "Por que estou gastando três dias para fazer algo que um computador faria em três segundos?".
Foi essa pergunta que me levou a buscar uma pós-graduação em Engenharia Ferroviária, para dominar a técnica, e outra em Engenharia de Software, para dominar a ferramenta. Fundei a ProjectData com essa visão: criar soluções que eu mesmo gostaria de ter usado anos atrás.
"Não sou um programador que acha que sabe construir. Sou um engenheiro que aprendeu a programar para construir melhor."
Hoje, divido meu tempo entre a gestão da empresa, o desenvolvimento de novos produtos e minha família. Com a chegada do meu filho, Vinicius, a gestão do tempo se tornou ainda mais crítica. A automação deixou de ser apenas uma vantagem competitiva profissional e se tornou uma necessidade pessoal para garantir qualidade de vida.
Este livro foi escrito com um perfil muito específico em mente:
Por outro lado, é importante alinhar expectativas. Este livro não é para você se:
Se você ficou no primeiro grupo, vire a página. Vamos começar a construir a sua nova caixa de ferramentas.
Bruno Dias
Engenheiro Civil
Campinas-SP, Outono de 2026
Capítulo 1
Se você entrar em qualquer escritório de engenharia hoje, seja uma pequena construtora familiar ou uma gigante de infraestrutura, você encontrará a mesma ferramenta aberta em 90% dos monitores: o Microsoft Excel.
O Excel é, sem dúvida, o "martelo" da engenharia moderna. Ele é flexível, acessível e permite que qualquer um crie uma solução rápida para um problema imediato. Precisa calcular o volume de concreto? Excel. Precisa fazer o cronograma da obra? Excel. Precisa controlar o estoque de EPIs? Excel.
O problema é que, para quem só tem um martelo, todo problema parece um prego. E na engenharia civil, muitos dos nossos problemas são parafusos complexos que exigem chaves de precisão, não marteladas.
O maior erro que cometemos na engenharia é confundir armazenamento de dados com planilha eletrônica. Parece a mesma coisa — afinal, ambos têm linhas e colunas — mas a diferença estrutural é abismal.
No Excel, a estrutura é visual, não lógica. Você pode pintar a célula A1 de amarelo para dizer que ela é "importante", ou mesclar B2 e C2 para criar um título bonito. Para um ser humano, isso faz sentido. Para um computador (e para a integridade dos seus dados), isso é um crime.
Em um banco de dados real, a estrutura é soberana. Se uma coluna é definida para receber datas, ela rejeitará qualquer texto. O banco "grita" se você tentar inserir "A definir" em um campo que deve conter dd/mm/aaaa.
No Excel, a célula aceita tudo. Nada impede um estagiário de escrever "A definir" na coluna de "Data de Entrega", transformando o que deveria ser um cálculo de prazo em um texto inútil. Pior ainda: nada impede que na aba "Janeiro" a coluna de "Custo Unitário" seja a C, e na aba "Fevereiro" seja a D, porque alguém inseriu uma coluna de observações no meio. Essa liberdade excessiva torna a automação impossível.
Quantas vezes você já abriu uma planilha com 50 abas? Uma aba para cada medição, ou uma aba para cada disciplina do projeto. Isso fragmenta a informação. Em um sistema robusto, você teria uma única tabela de "Medições" com uma coluna indicando o mês. Isso permite filtrar, somar e analisar o todo em milissegundos.
No modelo de "mil abas", para saber o custo total da obra, você precisa criar uma fórmula Frankenstein: =SUM('Jan'!Total, 'Fev'!Total, 'Mar'!Total...). Se alguém renomear a aba "Mar" para "Março", sua fórmula quebra.
A fragilidade suprema do Excel é a referência posicional. O Excel não sabe que você quer o "Preço do Cimento"; ele sabe que você quer o valor da célula D5. Se alguém deletar a coluna C, a coluna D vira C, e sua referência aponta para o vazio — ou pior, para o dado errado, gerando erros silenciosos que custam milhões.
Para o Engenheiro Híbrido, a evolução natural é migrar dados críticos para ambientes controlados:
Existe uma piada triste na engenharia que diz: "Se o arquivo se chama Final, ele certamente será alterado. Se chama Final_Definitivo, vai ter revisão. Se chama Final_AgoraVai_V3_ParaPlotagem, talvez estejamos perto."
O problema fundamental da planilha (e do DWG tradicional) é que ele é um arquivo estático e descentralizado. No momento em que você anexa Cronograma.xlsx em um e-mail e envia para três pessoas, você acabou de criar três "verdades" diferentes. Se o engenheiro da obra altera uma data na cópia dele e o gerente de suprimentos altera um custo na cópia dele, essas duas verdades nunca mais se encontrarão. Criamos silos de informação que não conversam entre si.
A indústria de software resolveu esse problema há quase 20 anos. Imagine se o Facebook ou o Google fossem construídos trocando arquivos de código por e-mail? O sistema cairia em minutos. Eles utilizam Sistemas de Controle de Versão (VCS).
Na engenharia civil, aceitamos passivamente a barbárie de "sobrescrever arquivos". Aceitamos que, para saber o que mudou de uma versão para outra, precisamos abrir dois arquivos lado a lado e brincar de "jogo dos sete erros". Isso é insano, ineficiente e perigoso.
Para se tornar um Engenheiro Híbrido, você precisa entender o conceito de Git. Mesmo que você não escreva uma linha de código hoje, a filosofia do Git salvaria sua obra.
O Git é como uma máquina do tempo com superpoderes. Ele não salva apenas o estado atual do arquivo; ele salva o diferencial (o que mudou) e, mais importante, o contexto (quem mudou e por quê).
Você não vai conseguir usar Git nativamente em um arquivo .rvt ou .dwg binário (ainda), mas pode adotar a postura:
Na engenharia de software, existe um mandamento sagrado chamado Separação de Responsabilidades (Separation of Concerns). Ele diz que a parte do sistema que guarda a informação não deve ser a mesma que calcula, nem a mesma que mostra a informação na tela.
O Excel viola essa regra de forma brutal. Em uma única tela (uma planilha), misturamos três camadas distintas:
=A1*B1).Isso cria o que chamo de "Efeito Dominó da Formatação". Ao tentar deixar a apresentação bonita — por exemplo, inserindo uma linha em branco para separar visualmente dois andares no orçamento — você acidentalmente exclui dados do intervalo de soma da sua lógica. Quantos orçamentos milionários já foram subestimados porque a fórmula SUM(A1:A50) não incluiu as novas linhas adicionadas no final?
Para profissionalizar a engenharia, precisamos adotar a arquitetura que sustenta a internet moderna. Vamos traduzir os conceitos de desenvolvimento web para a realidade da construção civil:
No Software: É onde o dado vive em estado bruto e seguro (SQL, MongoDB).
Na Engenharia Híbrida: É o seu modelo BIM (IFC), ou um banco de dados de insumos no SQL. Aqui, não importa a cor da fonte ou se está bonito. Importa a integridade. "Concreto FCK 30" é um dado imutável, acessível por qualquer um.
No Software: É o código que processa as regras (Python, C#, Java). Ele não tem "cara", ele tem função.
Na Engenharia Híbrida: É o seu script Python que lê o banco de dados e calcula: "Se o volume é X e o traço é Y, preciso de Z sacos de cimento". A vantagem? Se a regra de cálculo mudar (ex: nova norma técnica), você altera uma linha de código no Back-end, e todos os seus projetos são recalculados instantaneamente. No Excel, você teria que caçar a fórmula em 50 abas diferentes.
No Software: É o que o usuário vê (o site, o aplicativo mobile, o Dashboard).
Na Engenharia Híbrida: É o seu painel no Power BI ou o PDF gerado automaticamente. O Front-end é descartável e flexível. Quer mudar o relatório de azul para vermelho? Mude no Front. Isso não toca no dado (Database) nem no cálculo (Back-end). Você tem liberdade estética sem risco técnico.
Quando separamos as coisas, ganhamos um superpoder extra: a capacidade de conectar serviços externos via APIs.
Imagine um "Back-end" de diário de obra que, ao invés de você digitar se choveu ou não, ele consulta automaticamente a API de meteorologia baseada na geolocalização da obra e preenche o banco de dados. No Excel, isso é ficção científica ou uma macro instável. Na engenharia de software, é o básico do dia a dia.
O Engenheiro Híbrido não desenha linhas em planilhas; ele desenha fluxos de dados entre sistemas.
Muitos engenheiros travam na hora de aprender programação porque tentam decorar a sintaxe (onde vai o ponto e vírgula, como declarar uma variável) antes de entender a lógica.
A boa notícia é: engenheiros civis já são programadores naturais. Nós passamos 5 anos na faculdade aprendendo algoritmos. Só que chamamos esses algoritmos de "Normas Técnicas" e os executamos manualmente, com calculadora e lápis.
Pensamento Algorítmico não é saber Python. É a capacidade de quebrar um problema complexo em uma sequência de passos finitos, sem ambiguidade, que levam a uma solução. É traduzir o "bom senso de engenharia" em regras claras de SE... ENTÃO....
Vamos pegar um exemplo clássico de infraestrutura. Você precisa definir a superlevação ($h$) de uma curva ferroviária. O processo manual tradicional é:
Esse processo é lento, sujeito a erro humano (olhar a linha errada) e estático. Se a velocidade mudar de 80km/h para 100km/h, você precisa refazer tudo.
O engenheiro híbrido enxerga a norma não como uma tabela, mas como uma função matemática. Ele traduz o texto da norma para um algoritmo:
Ao escrever isso uma única vez, você criou uma ferramenta que verifica 1.000 curvas em segundos. Se a norma mudar (o limite subir para 180mm), você altera um número no código e reprocessa o projeto inteiro.
O maior desafio na programação é lidar com o famoso "depende" da engenharia. "Qual talude eu uso?" "Depende do solo."
O pensamento algorítmico exige que você explicite esse "depende". Você não pode mais confiar na intuição. Você precisa criar regras:
SE (N_SPT < 10) ENTÃO (Talude = 1:2)
SENÃO SE (N_SPT >= 10) ENTÃO (Talude = 1:1.5)
Quando você documenta essas regras em código, seu projeto ganha rastreabilidade. Você pode provar matematicamente por que aquela decisão foi tomada em cada quilômetro da rodovia, sem depender da memória do projetista que saiu da empresa mês passado.
Durante décadas, o mercado de construção civil foi dividido em dois grupos estanques: quem "sujava a bota" na obra e quem ficava no ar-condicionado projetando. Recentemente, surgiu um terceiro grupo: o pessoal de T.I., que tenta implementar softwares na construtora, mas muitas vezes não sabe a diferença entre um pilar e uma viga.
O resultado dessa desconexão é visível: softwares caríssimos que ninguém usa, tablets que ficam gaveta do mestre de obras e processos digitais que são mais burocráticos que o papel.
É aqui que nasce o Engenheiro Híbrido.
O Engenheiro Híbrido não é um "programador que sabe construir", nem um "engenheiro que brinca de Python". Ele é um bilingue. Ele fala fluentemente a língua da Engenharia (tensões, cronogramas, normas, FCK) e a língua da Tecnologia (APIs, loops, bancos de dados, git).
O maior valor desse profissional é resolver o gap de comunicação que custa bilhões ao setor:
O Engenheiro Híbrido olha para o problema e diz: "Não precisamos de 50 campos. Precisamos de um botão de geolocalização que puxe a previsão do tempo via API e um campo de voz-para-texto para o relato do mestre." Ele desenha a solução com a visão de quem conhece a dor da obra e a possibilidade do código.
Para se tornar esse profissional, você não precisa de um diploma em Ciência da Computação. Sua base (a perna vertical do "T") continua sendo a Engenharia Civil. A tecnologia é a barra horizontal que amplifica seu alcance.
"A tecnologia não substitui o engenheiro. O engenheiro que domina a tecnologia substitui o engenheiro que não a domina."
No Capítulo 2, vamos mergulhar na Engenharia de Software aplicada. Vou mostrar o que aprendi na minha segunda pós-graduação e como conceitos como "Clean Code" e "Versionamento" podem salvar seus projetos de infraestrutura do caos.
Fim do Capítulo 1