Category: Indústrias

É nesse ponto que os indicadores de desempenho deixam de ser um recurso administrativo e passam a ser uma ferramenta de engenharia. Um bom indicador deve funcionar como um instrumento de medição: precisa ter uma variável definida, um método de apuração consistente, uma frequência adequada e, acima de tudo, uma consequência gerencial. Se o número varia e ninguém toma nenhuma decisão a partir dele, provavelmente não estamos diante de um indicador. Estamos diante de decoração corporativa.

A questão, portanto, não é medir tudo. Empresas que tentam acompanhar dezenas de métricas acabam produzindo relatórios extensos, reuniões cansativas e pouca capacidade de intervenção. O objetivo deve ser acompanhar um conjunto limitado de indicadores que responda a perguntas concretas: temos capacidade para assumir novos projetos? Estamos convertendo esforço em faturamento? Os projetos estão consumindo mais recursos do que o previsto? Estamos corrigindo erros ou repetindo-os? O crescimento comercial é real ou apenas uma impressão criada pelo volume de propostas?

A seguir, estão alguns dos indicadores que melhor ajudam a responder essas perguntas, acompanhados da frequência com que deveriam ser analisados.

Workload ou carga de trabalho dos times

O workload compara a capacidade produtiva disponível com a demanda efetiva dos projetos. À primeira vista, parece uma conta simples entre horas disponíveis e horas necessárias. Na prática, é um dos indicadores mais importantes para evitar duas situações igualmente ruins: a sobrecarga crônica e a ociosidade mascarada.

A sobrecarga é facilmente percebida quando surgem atrasos, jornadas excessivas e conflitos de prioridade. A ociosidade, por outro lado, costuma ser mais difícil de identificar. Um profissional pode estar com a agenda cheia e, ainda assim, dedicar grande parte do tempo a atividades de baixa relevância, esperas, reuniões improdutivas ou correções que não deveriam existir. Estar ocupado não é o mesmo que utilizar bem a capacidade.

Por isso, o workload deve ser analisado por disciplina, função e projeto, e não apenas de forma consolidada. Uma empresa pode apresentar utilização média aparentemente saudável e, ao mesmo tempo, ter uma equipe operando no limite enquanto outra está subutilizada. A média, nesses casos, funciona como aquela velha história do sujeito com a cabeça no forno e os pés no congelador: estatisticamente, a temperatura média parece aceitável.

A análise deve ser semanal, pois a carga de trabalho se altera com novas contratações, atrasos, revisões de escopo, mobilizações e mudanças de prioridade. Esperar o fechamento do mês significa descobrir o problema quando parte do atraso já foi incorporada ao cronograma.

Funil de vendas

O funil de vendas não deve ser interpretado apenas como um indicador comercial. Para uma empresa de engenharia, ele também é um indicador de capacidade futura. O volume e a qualidade das oportunidades em negociação determinam, com alguma antecedência, a necessidade de mobilização de equipes, contratação de profissionais, aquisição de equipamentos e organização de parceiros.

O erro mais comum é considerar o valor total das propostas abertas como se ele representasse receita provável. Não representa. Um funil de R$ 20 milhões pode valer menos do que um funil de R$ 5 milhões, dependendo da qualidade dos clientes, do estágio das negociações, da taxa histórica de conversão e do prazo esperado para contratação.

O indicador precisa considerar, no mínimo, o valor das oportunidades, a probabilidade de fechamento, o tempo médio em cada etapa e a taxa de conversão. Também é importante avaliar a concentração. Um funil sustentado por dois ou três grandes contratos pode parecer robusto, mas é operacionalmente frágil. Se uma dessas oportunidades for adiada, toda a previsão de receita e utilização da equipe pode desabar junto.

A revisão deve ser mensal, com acompanhamento mais frequente das oportunidades críticas. O objetivo não é apenas cobrar a equipe comercial, mas ajustar antecipadamente a estrutura operacional. Engenharia sem previsibilidade comercial costuma alternar entre dois extremos: falta de trabalho em um mês e excesso de demanda no seguinte.

