Você já viu essa chamada em várias propagandas de produtos diversos e também deve ter visto em materiais promocionais de muitas indústrias. Se o produto não resolve o seu problema, devolva e pegue a grana que você gastou de volta. E não tem pra onde correr, está na lei que rege os direitos do consumidor, se o produto que ele comprou não servir para o fim desejado, ele tem todo o direito de devolver e dependendo do produto e do uso, ainda pode processar a empresa por fazer propaganda enganosa, pois ela pode estar dizendo que um produto faz algo sem fazer.

Tratemos então de trazer essa máxima da indústria “normal” para a nossa indústria de software. Quantas empresas de software você conhece que utilizam essa frase em seus sites institucionais, ou melhor, ao menos mencionam isso como sendo uma política da empresa?

Hã? Poucas? Só uma? Nunca viu?

Mas se isso é algo tão comum na experiente indústria de produtos, por que seria uma prática tão incomum na nossa jovem indústria de software, que adora copiar coisas da sua irmã mais velha?

Porque a indústria de software não costuma entregar o que o cliente deseja.

A maior parte das empresas que vendem soluções de software, escondem-se atrás de pilhas de documentos. Contratos que dizem exatamente o que o sistema deve fazer c como isso deve ser feito. E tudo isso antes de se escrever uma mísera linha de código. Quando muito, mostram um “demo”, pra tentar fazer o contrato descer goela abaixo em um cliente que está com medo de assinar o papel e não ter o seu real problema resolvido pela solução, porque ele esqueceu de adicionar um detalhezinho que passou despercebido ou que ele nem sabia que poderia ser implementado.

Começando com o pé esquerdo

O primeiro atraso em um projeto de desenvolvimento de software é a assinatura do contrato de prestação do serviço. A empresa de desenvolvimento deseja deixar o contrato o mais fechado possível, para evitar brechas que possam ser utilizadas no futuro pelo cliente e o cliente deseja fazer com que o contrato reflita todas as suas necessidades atuais e até mesmo futuras, pra evitar ter que passar por mais uma dessas negociações “malditas”, onde as partes desconfiariam até mesmo da boa vontade de suas próprias mães.

Algumas empresas chegam ao cúmulo de fazer contratos iniciais baratíssimos para o preço médio atual de mercado, esperando retirar os custos em contratos de manutenção ou de mudança de requisitos. Nestes contratos, já que o cliente já está “ganho”, eles não tem mais papas na língua, cobram o suficiente pra conseguir de volta o dinheiro que perderam com o contrato inicial. Afinal, se o contrato tem que ser feito mesmo, por que ter pena o cliente que só quer saber de sugar do seu trabalho?

Antes de iniciar o desenvolvimento de um projeto, o cliente normalmente não tem uma visão geral real sobre as suas necessidades. Ele normalmente não entende de desenvolvimento de software, entende de como funciona o seu negócio, então ele não é capaz de transpor as suas necessidades reais para software de forma direta. Pelo menos não quando o único meio de acesso ao software que ele tem são calhamaços de documentos de “definição de requisitos”.

Ele provavelmente vai investir muito dinheiro nessa solução e deseja ver esse dinheiro entrando de volta. A época do “informatiza porque é moda” passou, hoje as empresas desejam resultados, informatizam os seus processos porque acreditam que isso os vai tornar mais produtivos ou competitivos no mercado. Mas como é que eles conseguem fazer uma coisa dessas, adivinhando tudo o que o software vai poder fazer? Absolutamente, não.

Adivinhômetro

Contratos longos costumam se basear em adivinhômetros, analistas tentam adivinhar quais as necessidades do cliente e os clientes tentam adivinhar o que a solução vai poder fazer por eles. Sem um relacionamento próximo e sem um feedback constante de ambos os lados, o projeto dificilmente vai sair do jeito que ambos visualizavam.

Imagine que no meio da vigência daquele “contrato elefante branco”, o negócio do cliente sofre uma mudança brusca e ele precisa se atualizar para não ser engolido pela concorrência. Nesse caso, o máximo que ele vai poder fazer é “tentar” negociar com o fornecedor da solução pra ver se é possível alterar ou renegociar o contrato. Na melhor das hipóteses, ele vai perder tudo o que havia sido investido até aquele momento.

Os dois lados saem perdendo. O cliente vai ficar enraivecido por estar preso a um contrato engessado e o fornecedor vai sentir que dificilmente vai conseguir fechar algum outro contrato com esse mesmo cliente, depois de tantos problemas.

Contratos

O cliente e a empresa que está prestando o serviço devem partir em busca de um meio termo que possa ser benéfico para os dois lados. Uma das maneiras de se resolver esse problema é acabar com o “contrato elefante branco” e diluí-lo em diversos contratos menores. A equipe de desenvolvimento pode sentar com o cliente e buscar entender quais são as suas necessidades primárias, partindo dessas necessidades eles podem planejar tudo o que pode ser implementado em algumas (poucas) iterações, como por exemplo, seis iterações de um mês, fechando um primeiro contrato de seis meses.

Eles provavelmente não vão poder implementar tudo o que o cliente visualizou para esse primeiro passo, mas já vão estar com ele para fazer com que ele mesmo escolha o que deve ou não ser priorizado, afinal, o dinheiro pra pagar as contas sai do bolso dele, nada mais justo. Com iterações de um mês, eles vão ter um feedback (retorno) mais curto do cliente, que provavelmente vai acreditar bem mais no que está sendo desenvolvido e vai poder dar palpites e corrigir o caminho da ferramenta muito antes dela desandar completamente.

Mensalmente, antes do início da próxima iteração, a equipe de desenvolvimento vai sentar-se com o cliente pra mostrar as funcionaldiades que foram implementadas, para que ele possa validar que é realmente aquilo que ele deseja e para definir as prioridades da iteração que está para começar. Se você fizer as contas direitinho, o máximo que vai ser perdido se a equipe entendeu mal ou o cliente desenvolveu mal a idéia, é um mês de trabalho e não um projeto inteiro. Com toda essa troca de informações, a equipe dificilmente vai inventar “perfumaria” ou funcionalidades que ninguém precisa e é provável que até mesmo necessidades que o cliente acreditava que eram obrigatórias, terminem se mostrando pouco interessantes ou até mesmo removidas conforme ele entende como as coisas funcionam.

Contratos mais abertos ou com escopos menores são muito mais seguros tanto para o cliente, que vai poder controlar bem melhor o caminhar da sua solução, como para a empresa, que vai construir uma relação de confiança com o cliente que, garantidamente, deve terminar com a continuidade do desenvolvimento em novos contratos. O cliente vai sair satisfeito, tendo um produto mais próximo do que ele realmente desejava e o fornecedor sai satisfeito porque fez um bom serviço e vai ganhar moral, tanto internamente com seus funcionários, por terem desenvolvido uma solução vitoriosa, quanto no mercado, pois é cada vez mais difícil encontrar empresas de software que realmente conseguem cativar os seus clientes com bons serviços e soluções que resolvem os problemas certos.

Satisfação garantida só existe em projetos de software que buscam integrar os dois lados, que prezam pela comunicação e constante troca de informações e idéias entre os desenvolvedores e o cliente. E pra não esquecer do famoso bordão, “o cliente é quem manda”.

Esse texto é resultado das minhas anotações da leitura do livro de Tom e Mary Poppendieck, Lean Software Development, leitura obrigatória se você trabalha de verdade com desenvolvimento de software e gerência de projetos.