Escopo de serviços inclui o processo e não meramente o produto

Primeiro pensei em escrever um desabafo profissional. Depois pensei em escrever uma crítica. Mas, enfim, decidi escrever sobre os desafios de uma boa definição de escopo. Afinal, do que adiantaria expor os problemas do nosso mercado (empresas e profissionais) sem apontar ao menos um caminho para soluções?

Pretendo expor questões que julgo importantes sobre a definição de escopos na contratação de serviços, usando como exemplo a “elaboração (ou desenvolvimento) de projetos de arquitetura e engenharia” e que cada um, profissional ou empresa, avalie sua atuação a esse respeito. De cara já adianto que a chance de você estar fazendo errado, no mercado de projetos de arquitetura e engenharia, é muito grande, pois nos meus mais de vinte anos nesse nicho de mercado, encontrei pouquíssima gente que levasse isso a sério na ação, porque no discurso todos dizem levar.

A distinção do uso do termo projeto como processo e como produto é fundamentalmente crítica. Já escrevi mais de uma vez sobre essa distinção (veja a “Coletânea de Textos 2010 – 2015” disponível como e-book em nosso site). No mercado de arquitetura e engenharia é comum usar o termo para designar aquele tradicional conjunto de documentos (desenhos, memoriais etc.), mas também o usamos à moda do gerenciamento de projetos, onde significa um processo de criação de algo exclusivo (podendo ser até a própria obra). Se você tem consciência dessa distinção, ótimo. Se não tem, aumentam as chances de você estar fazendo errado, como mencionei há pouco.

O projeto (produto) de arquitetura e engenharia, ou seja, aquele conjunto de documentos, é sem dúvida exclusivo. Logo, para cria-lo é preciso um processo específico, ou seja, um projeto (processo). Como já citei noutras oportunidades, em inglês a distinção é mais objetiva, pois temos, por exemplo, os distintos termos project, design e plan, todos traduzidos como projeto conforme o contexto.

Feito o alerta, vamos em frente. Queremos discutir sobre como deve ser definido o escopo do projeto (processo) cuja entrega é o projeto (produto) de arquitetura e engenharia de um empreendimento. Como definir o escopo do processo que entrega o produto? Chamarei o produto de Projeto AEC, para simplificar (AEC é a sigla para arquitetura, engenharia e construção).

Se preferir pensar noutro serviço de consultoria no lugar do desenvolvimento do Projeto AEC, fique à vontade. Certamente as ideias aqui apresentadas continuarão válidas e talvez você fique livre da confusão terminológica que o termo projeto traz no mercado da construção.

Outro alerta importante deve ser feito: quando você contrata um Projeto AEC, está contratando na realidade um processo e não um produto. Isso é extremamente importante de ser compreendido. Se você, ao contratar, não estabelece requisitos para este processo, é como se estivesse afirmando que não importa o processo de criação do Projeto AEC, apenas o resultado. É isso que a maioria absoluta das empresas e profissionais do mercado fazem: compram um processo como se fosse um produto.

Os mais criteriosos definem o conjunto de documentos que deve ser entregue (planta disso, planta daquilo, cortes, elevações, diagramas, planilhas etc.). Alguns definem até o padrão de apresentação como configurações de linhas, símbolos, tipos de fontes, formatos de arquivos eletrônicos etc. Mas são raros os que estabelecem como devem ser realizados os estudos, como devem ser compartilhadas e integradas as informações, diretrizes para uso de softwares, a integração com outros processos, a abrangência a ser contemplada etc. Ou seja, a maioria do mercado se limita a caracterizar o produto, mas não define nenhum requisito que vise garantir a qualidade do processo. Crer na qualidade do resultado sem influenciar a qualidade do processo que o produz é, no mínimo, ingenuidade.

Dito isto, espero que esteja claro que a definição do escopo do serviço de “desenvolvimento (ou elaboração) de projetos de arquitetura e engenharia” é uma definição que incluir o escopo de um processo. A caracterização do produto resultante desse processo serve como requisitos de um sistema de controle de produção e qualidade do produto, pensando em inspeções pós produção, mas está longe de ser suficiente para dar confiabilidade ao processo, pensando em prevenção de falhas ou garantias da qualidade.

