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.

Meu primeiro haikai

Tentei escrever hoje um haikai. Para quem não sabe, Haikai (em japonês: 俳句 Haiku ou Haicai?) é uma forma poética de origem japonesa, que valoriza a concisão e a objetividade. Mais informações aqui. Bem, ultimamente uma pergunta se faz presente no meu dia a dia. Tenho sido incomodado várias vezes pela dúvida: quanto do seu simples me será complexo?

Complicado?

Bom, vamos simplificar. Sempre que posso, escrevo, divago e traço considerações sobre meu convívio com o mundo tecnológico. Um assunto que no qual tenho dirigido meu foco de estudos, é sobre desenvolvimento e pragmatismo. A referencia ao haikai, é pelo fato de sua objetividade. Em três linhas, um poema inteiro, conciso e objetivo.

Porque algumas aplicações, web ou não, incistem em ser complexas? Qual a premissa utilizada no seu desenvolvimento: os óculos do Jhon com o olhar do Paul? (Engenheiros do Hawai). O que predomina, a visão do chefe, do cliente ou do desenvolvedor? Ou melhor: a visão do “é assim” ou a do “deveria ser assim”?

Este assunto é infinito, pois aplicações, sistemas não são prédios. A mutabilidade de suas razões é infinda. Uma simples brisa pode marcar o início de uma grande alteração de um software. Uma simples idéia borboleta pode bater asas e iniciar uma catastrofe em uma rede inteira. Mas as pessoas ainda querem ver prédios. Quais pessoas?

A pessoa que especifica pretende ver a materialização de uma idéia pessoal. Por mais que seja debatida, vai prevalecer a circunstância de quem idelizou. Se acaso num debate sangrento, uma especificação tiver alteração, será apenas uma outra forma de ver a mesma idéia inicial.

A pessoa que desenvolve tem o poder de acrescentar aquilo que melhor entende como certo para o momento. Se ela é obrigada a seguir um esquema a risca, ainda assim lhe sobra o código, filho querido e protegido, que nunca erra.

A pessoa que vai usar apenas espera poder encontrar a solução de algum problema que ainda não existe. Essas pessoas normalmente expressam frases assim: e se... e quando...

O mais interessante é que nenhumas delas está errada. O que claro, não significa que estão certas. O fato é que temos a tendência de deixar parte de nós naquilo que construímos. E as vezes esquecemos que parte de nós jamais compleatará o todo de um outro alguém. Assim, algo será ruim ou porquê não é a sua parte que alí está, ou porque sua visão de todo desconhece aquela parte estranha, naquele momento. Em resumo, estará ruim se não for do meu jeito.

Isto não é nenhuma novidade. É, na verdade, muito comum. Justifica, inclusive, algumas frases como: nem Jesus agradou a todos, ou: nem os dedos da mão são iguais. Mas não importa. Sempre há espaço para o novo.

Tenho testemunhado alguns equívocos, que se relacionam bem ao assunto. Por exemplo, há algum tempo conversando com amigos, disseram que sua chefia queria apostar no advento web (tarede?). Para isso, queria aplicações simples, diretas. Até aí tudo bem, não fosse o caso o time de desenvolvedores acreditar que seria necessário trabalhar menos. Apenas colocar menos campos, conversar com menos pessoas. Como resultado... bem, segundo eles ainda não há resultados.

Penso que há apenas dois caminhos a seguir: o do sucesso e o do retrabalho. Entendo que fracasso vem sempre depois de retrabalho, de muito retrabalho. Até porque não teria a menor graça um fracasso sem frustrações. No caso comentado por meus amigos, concluímos que um ponto crucial era a falta de planejamento. Sempre ouço coisas do tipo: “pai, perdoai o cliente, pois ele não sabe o que pede”. Tudo bem, vou concordar. Vou inclusive confessar que já me estressei por esta incapacidade nata de o cliente não possuir claridade ou coesão no que pede. Mas quantas vezes eu soube o que fazer?

Imagine a situação: um não sabe o que pede, mas acaba por pedir algo. O outro não sabe o que fazer, e acaba não fazendo nada. O planejamento não é tão somente um passo no desenvolvimento, mas o primeiro passo. E como sabemos, desenvolver não é como jogar amarelinha, onde se pode chegar ao céu saltando algumas casas. Não podemos jogar a malha e dizer: agora estou na casa da codificação, vamos saltar a casa do teste, parei na casa da conclusão...

Produzir uma aplicação deveria ser como produzir um haikai. Focando o objetivo para demonstar ao leitor (cliente) algo bem simple, mas que diga (faça) o necessário. Certos escritories japonezes ficavam meses pensando (modelando) seus poemas. Não havia um toque divino que lhes desse tudo de bandeija. Era necessário se esforçar. Assim, compor algo que lhe pareça simples e lhe se seja objetivo e direto, irá custar muito esforço de quem compõe. 

Assim como no haikai, devemos entregar o óbvio, não importando quão complexo tenha sido seu desenvolvimento ou atingimento. Ouso dizer que o simples é inversamente proporcional a complexidade envolvida na sua produção.

Mas a pergunta da visão de prédios ainda perdura. Porque insistimos em trazer a burocracia dos papeis para a tela do micro? Porque ainda tratamos aplicações como gestoras ou reparticições públicas, com intermináveis fluxos? Será que não queremos pagar a conta da complexidade, deixando ela para o cliente? Deixar que o cliente preencha 30 campos não será sempre melhor do que tratar 15 internamente no código, tornando-os desnecessários para o cliente?

Não vou me ater ao fato das incríveis regras de negócio, que por vezes obrigam desenvolvedores a rebolarem para conseguir o solicitado. Mas neste caso, não estaríamos hiper-valorizando a presença de uma parte estranha ao contexto, deixando que o cliente se vire com ela? As vezes penso o quanto maltratamos aquele que nos paga. O que me deixa intrigado, é que muitas vezes ele ainda fica feliz, pois vê toda uma parafernalha tecnológica fazer exetamente o que antigamente se fazia com papeis e officboys. Mesmo que esforço seja o memso e o boy agora se chama email.

No pragmatismo não há muito espaço para empatia, uma vez que o foco deve ser entendido apenas por e para ele mesmo. No entanto, no desenvolvimento sim, há espaço. Acredito que devemos ser empáticos na criação, e pragmáticos no produzir. E sempre lembrar que são coisas destintas.

Quanto ao haikai, eu bem que tentei...

meu esforço é vão

quando não posso atender

tão mero desejo