Horas trabalhadas versus horas faturáveis

Poucos indicadores revelam de forma tão objetiva a eficiência de uma empresa de engenharia quanto a relação entre horas trabalhadas e horas faturáveis. Essa comparação mostra quanto do esforço da equipe foi efetivamente convertido em receita de projeto.

A distinção é importante porque uma empresa pode ter todos os profissionais ocupados e, ainda assim, apresentar baixa rentabilidade. Reuniões internas, retrabalho, espera por informações, correções não previstas, apoio comercial e atividades administrativas consomem tempo real, mas nem sempre são remuneradas pelo cliente. Quando essas horas crescem sem controle, a margem desaparece antes mesmo de o financeiro perceber.

Também não basta estabelecer uma meta genérica, como 85% de horas faturáveis, e aplicá-la igualmente a todos. Funções comerciais, administrativas e de coordenação naturalmente possuem uma proporção menor de horas diretamente faturáveis. O indicador deve ser segmentado por função e comparado com parâmetros realistas para cada atividade.

A análise semanal é recomendável porque desvios de utilização se acumulam rapidamente. Uma redução aparentemente pequena na taxa de horas faturáveis pode representar centenas de horas não convertidas em receita ao final do mês. O problema é silencioso, mas a folha de pagamento não é.

Custo por projeto

O custo por projeto deve comparar o orçamento aprovado com os gastos e horas efetivamente consumidos durante a execução. A lógica é simples: se um projeto foi vendido considerando determinado número de horas, viagens, mobilizações, equipamentos e despesas indiretas, qualquer desvio relevante precisa ser identificado enquanto ainda existe possibilidade de correção.

Projetos raramente se tornam deficitários por causa de um único evento extraordinário. O mais comum é a soma de pequenos desvios: uma visita adicional, uma revisão extra, uma informação que chegou incompleta, uma equipe que permaneceu mobilizada por mais tempo ou uma etapa que precisou ser refeita. Nenhum desses eventos parece grave quando analisado isoladamente. O problema aparece quando todos resolvem acontecer no mesmo contrato.

Acompanhar apenas o faturamento não resolve essa questão. Um projeto pode ter valor elevado e, mesmo assim, gerar pouca contribuição para a empresa. A receita impressiona; o custo explica.

O acompanhamento deve ser mensal, ou até quinzenal em projetos de curta duração ou elevada complexidade. Fazer essa análise apenas no encerramento serve para registrar o prejuízo, não para evitá-lo.

Taxa de retrabalho

O retrabalho é frequentemente tratado como parte inevitável da engenharia. Em alguma medida, é verdade: projetos complexos estão sujeitos a revisões, ajustes e mudanças de premissas. O problema começa quando toda correção é classificada como normal, sem distinção entre alteração legítima de escopo e erro interno.

É necessário separar o retrabalho causado pelo cliente daquele provocado por falhas de levantamento, incompatibilidades, documentação inadequada, comunicação deficiente ou ausência de procedimentos. Sem essa classificação, a empresa mistura revisão contratual com desperdício operacional e perde a capacidade de atacar a causa real.

A taxa de retrabalho pode ser medida pela proporção de horas dedicadas a correções em relação ao total de horas do projeto. Também pode ser analisada pelo número de revisões, pelo custo das correções ou pelo impacto no prazo. O mais importante, porém, é identificar a causa raiz. Medir que houve retrabalho é útil; descobrir por que ele se repete é o que gera melhoria.

A revisão deve ser mensal, acompanhada de análise por disciplina, tipo de erro e etapa do projeto. Caso contrário, a empresa corre o risco de continuar pagando todos os meses pelo mesmo problema com nomes diferentes.

Lead time de projeto

