A engenharia de projetos e a cultura de “operar softwares”

O contexto da engenharia de projetos no Brasil experimentou uma mudança radical na percepção dos profissionais sobre o uso de softwares, sobretudo a partir da década de 2000. O principal motivo foi a popularização e a humanização das interfaces desses aplicativos.

Como exemplo, pode-se citar o caso das estruturas de concreto. Antes do surgimento e popularização dos computadores, o dimensionamento de estruturas de concreto tinha como ferramenta de apoio ao engenheiro apenas a régua de cálculo. Isso limitava a análise de vigas e pórticos ao método de Cross. O surgimento de calculadoras que permitiam superar as limitações das quatro operações básicas, a partir da década de 1960, e de softwares baseados em análises matriciais nas décadas seguintes representou um salto significativo na profissão. Esses softwares de cálculo reproduziam, de maneira automática, os modelos simples de análise das estruturas, exigindo do profissional conhecimento sobre análise de comportamento estrutural. Além disso, a transformação de um modelo real em um modelo analítico compreendido pelo programa exigia noções de configuração de rigidez de nós e barras, para que a correlação entre os modelos representasse o comportamento real da estrutura.

Atualmente, todas as etapas de um projeto estrutural, desde a concepção até a emissão de plantas, são automatizadas pelo computador. O lançamento da estrutura no software tornou-se intuitivo: vigas são lançadas como vigas, pilares como pilares e lajes são discretizadas conforme o resultado desejado. Todas as principais análises são fornecidas ao clique de um botão: esforços internos, reações nas fundações, deslocamentos, vibrações, resistência ao fogo, entre outras. Com isso, o tempo que o engenheiro investia na configuração do modelo e na análise de resultados foi consideravelmente reduzido, assim como a necessidade de desenhistas técnicos para a montagem das pranchas.

Além de se tornarem mais intuitivos e humanizados, os softwares ficaram mais acessíveis técnica e financeiramente. Nos dias de hoje, computadores domésticos com configurações mínimas são capazes de processar os programas, e a opção de assinatura oferecida por grande parte das empresas desenvolvedoras permite que muito mais profissionais tenham acesso a esse mercado, algo impensável anos atrás. Isso, à primeira vista, parece ser uma evolução positiva: profissionais que perdem menos tempo com um projeto têm mais tempo para evoluir em outros, aumentando a produtividade e os ganhos financeiros. O objetivo do avanço tecnológico é justamente diminuir o trabalho mecânico do ser humano para que este privilegie o trabalho intelectual. No caso dos engenheiros de projetos, o trabalho intelectual representa pensar na melhor solução para a edificação, tanto técnica quanto economicamente. Essa afirmação aplica-se não apenas à engenharia de estruturas, mas a qualquer área que envolva projetos.

Por outro lado, a popularização dos softwares fez com que muitos profissionais sem a devida experiência ou capacitação se tornassem simples operadores de softwares. Não é incomum observar, no mercado, engenheiros que vendem “pacotões” de projetos pela internet, com preços consideravelmente abaixo daqueles praticados por profissionais com anos de experiência. Por experiência própria, recebi clientes que compraram esses projetos e tiveram problemas na execução de suas obras. O produto entregue nesses casos são pranchas geradas automaticamente pelos softwares, que muitas vezes sequer passam por um tratamento de textos sobrepostos. Se não há cuidado nem com a qualidade do desenho – que é o principal contato do profissional com o cliente – muito provavelmente não houve cuidado com a análise do modelo calculado pelo software.

Sempre faço questão de frisar com meus alunos de Análise Estrutural que, quando o modelo analítico – que é inserido como dado de entrada no software – não corresponde ao mecanismo que é executado, muitas vezes torna-se um problema para a edificação construída. A correta representação do analítico pelo real passa pelo detalhamento adequado dos elementos projetados. Por exemplo, se em um projeto estrutural o engenheiro determina que o vínculo de um pilar com o solo seja engastado, o elemento de fundação deve ser detalhado de forma que possa transferir ao solo os momentos e reações de acordo com o modelo. Já houve situação real em que uma empresa venceu uma licitação para fornecer projetos para construção de pontos de ônibus. O profissional responsável pelo projeto estrutural considerou que o pilar das estruturas estava engastado (os pontos de ônibus, no caso, tinham apenas um pilar para sustentação da cobertura) e detalhou sapatas de 100 x 100 centímetros, “esquecendo-se” dos momentos atuantes na base. Os projetos executivos passaram pela fiscalização do órgão público até chegarem à empresa que venceu a licitação para execução. A empresa só se deu conta do problema ao instalar a cobertura e perceber que o pilar começava a tombar, pois a fundação não tinha capacidade de restrição ao giro. Ao ser questionado, o engenheiro responsável pelo projeto respondeu que verificou a carga vertical do pilar contra a carga limite do solo, a partir das tensões na base da sapata, e, como o esforço resistente foi maior que o solicitante, julgou que estava tudo certo. Além disso, descobriu-se que a empresa, “especialista em licitações”, fazia todos os tipos de projetos, desde arquitetônicos até de climatização, sendo esse o único engenheiro do quadro técnico. Ele fazia exatamente aquilo que descrevemos: entregava aquilo que saía do software.

O caso acima é apenas um exemplo entre muitas outras situações que podem ser encontradas no cotidiano e que só são descobertas (quando são descobertas) na etapa de execução. A fase de projeto, que deveria ser composta por etapas como estudo, análise, concepção e detalhamento, acaba sendo negligenciada por conta das pressões de clientes e órgãos públicos por prazos e custos. Esses atores precisam ter consciência de que projetos mal feitos, contratados pelo menor preço e menor prazo, podem gerar economia no curto prazo, mas as falhas decorrentes dessas contratações causarão prejuízos muito maiores no futuro. Já o profissional que hoje se tornou um simples operador de software precisa ter consciência de que é o responsável legal pelo projeto que está entregando e pelas consequências dele.