Decisões técnicas ou de negócio?
Na minha coluna anterior, abordei a questão de que os desenvolvedores tendem a complicar as soluções mais do que o necessário. Ou seja, mesmo se limitadas às questões puramente técnicas, o pessoal tende a complicar. Seguindo esta linha da complicação desnecessária, existe um outro problema mais grave ainda: muitas vezes, uma decisão aparentemente técnica é na verdade uma decisão de negócio. A complicação ultrapassa o escopo técnico e passa a afetar diretamente o negócio que o software se propõe a ajudar.
Como esse problema pode acontecer? Qual é o interesse em complicar? Na verdade, pode haver várias razões, por exemplo:
· O desenvolvedor se sente muito mais confortável com uma determinada técnica e não quer aprender a outra, mais simples e eficaz;
· O desenvolvedor teme pelo seu emprego; um projeto mais complicado – desde que não seja cancelado – garante o seu emprego e de seus colegas;
· O desenvolvedor gostaria de aprender a tecnologia mais complicada para seu aprimoramento profissional, ao invés de usar uma técnica simples, porém já dominada;
· Pura e simples ignorância – o desenvolvedor simplesmente não sabe fazer de outra forma.
Por “desenvolvedor” entendo qualquer um que tome uma decisão técnica. Pode ser desde o programador, em escopos mais limitados, até o arquiteto, em um escopo mais amplo. Evidentemente, o arquiteto é quem tem o maior poder de complicar o projeto. Por exemplo, as decisões abaixo aparentemente são decisões técnicas de arquitetura:
· “Vamos usar uma arquitetura de quatro camadas ao invés de duas camadas”;
· “Usaremos uma biblioteca que permite criar simultaneamente versões Web e Windows”;
· “Nossa técnica de acesso a banco de dados funciona com qualquer banco de dados relacional”.
Aparentemente todas as características acima são desejáveis. Dificilmente o dono do projeto (quem está assinando os cheques) as questionará. Elas são aparentemente questões puramente técnicas e existem argumentos sensatos em favor de cada uma delas. O que o arquiteto “esquece” de dizer é que cada uma das decisões acima aumenta muito o custo e o tempo de desenvolvimento. Ou seja, elas são decisões que afetam enormemente o negócio. Seria mais adequando que o arquiteto colocasse as coisas nos seguintes termos:
· “Se usarmos uma arquitetura de duas camadas, o software estará pronto em três meses, mas as manutenções custarão o dobro e será difícil reutilizar seu código. Já se fizermos em quatro camadas, isso nos tomará seis meses, mas no futuro será muito mais fácil manter e reaproveitar as rotinas do programa para outras finalidades”;
· “Para termos simultaneamente versões Web e Windows, o custo aumentará em 50% e o produto final terá uma interface com usuário relativamente pobre”.
· “Ao permitir acesso a vários bancos de dados, gastaremos 40% a mais no desenvolvimento, o desempenho das operações de banco de dados será pior e ainda teremos que contratar ou treinar especialista nos vários bancos de dados para pelo menos nos ajudar nos testes”.
Colocada desta forma, fica evidente que as decisões são essencialmente de negócios. Pegue a primeira, por exemplo. Se o projeto for a longo prazo e com bom financiamento, quatro camadas é mais recomendável. Se for para aproveitar uma oportunidade que deixará de existir em quatro meses, evidentemente o desenvolvimento em duas camadas é o mais recomendável. Não existe uma decisão técnica e sim de negócio.
É muito importante que os desenvolvedores, especialmente os arquitetos, saibam que eles não são os donos da verdade. Eles devem oferecer alternativas para que os verdadeiros donos do projeto possam decidir o que é melhor para o negócio como um todo, mesmo que isto signifique usar técnicas “feias”.
Por outro lado, as pessoas que assinam os cheques não devem confiar cegamente nos arquitetos, por melhor que eles sejam. Eles devem aprender a fazer as perguntas certas, especialmente jogando com alternativas de preço e de prazo.
Mauro Sant’Anna (mas_mauro@hotmail.com) gosta muito do princípio “KISS – Keep It Simple, Stupid”. Ou seja, mantenha as coisas simples.