O lead time mede o tempo total entre o início e a conclusão de um projeto ou de uma etapa específica. Ele permite comparar prazo planejado e prazo realizado, mas sua utilidade vai além de registrar atrasos. Quando bem analisado, mostra onde o fluxo está parando.

Uma entrega pode atrasar não porque a equipe trabalhou lentamente, mas porque o projeto permaneceu dias aguardando informação, aprovação, liberação de acesso ou definição de escopo. Esses períodos de espera também fazem parte do lead time e precisam ser registrados. Caso contrário, a análise penaliza apenas quem executa e ignora quem interrompe o fluxo.

O indicador deve ser decomposto por etapa. Saber que um projeto levou 90 dias é menos útil do que saber que 25 dias foram consumidos aguardando dados do cliente, 15 dias em revisão interna e 10 dias em correções. A decomposição transforma um atraso genérico em um problema tratável.

A avaliação deve ser mensal, com acompanhamento contínuo dos marcos contratuais. Em projetos de engenharia, pequenos atrasos raramente permanecem pequenos. Eles tendem a se acumular até que a última etapa receba a missão impossível de recuperar tudo.

Margem de contribuição por projeto

A margem de contribuição mostra quanto cada projeto efetivamente entrega para cobrir os custos fixos e gerar resultado para a empresa. Ela é calculada pela diferença entre a receita do projeto e seus custos variáveis diretos.

Esse indicador é essencial porque o faturamento, sozinho, pode produzir uma visão enganosa. Contratos grandes costumam receber destaque em reuniões e apresentações, mas também podem carregar alto consumo de horas, mobilizações complexas, riscos contratuais e sucessivas revisões. Um projeto menor, bem definido e executado com eficiência pode gerar resultado superior.

A margem deve ser analisada por projeto, cliente, tipo de serviço e equipe. Isso permite identificar padrões. Talvez determinado serviço tenha preço inadequado. Talvez alguns clientes exijam esforço desproporcional. Talvez a equipe estime mal certas etapas. Sem essa análise, a empresa tende a repetir contratos ruins apenas porque eles aumentam o faturamento.

A revisão trimestral é adequada para decisões estratégicas, mas projetos com risco elevado devem ser acompanhados mensalmente. Esperar três meses para descobrir que um contrato importante está consumindo caixa é uma experiência educativa, mas pouco recomendável.

Turnover ou giro de pessoas na empresa

O turnover mede a rotatividade de profissionais, mas seu impacto em empresas de engenharia vai muito além do custo de desligamento e reposição. Quando um profissional experiente deixa a organização, leva consigo conhecimento de projetos, histórico de decisões, relacionamento com clientes e domínio de procedimentos que muitas vezes nunca foram formalmente documentados.

A substituição também não é imediata. Mesmo quando a empresa encontra alguém tecnicamente qualificado, existe um período de adaptação até que o novo profissional compreenda padrões internos, clientes, ferramentas e particularidades dos projetos. Esse tempo precisa ser considerado como perda de capacidade produtiva.

O indicador deve ser analisado por área, tempo de empresa, nível de experiência e motivo de desligamento. Uma taxa geral pode parecer aceitável, mas esconder a saída recorrente de profissionais em uma função crítica.

A avaliação trimestral costuma ser suficiente, desde que cada desligamento relevante seja analisado individualmente. Turnover elevado quase nunca é apenas um problema de salário. Pode indicar falhas de liderança, falta de perspectiva, carga excessiva, processos ruins ou ausência de reconhecimento.

Satisfação do cliente

A satisfação do cliente é frequentemente medida de forma superficial, com uma pergunta genérica ao final do contrato. O problema é que uma nota isolada explica pouco. Um cliente pode avaliar bem uma entrega e, ainda assim, não voltar a contratar. Outro pode apresentar reclamações durante o projeto e permanecer como parceiro por anos.

