Ciclo de Vida nos Projetos AEC: equívocos comuns

Esses dias estive ocupado com tarefas que envolviam o ciclo de vida de empreendimentos de engenharia. Coisas do dia a dia de quem vive disso, ou seja, nada anormal.


Fiz algumas pesquisas na internet por algumas palavras-chave, li alguns documentos on line e, claro, os mecanismos de busca começaram a me presentear com diversas notificações de notícias e artigos (de blogs) relacionados ao tema. Viva a tecnologia! Até aí tudo bem!


Os problemas começaram quando comecei a dar atenção a algumas destas notificações e me deparei com uma enxurrada de equívocos conceituais em textos que pareciam ser de especialistas. É claro que eu não acreditei que fossem mesmo.



O que mais me preocupou é que imaginei que muitos estudantes ou profissionais estejam lendo essas coisas e achando que estão aprendendo ou se qualificando, pois parecem ser textos eloquentes, daqueles escritos pra tentar convencer.


É, de fato, impressionante a quantidade de “conteúdos equivocados” que podemos encontrar na internet. Uma tragicomédia da superficialidade da sociedade líquida! Na virada do século deram até nome para uma das causas disso: Efeito Dunning Kruger (quem sabe um dia escrevamos sobre ele).


Há, certamente, algumas questões que naturalmente decorrem do amadurecimento de uma área de conhecimento. Conceitos que vão se ajustando melhor à medida que as teorias vão se enriquecendo. Assim é, por exemplo, com os conceitos de fase e etapa. Aparentemente sinônimos, essencialmente são coisas diferentes em um bom nível de rigor. Há um texto meu sobre isso na coletânea que publiquei no final de 2020 (disponível em www.reneruggeri.com) e um artigo publicado em 2010 intitulado “Definindo o Ciclo de Vida dos Projetos: utilizando e diferenciando fases e etapas” (2010 em www.administradores.com.br e republicado em 2018 no www.pmkb.com.br). Indiretamente devo ter falado disso mais de uma centena de vezes nessa última década.


Um outro exemplo de evolução que tenho percebido ainda não ter caído na graça do público e de alguns especialistas é o fato de pensar a compatibilização de projetos não como etapa do processo de desenvolvimento do projeto. Há muitos textos recentes na internet que ainda falam da compatibilização como uma etapa. Felizmente, aos poucos têm surgido as referências a ela como uma atividade contínua de coordenação (ainda teremos a evolução de tratá-la como atividade contínua de projeto, não especificamente de coordenação). O BIM tem contribuído bem para essa recuperação conceitual. Compatibilização nunca deveria ser uma etapa do processo do projeto, embora fosse executada como tal. Isso é uma falha crônica nos processos de projeto adotados no mercado, que agora tem recebido atenção. Vamos dar o desconto de que realmente sem um bom apoio tecnológico a compatibilização tende a ser bem difícil (eu que o diga, fiz isso minha vida toda), mas não é impossível. A tecnologia facilitou muito a compatibilização, mas tratá-la como uma atividade contínua não é uma evolução do processo, é uma correção de um processo que estava (e ainda está, para boa parte do mercado) equivocado.


A virada do século marcou a explosão do Gerenciamento de Projetos (GP) como carreira e área de especialização para o negócios no Brasil. Pipocaram MBAs e cursos livres em todo o mercado. Ainda hoje é um tema “da moda”. E com razão, o GP é, sem dúvida, um dos conteúdos mais importantes para a formação de uma série de profissionais com forte tendência a ocupar cargos de liderança nas organizações.


Mas o termo “projeto”, na língua portuguesa, é traiçoeiro, sobretudo nas áreas de engenharia e arquitetura. Ao mesmo tempo que significa um processo, pode significar também um produto. E ambas as interpretações estão corretas (esse é outro ponto que já tratei uma centena de vezes nas últimas décadas e sobre o qual já publiquei textos). Mas, ainda nos deparamos com textos na internet que confundem o “projeto”, à moda do GP, denotando um processo e o “projeto”, típico no ramo de arquitetura e engenharia, denotando um produto. É sutil a diferença, mas leva a perigos estruturais.


Por exemplo, no aspecto do GP, muito vinculado à gestão empresarial ou de negócios, é dada importância a certos pontos do projeto (processo) que, pelo olhar do projeto de engenharia e arquitetura (produto) não seriam os fundamentais. A generalidade do GP permite aplicar este conhecimento ao processo de desenvolvimento do projeto de arquitetura e engenharia. E aí está o risco: o termo usado com significados diferentes no mesmo contexto com um público que não é, na prática, especialista em um ou em ambos os temas. Resultado: tenta-se estruturar o processo de produção de um produto dando ênfase a aspectos típicos da gestão do processo do negócio. Convive-se permanentemente com uma falha de processo produtivo em nome de entregas que fazem sentido no processo do negócio. Ainda que guardem alguma correlação importante, não são rigorosamente a mesma coisa. E o pior, julga-se como incompetente o fornecedor que não consegue produzir bem cumprindo, por exigência contratual, o processo equivocadamente estruturado pelo contratante. Pasmem, isso está embutido em normas internas de várias instituições. Para ser mais preciso, o problema aqui não é atender as entregas do processo do negócio (que são legítimas obviamente), mas falhar com as entregas do processo produtivo (que são necessárias).


Nem vale a pena discorrer sobre diversos outros equívocos em relação ao ciclo de vida dos projetos de arquitetura e engenharia, ainda comuns de se ver nos materiais “instrutivos” por aí:


  • Confundir estudo preliminar com anteprojeto.

  • Confundir anteprojeto com projeto básico.

  • Confundir projeto básico com projeto legal.

  • Achar que projeto completo é sinônimo de projeto executivo (como se não fizesse sentido um estudo preliminar completo).

  • Não se considerar os objetivos das etapas como definidores delas (como se fossem etapas definidas apenas burocraticamente, sem função objetiva no processo de desenvolvimento de soluções técnicas).

  • Admitir uma tarefa ou atividade do processo do projeto como etapa. Por exemplo, considerar visita ao local como etapa. (Acreditem, já vi considerar visita à obra, que obviamente anda não existe, como etapa inicial de projeto. Um erro terminológico ou conceitual?).

  • Considerar a orçamentação da obra como uma etapa de projeto e, o que é pior, uma das últimas. É algo como dizer que o valor da obra será uma surpresa no final.

  • E por aí vai, a lista pode crescer...


É claro que há inúmeras possibilidades de estruturação do ciclo de vida em função de diversas peculiaridades de nichos de mercado ou de tipos de empreendimentos. Mas nenhuma delas exclui a necessidade do rigor conceitual, sob pena de instruir ou generalizar equivocadamente o processo, lançando estudantes e profissionais numa cilada de equívocos cujas consequências podem variar de um probleminha de entendimento a sérios prejuízos causados por falhas do processo produtivo.


Aqui escrevemos um texto para blog, mas há inúmeros trabalhos acadêmicos e livros que levam a sério essa importante questão. Não se pode lidar com os problemas um a um (construindo uma colcha de retalhos de soluções do tipo puxadinho) em vez de dedicar esforço intelectual para edificar soluções estruturantes (mais que estruturais) para um processo que é de negócio, mas também de produção. Todo processo produtivo precisa também ser bem projetado.

Featured Posts
Recent Posts
Archive
Search By Tags
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square