O tempo é relativo

Acho que quando uma pessoa se torna um cliente de consultoria de desenvolvimento de software a percepção de tempo dela muda brutalmente. Na verdade eles passam a viver num universo paralelo. No universo A, onde os desenvolvedores criam sistemas, o tempo passa devagar e no universo B onde fica a empresa do cliente, o tempo passa rápido – na proporção de 2/1 ou mais se comparado com o tranqüilo universo A. Esta é a minha conclusão depois de anos trabalhando como consultor.

Por exemplo: Submeta para aprovação do cliente um cronograma, projeto, orçamento de horas ou seja lá qual for o nome que você dá para aquele documento com prazos para o desenvolvimento de um sistema. Clientes em universos paralelos podem questionar você que 16 horas é muito tempo para a criação de uma feature qualquer, ainda que ela seja complexa. Diz que é possível fazer em 8 horas tranquilamente. Vejam, 16/8, é a tal proporção 2/1 que citei. Clientes em universos paralelos mais velozes podem sugerir que o tempo caia de 16 horas para 4 horas, afinal é só uma tela. Ou seja, este universo tem uma proporção de tempo de 4/1 se comparado com o universo normal, onde nós desenvolvedores mortais vivemos. É um universo Speed Racer.

Outros clientes vivem em universos com peculiaridades complexas na estrutura temporal. Nós, desenvolvedores mortais temos freqüentemente dificuldade em compreender tal lógica que desafia todos os conceitos da física. Por exemplo, certa vez estava trabalhando no tunning de um sistema que ajudei a desenvolver. O sistema permitia que uma certa atividade pudesse ser feita em lotes de itens cujo tipo não vem ao caso aqui. Então o usuário preparou uma planilha com os tempos atuais da atividade quando um item, quinze itens ou trinta itens eram submetidos. Vamos dizer que o resultado foi 1x, 15x e 30x. Obviamente todos insatisfatórios no rápido e misterioso universo em que eles vivem. Ao lado desta tabela, havia outra com os tempos esperados. Eles queriam que um item levasse 0,5x tempo. Até ai tudo bem. O problema era que quinze itens deveriam levar não 7,5x como esperado, mas sim 5x. E trinta itens deveriam levar 8x e não 15x. Ou seja, quanto mais itens processados, menor era o tempo individual de cada um, eles tendiam a zero. Se conseguísse atender o cliente, talvez se eu processasse milhões de itens eu conseguiria fazer o tempo correr ao contrário. Não fiz este teste porque eu poderia abrir um buraco negro ou alguma coisa assim e hoje você não estaria lendo isso.

Há ainda universos onde parar o tempo é algo corriqueiro. Suponha que seu cliente tenha aprovado seu cronograma e depois se lembrou de outra feature que ele quer no aplicativo. Ele não aceita mudar o prazo final, não aceita pagar horas extras para o desenvolvimento e não aceita pagar por mais recursos no projeto. Ele insistirá que dá para encaixar a tal feature no projeto sem comprometer o bolso dele e o prazo final. O que me leva a crer que no universo onde ele vive é possível parar o tempo, desenvolver a feature e depois soltar o tempo para que ele corra novamente.

Clientes são pessoas com estas e outras incríveis capacidades físicas que me admiram a cada contato e projeto novo. Há sempre algo surpreendente e desafiador por trás de cada solicitação em um projeto.