Por isso, a avaliação deve considerar fatores específicos: cumprimento de prazo, qualidade técnica, comunicação, capacidade de resposta, clareza documental e facilidade de relacionamento. Também é útil acompanhar indicadores comportamentais, como recorrência de contratação, número de indicações, tempo de resposta a novas propostas e volume de serviços adicionais.

A análise trimestral permite identificar tendências, mas o feedback deve ser coletado logo após entregas relevantes. Esperar meses para perguntar ao cliente o que ele achou é confiar excessivamente na memória e na boa vontade.

Retorno sobre o investimento

O retorno sobre o investimento, ou ROI, compara o benefício econômico gerado por uma decisão com o valor necessário para implementá-la. Em engenharia, pode ser aplicado à aquisição de equipamentos, implantação de softwares, contratação de equipes, treinamentos, automações e melhorias de processo.

O cálculo precisa considerar não apenas o ganho direto de receita, mas também a redução de custos, o aumento de capacidade, a diminuição de retrabalho e a redução de riscos. Um novo equipamento pode não gerar faturamento isoladamente, mas pode reduzir dias de campo, permitir mais projetos simultâneos e diminuir erros. Esses benefícios precisam ser quantificados.

Também é importante estabelecer um período de análise. Um investimento pode apresentar retorno negativo nos primeiros meses e tornar-se altamente vantajoso ao longo de dois anos. Sem horizonte definido, a discussão sobre ROI vira opinião.

A revisão trimestral é adequada para acompanhar o desempenho acumulado e comparar os resultados com as premissas usadas na aprovação do investimento.

Afinal, quantos indicadores um gestor precisa acompanhar?

Provavelmente menos do que imagina.

O objetivo de um sistema de indicadores não é produzir a sensação de controle. É antecipar desvios e apoiar decisões. Se o gestor acompanha vinte métricas, mas nenhuma altera prioridades, alocação de recursos, preços, processos ou investimentos, então a empresa não possui gestão por indicadores. Possui apenas relatórios.

Um conjunto eficiente deve equilibrar quatro dimensões: capacidade, eficiência, rentabilidade e qualidade. Workload e lead time mostram como a operação está fluindo. Horas faturáveis, custos e margem revelam se o esforço gera resultado econômico. Retrabalho e satisfação do cliente indicam a qualidade da entrega. Funil de vendas e turnover ajudam a antecipar a demanda e a capacidade futura.

Os números, no entanto, não tomam decisões. Eles apenas retiram parte das desculpas.

Quando um indicador está ruim, sempre existe uma explicação: o cliente atrasou, o escopo mudou, a equipe estava sobrecarregada, o mercado esfriou ou o projeto era mais complexo do que parecia. Algumas dessas justificativas são legítimas. Outras são apenas maneiras sofisticadas de dizer que a empresa não percebeu o problema a tempo.

No fim, a função de um bom indicador é exatamente essa: permitir que o gestor enxergue cedo o que, mais tarde, todos dirão que era óbvio.

Ela entra na reunião com cara de pragmatismo. Parece experiência. Parece maturidade. Parece aquele tipo de flexibilidade que todo mundo elogia antes de descobrir que era só bagunça com crachá.

No retrofit, essa frase deveria acender uma sirene.

A captura da realidade em retrofit precisa virar item padrão nas propostas. Não como mimo tecnológico. Não como perfumaria de inovação. Não como aquele “plus” que é cortado quando o orçamento fica apertado. Ela precisa ser tratada como parte normal do escopo.

Porque retrofit não é obra em folha branca. É intervenção em algo que já existe. E o que existe quase sempre foi alterado, adaptado, remendado, esquecido ou “resolvido em campo” por alguém muito antes de você chegar.

Eu mesmo já caí nessa armadilha. Já achei que planta antiga resolvia. Já confiei em arquivo chamado “asbuilt_final_revisado_agora_sim.dwg”. Foi bonito. Bonito como ver um piano despencando em câmera lenta.

A verdade é simples. Sem capturar a realidade, o projeto começa devendo informação.

