Maquetes de Software

É comum, no início dos projetos de software, serem criados protótipos para permitir uma visualização do entendimento da equipe para o cliente/usuário, facilitando assim alinhar a visão de quem vai criar a ferramenta (o software) com a visão de quem precisa dele.

Como é de praxe na área de TI, os prazos são curtos e os orçamentos, em geral, apertados. Desta forma, os protótipos costumam ser feitos em pouquíssimo tempo e, portanto, em geral os engenheiros de software os consideram inúteis para o desenvolvimento efetivo do sistema.

É aí que, em minha visão, muitos projetos já começam destinados a desastres.

Os clientes e usuários de projetos desta natureza, e até mesmo gerentes que não tem conhecimento técnico na área, muitas vezes enxergam o protótipo como uma peça que pode ser incrementada até chegar ao produto desejado, o que não costuma ser verdade. Para piorar, de suas perspectivas, ao verem um protótipo que reflete em certo nível suas necessidades, entendem que grande parte do trabalho de desenvolvimento já está pronto, e portanto exigem que o protótipo se torne funcional em pouco tempo, ordenando que o projeto continue a partir do protótipo.

Creio que muitos leitores vão concordar comigo que esta prática leva ao desastre, e um tempo precioso do projeto é gasto refatorando e corrigindo defeitos com origem em uma arquitetura que não foi feita para a produção, mas apenas para uma apresentação ao cliente. Já tive muitas experiências similares, e percebi que o tempo total do projeto utilizando esta prática fica muito maior do que se o protótipo tivesse sido jogado fora para, então, iniciar as tarefas de engenharia (requisitos, negócio, software, etc) antes da codificação. A qualidade final do produto é ainda mais afetada por esta prática, que costuma ficar péssima quando o software é desenvolvido desta forma.

Visto estes problemas, e outros que convenientemente omiti, vejo a necessidade de criar um entendimento comum sobre o significado de um protótipo de software. Trago uma proposta diferente, que ainda não encontrei similar ao navegar pela internet.

Em breve chegamos lá, mas antes pensemos no termo "protótipo". É comum em diversas áreas, e muito visto em filmes de ficção, um protótipo ser uma primeira versão de determinado produto, em geral funcional, porém com desempenho abaixo do que a versão de produção em escala. Vejamos uma das definições do Grande Dicionário Larousse Cultural da Língua Portuguesa: "Em design, a primeira realização concreta de um projeto, com todas as características do produto final, antes de ser industrializado."

Vejo que é isso que muita gente entende ser um protótipo de software, e este entendimento talvez venha destes casos, mas digo que esta definição não se aplica a software.

Assim sendo, finalmente chego à minha proposta: que paremos de chamar estas carcaças não funcionais de protótipos, e passemos a chamar de maquetes de software.
O objetivo é facilitar, por analogia, ao cliente/usuário entender a utilidade (ou inutilidade) do mesmo com uma analogia a maquetes utilizadas na construção civil.

Uma maquete serve muito bem, para prover ao cliente de um projeto de construção, uma visão de como ficará o produto final. Ao mesmo tempo, fica claro para ele que a casa não será construída a partir da maquete. Óbvio que paredes de isopor e componentes de papel não tem capacidade de sustentar uma casa, aguentar ao mal tempo, prover encanamento, eletricidade ou quaisquer características de uma casa real. Óbvio? Então porque não é visto sob este ponto de vista quando se trata de um software?

A idéia é que o mesmo princípio se aplica à maquete de software. Ela não é estruturada para suportar um uso real. Ela não tem uma arquitetura que facilite sua manutenção ou evolução. A maquete certamente não foi pensada para escalabilidade, segurança e outros assuntos necessários à produção de um software.

Assim sendo, proponho que lidemos com este tipo de produto, que hoje chamamos de protótipo não-funcional, pelo nome de Maquete de Software. Recomendo, também, que seja explicado muito bem a todos envolvidos o significado disto, de forma que novos projetos de software reduzam a chance de serem forçados a transformar um prédio de papel em um arranha céu.