© Copyright  2018 por Renê Ruggeri Engenharia e Consultoria Ltda. Desenvolvido por Navii Inteligência Digital

Como julgar a melhor solução técnica de um projeto

December 19, 2019

Todos sempre buscamos as melhores soluções para as questões que enfrentamos no dia a dia profissional. Algumas vezes acabamos usando soluções que reputamos como não tão boas, mas é a que se nos apresenta no momento. Outras vezes, utilizamos nosso arcabouço técnico para definir soluções que consideramos as melhores. E é aqui que surge um problema: o que devemos considerar melhor?

 

Melhor é uma daquelas palavras que depende de uma referência. Pergunta-se: melhor que o que? Parece simples responder essa questão: ora, melhor que a outra solução! Estamos nesse caso comparando uma solução com outra, ou seja, usando uma delas como referência.

 

 

Percebe-se neste ponto que estou me referindo aqui à solução para o produto do projeto, ou, como já referimos em outro texto, soluções para o que convencionamos chamar projeto produto. Se quiser, você pode recapitular este conceito em:

 

https://www.reneruggeri.com/single-post/2015/09/21/Projeto-Processo-e-Projeto-Produto

 

Mas, digamos que tenhamos três ou mais alternativas. Nesta situação precisamos comparar todas com todas? Se usarmos uma como referência restarão algumas melhores que ela e precisaremos fazer análises sucessivas até que isolemos uma que seja melhor que todas as demais. Não é um processo eficiente.

 

Entretanto, é comum que dois profissionais, ao julgarem um conjunto de alternativas, cheguem a resultados diferentes. Aliás, é comum que tenham posições diferentes em relação a um conjunto de apenas duas alternativas. Um prefere uma, enquanto o outro prefere a outra. Como resolver esse impasse, uma vez que é inegável que ele ocorra? Se você já teve alguma vivência profissional, já deve ter passado ou presenciado situações semelhantes.

 

A questão é que os critérios de avaliação sobre o que é melhor tendem a ser bastante subjetivos. Enquanto um acha que dez é a quantidade ideal de alguma coisa, outro acha que cinco é suficiente. Assim, as soluções que consideram seis e onze serão julgadas diferentemente. Percebemos que, embora primariamente a definição do que é melhor dependa de uma referência, num nível mais analítico, há a necessidade de uma uniformização do critério de julgamento. E é aqui que a técnica de gestão faz a diferença.

 

Quando se analisa as alternativas para um projeto, o julgamento sobre o que é melhor deve ser feito do ponto de vista do projeto e não do analista. Algo como: eu prefiro bolo de nozes, mas num projeto de festa infantil, o melhor é chocolate. Ou ainda: eu prefiro sistemas informatizados, mas a cultura atual da empresa demanda soluções mais tradicionais para que sejam bem recebidas (esse exemplo foi provocativo!).

 

Todo projeto nasce para resolver um problema, aproveitar uma oportunidade ou atender uma demanda. A fim de balizar o planejamento e as decisões do projeto, essa razão de sua existência (problema, oportunidade ou demanda) é traduzida, pelo empreendedor/proprietário/usuário em requisitos que devem ser atendidos. Escrevi sobre requisitos neste mesmo blog, veja:

 

https://www.reneruggeri.com/single-post/2016/1/22/Requisitos-no-Desenvolvimento-deEngenharia.

 

Os requisitos são a referência para julgar o que é melhor e muitas vezes contêm também os critérios. Ou seja, a melhor solução é aquela que atende mais de perto os requisitos. Não estamos falando de exceder os requisitos, mas atender na justa medida. Lembremos que o escopo do projeto é todo o trabalho necessário para atingir os objetivos e não mais do que isso. Esse “não mais do que isso” é fundamental para estabelecer um critério de julgamento.

 

Então, se eu acho que deve ser seis e nos requisitos está registrado dez, não interessa o que acho, pois dez é a referência a ser usada. Mas há alguns problemas comuns em relação à definição destas referências, ou desses requisitos, como será demonstrado a seguir.

 

Primeiramente, há requisitos que não são registrados por se considerar que são evidentes, mas nem sempre são de fato. A vida útil esperada para um imóvel, se nada for dito, tende a ser da ordem de algumas dezenas de anos. As soluções técnicas dadas para essas construções tendem a considerar isso como um requisito natural. Mas, se for uma construção que antecipadamente se saiba que deve durar apenas 10 anos, é possível propor soluções “melhores”, ou seja, que tenham durabilidade mais próxima dos 10 anos. Veja que é preciso explicitar o requisito de durabilidade.

 

Se, com a durabilidade, é uma questão de explicitação, com requisitos de natureza intangível a questão é um tanto diferente. Como traduzir em requisitos objetivos algo como “confortável”, ou “bonito”? Para confortável pode-se pensar em equiparar com ergonômico e buscar referenciais objetivos de ergonomia. Mas, para bonito, a situação é um tanto mais difícil.

 

Enfim, a definição de requisitos de forma objetiva e explícita não é uma questão meramente burocrática. Por serem referências e critérios que todas as partes interessadas devem considerar igualmente em um projeto, negligenciar a definição de requisitos costuma ser causa de muitas dificuldades e divergências.

 

Aliás, muitas vezes, é causa de falhas de comunicação. Enquanto alguns consideram os requisitos bem elucidados, outros não os percebem com facilidade gerando divergências de opiniões (por estarem em bases subjetivas).

 

Os requisitos estão na alçada do empreendedor/proprietário/usuário, enquanto as soluções técnicas estão na alçada do projetista. Não é à toa que a primeira etapa do “processo de desenvolvimento do projeto do produto” (o que nos nossos textos costumamos chamar de PDP) é o levantamento de informações. O que se busca, entre outras coisas, é elucidar os requisitos a serem atendidos pela solução que se pretende conceber. Em relação aos requisitos, o trabalho do projetista não é defini-los, mas levantá-los. Se um empreendedor delega ao projetista a definição dos requisitos, está em última instância dizendo que aceita qualquer solução, pois delega junto a referência e o critério de julgamento. Sem requisitos (ou com requisitos definidos pelo projetista) nem mesmo é possível fiscalizar a concepção das soluções. A tendência é que o projetista adeque os requisitos à solução subjetiva que deseja implantar.

 

A definição de requisitos não é apenas um processo previsto no PMBoK, ela é um importante aspecto na gestão de comunicações, das aquisições, dos riscos e das partes interessadas. Cuidemos dos requisitos dos projetos para que tenhamos produtos que atendam à demanda objetivamente.

Please reload

Featured Posts

Fases e Etapas: conceitos e consequências no sistema gerencial

January 17, 2020

1/10
Please reload

Recent Posts