O que é captura da realidade em retrofit?

Captura da realidade é o processo de registrar digitalmente as condições reais de um ambiente existente. Isso pode ser feito com laser scanner 3D, drones, fotogrametria, topografia digital e outras tecnologias de levantamento.

O resultado mais conhecido é a nuvem de pontos. Ela representa, em três dimensões, superfícies, estruturas, equipamentos, tubulações, fachadas, passarelas, interferências e tudo aquilo que costuma transformar um retrofit em um pequeno thriller corporativo.

A GENIA descreve a nuvem de pontos como uma coleção de pontos tridimensionais obtidos por escaneamento a laser ou fotogrametria. Esses pontos representam a superfície de objetos e estruturas, criando uma base digital detalhada para projetos BIM e as built.

Em termos simples, a captura mostra o que existe. Não o que deveria existir. Não o que foi prometido no projeto original. Não o que alguém lembra “mais ou menos”. Ela mostra o mundo físico, com suas virtudes, cicatrizes e pequenas atrocidades técnicas.

E é exatamente por isso que ela deve estar na proposta.

Por que retrofit sem captura é aposta fantasiada de engenharia?

Retrofit é cirurgia em paciente acordado. A edificação, a fábrica ou a instalação continuam carregando décadas de decisões. Algumas boas. Outras, nem tanto.

Há tubulações desviadas. Há shafts congestionados. Há equipamentos trocados. Há suportes improvisados. Há interferências que só aparecem quando o forro é aberto e todo mundo descobre que a realidade tem senso de humor.

Quando a captura da realidade em retrofit não é feita no início, o projeto passa a depender demais de documentos antigos. E documentos antigos podem ajudar, claro. Mas tratá-los como verdade absoluta é um gesto de fé. Bonito na religião. Ruim na engenharia.

A GENIA já aponta que dados de laser scanner e drones integrados a RTK ou PPK podem ser conectados ao fluxo BIM. Também observa que pode haver pré-processamento, o que é uma etapa essencial para lidar com dados refinados e organizados.

Essa parte é importante. Capturar não é só “escanear e jogar no Revit”. Existe método. Existe tratamento. Existe registro. Existe intenção de uso.

Sem isso, a tecnologia vira showzinho de feira. Com isso, ela vira base de decisão.

O erro nasce antes da obra: nasce na proposta

O retrofit começa errado quando a proposta trata a captura como opcional.

Esse é o ponto mais incômodo. O problema não nasce quando a obra encontra a interferência. Ele nasce antes, quando a proposta finge que a condição existente já é conhecida.

A proposta deveria declarar, com todas as letras, que a realidade será capturada antes do desenvolvimento técnico. Também deveria explicar o objetivo dessa etapa. Pode ser para modelagem BIM. Pode ser para as built. Pode ser para compatibilização. Pode ser para análise de interferências. Pode ser para planejamento executivo.

O que não dá é para vender retrofit como se o ambiente fosse obediente.

A GENIA informa que, em sua modelagem BIM industrial sobre nuvem de pontos, são usados laser scanners e drones para capturar dados precisos do ambiente físico. Esses dados são processados por softwares avançados para criar modelos BIM detalhados.

Essa abordagem muda o jogo comercial. A proposta deixa de vender apenas “horas técnicas”. Ela passa a vender redução de incerteza.

E redução de incerteza é uma moeda nobre. Especialmente quando parada de produção, retrabalho e atraso estão na mesa.

A captura da realidade vende menos surpresa

O cliente não compra nuvem de pontos. Ele compra menos susto.

Essa frase deveria ser colocada em cima da tela de todo vendedor técnico. Porque o erro clássico é tentar vender tecnologia pelo brilho da tecnologia.

Mostra-se o scanner. Mostra-se a nuvem colorida. Mostra-se o modelo girando. Todo mundo acha bonito por três minutos. Depois alguém pergunta o preço.

A venda correta começa pela dor.

