Essa é uma dica que pode ser muito útil para freelancers, pequenas micro empresas de desenvolvimento de software ou gerentes de equipes de TI. Muito se fala e pratica sobre métodos ágeis, mas um dos maiores pitfalls que se pode ter em um projeto ágil é fechar um contrato que especifique um valor e um prazo determinados, muitas vezes incluindo valores de multas caso as funcionalidades não sejam entregues no prazo.

O problema disso, é que o custo de um projeto segue uma fórmula mais ou menos assim:

$ = Escopo * Qualidade / Tempo

A qualidade não deveria ser negociável, deveria sempre ser máxima ( o que significa que deveriam haver testes, refatoração, pair programming, enfim, o que a equipe de desenvolvimento achar necessário e ético ).

O grande problema então, é que ao fixar o tempo e o custo, o escopo acaba sendo fixo. E é evidente que se o escopo for fixo, o projeto não é ágil ( porque por definição não pode se adaptar à mudanças ).

E se por acaso o escopo mudar, aí então o problema aumenta… O que geralmente acontece nesse caso é que os desenvolvedores precisam trabalhar mais do que imaginaram no mesmo tempo, o que significa que a qualidade cai. E quando a qualidade cai novos bugs surgem, e fazem o projeto atrasar. E isso vira uma bola de neve rumo ao desastre.

Como então evitar tudo isso?

O jeito é não fixar uma data e nem um custo para o projeto. Mas falar é fácil, de acordo com a minha experiência como desenvolvedor e fundador de empresa é muito difícil um novo cliente já conhecer métodos ágeis. Geralmente um novo cliente acha que software é um trabalho mecânico, como fazer pão: são todos iguais, fácil e barato de fazer, custa um valor bem definido e é fácil de saber em quanto tempo fica pronto.

Mas não é bem assim que as coisas funcionam. Desenvolvimento de software é um trabalho intelectual e não mecânico, quase nunca um software é idêntico à outro, são difíceis e caros de serem produzidos e não é simples ter um valor bem definido do seu custo ou uma data de entrega garantida. Isso é algo que precisa ficar muito transparente no início de novos projetos, para que uma conversa franca possa continuar deste ponto.

Por outro lado é necessário passar uma estimativa para que se possa ter uma idéia da ordem de grandeza do custo e do tempo para que todos possam se organizar. Levando em consideração a incerteza do desenvolvimento, é preferível passar um interval ao invés de um prazo e custo definidos. Ou seja, ao invés de falar que o projeto custa por exemplo R$ 10k e fica pronto em um mês, é preferível orçar que fica entre R$ 7k e R$ 16k, e que deve levar entre 3 semanas e um mês e meio para ficar pronto. Geralmente o intervalo vai de:

(média - devio padrão) até (média + 2 * desvios padrões)

A forma como eu calculo a média e o desvio padrão fica para um próximo post, mas geralmente dá para usar algo como 0,7 * estimativa até 1,6 * estimativa caso não tenha um cálculo de desvio padrão.

É muito importante que haja entrega contínua de software neste caso, para que o cliente possa acompanhar concomitantemente o crescimento de custo ( que pode crescer de acordo com o número de horas trabalhadas ou por sprint ) e as entregas de funcionalidades. Desta forma, o cliente também não irá se “assustar” com o custo do desenvolvimento, pois terá acompanhada de perto tanto o custo quanto as entregas. ( se houverem problemas de comunicação, qualquer projeto bem intencionado está fadado ao fracasso, seja ele ágil ou não )

Outra coisa que vale notar, é que esse intervalo de custo e de tempo não devem ser muito grandes, pois fica difícil de se comprometer com a estimativa no pior caso ( quando o valor fica próximo da média + 2 desvios ). Quando o projeto é muito grande, envie um orçamento apenas do MVP ( Minimum Viable Product ), que seria o conjunto mínimo de funcionalidades, ou algo que não ultrapasse 2 meses de desenvolvimento, e nem chegue a estimar as tarefas depois disso ( porque estoque de backlog também é desperdício ). Se o cliente pedir um valor para o projeto inteiro, passe apenas uma ordem de grandeza ( digamos na ordem de 40k por exemplo ), e não se comprometa nem com prazos nem com custos do projeto completo, apenas se comprometa com a primeira fase ou MVP.

A falta de comprometimento com o projeto completo não chega a ser um problema, porque até lá o cliente vai ter em mãos um MVP e provavelmente vai ter repensado e replanejado todas as funcionalidades, e vai estar muito feliz da equipe estar disposta a desenvolver o que é o mais importante, ao invés de se ater ao escopo descrito em um contrato assinado.

Mas e o Contrato?

Se você estiver se perguntando como fica um modelo de contrato de escopo aberto, ele geralmente especifica apenas a quantidade de horas que devem ser trabalhadas no projeto ( ou número de sprints ), e que as tarefas a serem executadas serão negociadas entre o cliente e a equipe. No pior dos casos, este contrato também especifica que a equipe se compromete com a estimativa de pior caso do MVP.

A partir do momento que a relação entre o cliente e a equipe já foi estabelecida e há confiança entre as partes (geralmente na entrega do MVP), é possível retirar essa cláusula de comprometimento de pior caso e trabalhar de fato com escopo aberto, onde todos estão remando dentro do mesmo barco, e onde todos os problemas encontrados são discutidos e negociados. Se achar que o cliente possa não gostar do termo “escopo aberto” ( que é um pouco genérico demais mesmo ), chame esta nova fase de “contrato de manutenção”, afinal o cliente já está com um software em funcionamento.