Já houve quem argumentasse que a separação do processo em etapas, como é feito no mercado quando se definem entregas para estudos preliminares, anteprojeto e projeto executivo, tem esse objetivo de garantir qualidade. Quando escuto isso, penso que falta conhecimento do próprio processo produtivo do Projeto AEC, além de conhecimento em gestão de projetos ou da qualidade. A separação em etapas não tem essa finalidade, mas isso é outra discussão; não a farei neste texto. As etapas do desenvolvimento do Projeto AEC não existem para definir pontos de inspeção, embora sejam usadas para isso.

Costumo dizer que descobrir erros depois do resultado entregue é tarde demais. Seria mais inteligente trabalhar para evitar que os erros acontecessem. Isso significa que se deve intervir no processo de produção e não no produto. Mas isso não é novidade para quem conhece sistemas de qualidade.

Não adianta, por exemplo, definir que as soluções multidisciplinares devem ser integradas ou compatibilizadas, se não for definido um procedimento para garantir essa integração. A falta de um bom procedimento ficará explícita quando o resultado não estiver adequado. Sabe-se há décadas, analisando os custos da qualidade, que os custos de correção são quase sempre superiores aos custos de prevenção. Aparentemente esse nicho de mercado ainda não sabe como prevenir os erros no Projeto AEC. Parece ter consciência ainda menor do impacto desse investimento no custo final de um empreendimento. Se sabe, precisamos entender por que ainda contrata serviços de formas inadequadas.

Por fim, para não esticar o assunto, ainda que ele mereça ser mais explorado, é preciso esclarecer sobre outro argumento muito utilizado no debate sobre o tema. Muitos contratantes argumentam que o processo é um problema do fornecedor e ao contratante interessa apenas o resultado, por isso a definição do escopo se concentra nele.

Bons processos, ou seja, processos com garantias de qualidade, têm maiores custos, mas maus processos também entregam resultados. Claro, resultados diferentes. Assim, se o contratante tem interesse no resultado, deveria exigir explicações sobre o processo produtivo de cada fornecedor. Se não fizer isso, receberá sempre um resultado e nunca poderá dizer se é o melhor ou mais adequado à sua necessidade. Vale lembrar que a maioria dos requisitos do produto é atendida por uma infinidade de soluções, com qualidades diferentes. Resolver um problema é diferente de resolver bem o mesmo problema.

Me chamam a atenção os contratantes especializados. No exemplo que escolhemos, empresas de arquitetura e engenharia, que, para contratar Projetos AEC, não definem ou não observam o escopo do processo. É principalmente o processo que caracteriza o trabalho feito. Os mesmos profissionais que definem escopo nestas contratações e acabam decidindo apenas pelo menor preço do produto, se reúnem em associações, comissões etc. para defender a valorização profissional. Inflamam-se em discursos convincentes, mas na ação como contratantes, voltam a focar no produto em detrimento do processo, onde é realmente resguardado o valor da boa técnica. Devemos julgá-los pelo discurso ou pelo exemplo?

Se queremos serviços de qualidade, precisamos aprender a definir processos de qualidade. Inspecionar a qualidade apenas do produto em projetos não parece ser muito inteligente, afinal, todo projeto cria um resultado exclusivo e não há chances de ajustes do produto já entregue a não ser pelo retrabalho, com seus custos, prazos, desgaste e riscos.

Como profissional ou como empresa, como tem sido tratada na sua prática profissional a definição de escopo nas contratações de serviços? Como fornecedor ou como contratante, que procedimentos são previstos para garantir a qualidade dos resultados antes que eles estejam prontos? Qual o custo do retrabalho nos serviços? Quais seriam e qual o custo dos procedimentos que evitariam estes retrabalhos?

Nossos processos de trabalho são o que são porque são os melhores ou porque não sabemos fazer melhorias?