Com captura da realidade, a equipe consegue identificar interferências antes da execução. O projeto é desenvolvido sobre uma base mais confiável. A compatibilização ganha evidência. O planejamento deixa de depender de esperança. E a obra recebe menos bombas-relógio.

Segundo a GENIA, a nuvem de pontos permite capturar milhões de pontos em segundos, documentar dimensões da estrutura existente, reduzir tempo de levantamento e apoiar modelos digitais de as built para renovação, manutenção e retrofit.

Portanto, o argumento não deve ser “vamos usar escaneamento 3D”. O argumento deve ser outro: “vamos reduzir o risco de projetar sobre informação desatualizada”.

Isso vende melhor. E, de quebra, é mais honesto.

O as built BIM deveria ser memória técnica, não necropsia

Muitas empresas só lembram do as built quando a obra acabou. Aí começa aquela operação arqueológica. Alguém junta desenhos, fotos, e-mails, mensagens, PDFs e memórias emocionais da equipe.

É quase uma necropsia documental.

O problema é que o as built deveria ser memória técnica organizada. No retrofit, ele precisa nascer cedo. A captura da realidade permite registrar a condição existente antes da intervenção. Depois, essa base pode alimentar um modelo BIM, apoiar decisões e facilitar futuras manutenções.

A literatura técnica reforça essa lógica. Uma revisão sobre reality capture com laser scanners discute aquisição, processamento de nuvens de pontos e integração com BIM no ambiente construído. O estudo também aponta que o uso desses dados deve ser planejado conforme a aplicação desejada.

Ou seja, a nuvem de pontos não é um arquivo bonito para impressionar diretoria. Ela é uma base técnica. E bases técnicas existem para evitar que a próxima decisão seja tomada no escuro.

Scan-to-BIM: quando a realidade vira modelo útil

O fluxo Scan-to-BIM transforma dados capturados em campo em modelos BIM. Em retrofit, isso é especialmente valioso. Afinal, o projeto precisa conversar com aquilo que já existe.

Primeiro, o ambiente é capturado. Depois, a nuvem de pontos é processada. Em seguida, a modelagem é feita com base nessa referência. Por fim, o modelo passa a servir como base para compatibilização, documentação, planejamento e manutenção.

Parece óbvio. Mas o óbvio, na engenharia, às vezes precisa ser cobrado em proposta para ser respeitado.

Estudos recentes sobre integração de laser scanning e BIM mostram que essa combinação pode melhorar a precisão da coleta de dados, a documentação as built e os resultados de projetos em ambientes que não nasceram BIM. Também são citados desafios ligados à acurácia, obstruções de campo e qualidade do modelo.

Essa ressalva é saudável. Captura da realidade não é milagre. É método. E método exige escopo, critério e responsabilidade técnica.

Como escrever essa linha na proposta de retrofit?

A captura não deve aparecer escondida no rodapé. Ela precisa ser descrita como etapa do escopo.

Uma redação possível seria: “Será realizada captura digital das condições existentes por meio de escaneamento 3D, drone, fotogrametria ou método equivalente, conforme necessidade do ambiente. Os dados serão processados em nuvem de pontos registrada e poderão apoiar modelagem BIM, documentação as built, compatibilização e análise de interferências.”

Esse tipo de frase faz duas coisas. Primeiro, educa o cliente. Segundo, protege a equipe.

Também é recomendável separar a entrega técnica. A proposta deve dizer se será entregue apenas a nuvem de pontos, um modelo BIM, um relatório de interferências, uma base cadastral ou uma combinação desses itens.

Assim, ninguém compra uma coisa achando que comprou outra. Parece básico. Mas, em proposta técnica, o básico é uma espécie de luxo.

A objeção do preço: o barato que cobra juros

Sempre haverá alguém dizendo que a captura encarece a proposta.

Em parte, sim. Ela adiciona uma etapa. Ela exige equipamento, equipe, processamento e controle de qualidade.

