“Quando clientes potenciais entram em contato conosco, é provável que queiram
saber duas coisas: Quanto custa implementar a aplicação? Quanto tempo
demora?”, diz no seu site web o desenvolvedor Petri Kainulainen. E acrescenta:
“A resposta honesta para isto é ‘não fazemos ideia’. É claro que se nós
respondermos isso, ninguém vai contratar nossos serviços. Por isso é que usamos
estimativas de trabalho para poder dar alguma resposta”.
“Nossos clientes precisam de estimativas”
Há muitas variantes nisto, mas em geral a conclusão é a mesma: precisamos de
clientes e os clientes precisam de estimativas, por isso temos que fazê-las.
Alguns exemplos desta ideia, como explica o programador Woody Zuill no artigo do
seu site web, são:
● Os clientes aceitarão contratar nossos serviços para programar um software
personalizado para eles, só se nós fizermos uma “cotação”.
● A realidade dos negócios é que devemos oferecer estimativas aos nossos
clientes para que possamos trabalhar.
● Devemos dar boas estimativas porque nossos competidores estão fazendo
a mesma coisa.
● O cliente quer saber se nós podemos fazer seu trabalho com preço
acessível.
● O cliente precisa saber se pode ganhar dinheiro segundo o custo do seu
software, e é por isso que precisa de uma cotação.
Porém, como diz Petri no seu artigo, o problema de dar uma estimativa é que
muitas vezes não estamos dizendo a verdade.
As estimativas são suposições
Isto pode ser uma surpresa para eles, mas nossas estimativas são só isso:
suposições. É fácil descobrir se uma tarefa específica é pequena, média ou
grande. Porém, é muito difícil se dar conta de quanto trabalho é necessário
realmente para finalizar uma tarefa.
Um motivo disto é que, muitas vezes, as estimativas se baseiam em informação
insuficiente. O problema é que quando damos estes indicativos, utilizamos
exemplos de interfaces de usuários ou uma lista de histórias de usuários, e, por
isso, não há nenhuma maneira de saber quanto vamos demorar para programar
este software em particular.
Por quê? Porque não podemos estimar sobre alguma coisa que desconhecemos.
Por exemplo, não sabemos:
1. Como deveríamos validar os dados
2. Quais são as regras de negócio da aplicação
3. Como deveria ser implementada a autorização
Existem muitas perguntas sem respostas, e ainda deveríamos ser capazes de dar
estimativas exatas… o que seria uma utopia, segundo o que disse Petri.
As estimativas não nos incentivam a maximizar o valor agregado
As estimativas se usam para atingir dois objetivos diferentes:
● Para que o cliente saiba quanto tempo vai demorar a implementação da
aplicação e quanto custará.
● Para que a companhia de desenvolvimento de software tenha certeza de que
o projeto é rentável.
Woody menciona algumas considerações para levar em conta se tiver que dar
estimativas:
● Você está disposto a fazer uma cotação / valor de graça?
● Quem paga as estimativas dos trabalhos que finalmente não são
contratados?
● Quanto mais é necessário para “simular” um trabalho completo feito para os
“desconhecidos”?
● Por quê seu cliente deveria pagar por isso?
● Você vai dar uma aproximação? Por exemplo: “Não custará menos que isto,
mas não mais que isso”. Você pode garanti-lo?
● Se fazer o software custar mais do que foi calculado, você está disposto a
assumir essa perda? Por quê? Se não for possível, como lidará com isso?
Você negociará de novo o contrato?
Você sabe o suficiente sobre o trabalho para poder oferecer um preço /
cotação razoavelmente preciso?
● Se um competidor lhes oferecer uma melhor proposta, vão entrar em contato
de novo com vocês?
O caminho ágil
Jeff Sutherland, um dos criadores do processo de desenvolvimento de software da
metodologia Scrum, ministrou uma palestra na qual mencionou a regra de “80/20”:
“80 por cento do valor está no outro 20 por cento das características” de um
projeto de software. Y sugeriu que “deveríamos financiar 20% e não fazer o resto”.
“Acho que a regra é mais “95/5”, quer dizer: 95% do valor está aproximadamente
no outro 5% das funções, e as pessoas que pagarem pelo projeto verão terminado
o trabalho quando esse 5% estiver sendo usado”, explica Woody no seu artigo.
Por isso, alguns escolhem o “caminho ágil”. Neste modelo, é sabido que “os
requisitos surgem”. Se podemos permitir que os requerimentos mais importantes e
úteis surjam naturamente, isto será amortizado muito bem.
Por esse motivo, existe o pedido de estimativas: um cliente que precisa “saber
quanto custará” antes de decidir contratar os serviços para fazer o projeto, pode
não estar disposto a deixar que surjam os inconvenientes, pois simplesmente não é
sua maneira de pensar.
Não todos os clientes precisam de uma cotação
A conclusão é esta: pode-se escolher com quem fazer negócios. Se você
escolher atender os clientes que precisarem de estimativas, faça estimativas /
valores e descubra como fazer que isso funcione para você. Se escolher atender os
clientes dispostos a deixar surgir os requisitos, então escolha a maneira ágil e
aposte neles. É sua escolha.