Em Busca da Perfeição

Alguém por acaso já ouviu o termo: encontro da perfeição? Eu nunca vi. Em meu pequeno mundo e em minha parca experiência, principalmente no ramo industrial onde trabalhei por alguns anos, jamais vi uma gerência ou diretoria falar do encontro da perfeição. Inclusive, o termo em busca da perfeição é parágrafo garantido de algumas políticas de qualidade.

Seria a perfeição então algo inatingível? E se sim, porque ainda a buscamos? Tenho me perguntado isto ultimamente devido a uma incapacidade de entregar um certo projeto. No caso específico, o cliente deixou de se comportar como tal, e acabou passando por uma metamofose, transformando-se em adjunto de avaliação técnica. Embora não domine, acredita que o projeto não pode estar concluído se não possuir a capacidade de se comportar bem quando ocorrer um fato, ainda não determinado, no futuro. Meu pai de santo se recusou a fazer consultas compulsórias.

Claro, esta metamorfose não teria ocorrido se minha capacidade de dizer não estivesse mais apurada. Isto não importa. O fato é que o projeto não se materializa como produção porque foi andar no   infindo caminho da busca da perfeição.

Neste meu estudo de “caso perdido”, pude notar que o perfeito de agora é simplesmente o imperfeito de anteontem. E que o perfeito de ontem, é um caso a ser estudado, mas que não necessariamente é necessário. Ou seja, o projeto deve ser orientado a conjunturas e especulações.

Uma outra coisa que pude notar é o receio de que o projeto não fique a cara do adjunto de avaliação técnica, mesmo que ele sequer vai usar o projeto, neste caso um sistema. Assim, o meu não mais cliente usa de um pré-contexto: a sua experiência deverá prevalecer da forma que é contextualizada no seu conhecimento.

Se fossemos capazes de interpretar estas variações do conhecimento, a produção de software estaria num patamar futurístico. Isto porque nosso conhecimento se apresenta em função das necessidades intelectuais de um determinado momento. Ocorre um problema, e se ele nos é desconhecido nosso raciocínio é direcionado a encontrar a maneira mais rápida de solucioná-lo, não a melhor. Se este mesmo problema ocorre novamente, é simples para o cérebro recobrar uma solução já aplicada, nos dando tempo para projetar uma outra soluções e então poder avaliá-la como melhor ou pior, e assim sucessivamente. Assim formamos a experiência.

No entanto é individual, depende de quantas vezes o problema é apresentado a cada pessoa e em que tipo de ambiente. E, claro, qual a solução rápida de cada um, que originou o ciclo pessoal da experiência.

A busca pela perfeição aplicada a este meu projeto, o torna um celeiro de experimentações, que jamais terá fim. Nenhuma tentativa será boa o suficiente a partir de amanha, e todas serão obsoletas depois de amanha, podendo ser o algo perfeito no mês que vem.

Para este caso, não há solução. A impressão de um projeto inacabado já está presente no adjunto de avaliação técnica, que neste momento retorna a crisálida e volta a ser cliente. E faz uma distinção de papéis: o cliente é quem se aborrece, o adjunto tem méritos das boas ideias, mas se não vai para produção ou não termina nunca a culpa é do desenvolvedor.

Qual a melhor saída neste caso? Continuar a busca pela perfeição? Abandonar o projeto? Acredito que um debate, não embate, é sempre a melhor opção. Claro, não será uma especificação assinada com sangue com resolverá os problemas. Ao contrário, pode até piorar.

Neste meu caso em específico, tentei mostrar ao cliente sua posição de Stakeholder, como uma parte interessada para que ele pudesse se manifestar em entregas e não em projeções que ainda não foram desenvolvidas. Solicitei que analisasse o quão genérico deveria ser a aplicação, para que outras opiniões fossem ouvidas. E o principal, que o todo fosse repartido em partes, segundo o negócio, para que cada uma fosse avaliada em particular.

Mas não é uma solução, e sim um paliativo. Não é possível saber quanto tempo meu cliente se comportará como cliente. Tudo isto porque houve uma falha de planejamento: a da definição de papéis. Ou seja, a culpa realmente é do desenvolvedor.