Mas a pergunta correta não é se custa. A pergunta correta é quanto custa não fazer.

Quanto custa descobrir uma interferência na montagem? Quanto custa parar equipe? Quanto custa refazer rota? Quanto custa alterar projeto durante execução? Quanto custa explicar ao cliente que a planta usada estava errada?

A economia de não capturar costuma ser sedutora no orçamento. Depois, aparece com juros compostos na obra.

E aqui vai minha pequena confissão autodestrutiva: eu já achei que “resolver depois” era agilidade. Hoje, vejo que era só ansiedade usando camisa social.

Agilidade não é pular etapa. Agilidade é remover incerteza cedo.

O cronograma de engenharia, que deveria organizar o saber técnico, virou um instrumento de tortura: corta etapas, ignora maturações, atropela boas práticas. Projetar virou sequência de entregas forçadas. A pressa institucionalizada foi normalizada como competência. Mas não é. É sabotagem. O pior é que ela vem disfarçada de produtividade. É o tipo de ilusão corporativa que enche dashboards e afunda obras. 

A engenharia sempre foi uma disciplina de causa e efeito, onde cada decisão técnica exige contexto, experiência e, acima de tudo, tempo. Mas os cronogramas atuais parecem ter sido escritos por gente que nunca viu uma revisão de flexibilidade ou um clash detectado de madrugada, quando o prazo já expirou e ninguém quer mais saber de retrabalho. O resultado disso é um ciclo de mediocridade técnica cronicamente alimentado por pressa. 

O que antes exigia critério virou um desfile de entregas apressadas. E não estamos falando de detalhe estético, mas de integridade de projeto. Hoje se modela para parecer finalizado, não para ser construído. Se emite desenho para cumprir data, não para garantir execução segura. A engenharia foi cooptada por uma lógica onde o planejamento importa mais que o projeto. Onde o PowerPoint é mais poderoso que o AutoCAD. Onde o cronograma manda, e a qualidade obedece. 

Essa inversão de prioridades cria uma cultura onde a verificação é ritual burocrático. O review técnico virou checklist automatizado. O cálculo virou obrigação apressada. O conhecimento acumulado foi atropelado pela cultura do “vamos entregar isso logo”. E a figura do engenheiro sênior, que antes era referência técnica, virou obstáculo para quem quer apenas fechar mais um pacote no prazo. 

A médio prazo, essa lógica se revela devastadora. Não só porque compromete a qualidade dos projetos, mas porque mina a formação de novos profissionais. Os jovens engenheiros aprendem que o mais importante não é entender o porquê das decisões, mas apenas garantir que o PDF esteja assinado antes da próxima reunião. E assim seguimos empilhando erros bem formatados, enquanto a base técnica da engenharia se esfarela. 

O retrabalho virou parte da conta. O erro virou etapa do processo. A falha estrutural virou aprendizado. Tudo isso soa bonito quando dito em apresentações motivacionais, mas na prática, são só sintomas de um sistema doente, que trocou engenharia por logística de arquivos. 

Se quisermos reverter esse quadro, precisamos de coragem para enfrentar a idolatria do cronograma. Ele deve existir, sim — mas a serviço da engenharia, e não o contrário. Projetar exige tempo. Revisar exige pausa. Calcular exige silêncio. E emitir exige convicção. Nada disso cabe em planilhas feitas para agradar a diretoria. 

O cronograma de engenharia não pode continuar sendo uma sentença. Ele precisa voltar a ser um aliado. Isso exige uma reeducação gerencial profunda, uma revalorização do saber técnico e uma reconstrução da cultura de projeto. Senão, vamos continuar vendendo agilidade enquanto entregamos riscos mal disfarçados. 

E aí, quando a obra desabar, ninguém vai culpar o cronograma. Vão culpar a engenharia. E essa, meus caros, já vem sendo destruída há tempos — uma linha de entrega por vez.