Eu tinha falado antes das regras para desenvolvimento de software, segundo Patrick Hynds, e a última, a regra de quatro palavras dele, era essa:

“Sem especificação, sem estimativa”

Fiquei de falar um pouco mais dela, e esse post serve para isso.

A regra, a princípio, me pareceu óbvia e simples, mas isso é só uma impressão. Por isso quero falar dela aqui com mais detalhes.

Vamos começar pelo final, entendendo a segunda parte da frase. Preciamos entender o que é estimativa. Estimativa no dicionário (grifo meu):

Cálculo aproximativo que se faz de algo.

“Aproximativo” é a palavra chave. Significa que nada que seja uma estimativa é preciso, mas é aproximado. Pedir uma “estimativa precisa” é como pedir para subir para baixo, para sair para para dentro, e outros absurdos. Estimativa sempre é imprecisa, sempre é, no fundo, um chute. A não ser que você tenha uma bola de cristal, sua estimativa nunca vai ser precisa, a não ser que você considere desvios altíssimos (200% por exemplo) dentro da sua taxa aceita de precisão. Mas aí eu diria que você precisa rever seu conceito de precisão.

Sim, uma estimativa pode variar 200%. Ou 0%. É um chute, ele pode entrar no gol ou passar longe. E excelentes jogadores, com frequencia, também batem para fora.

Com isso claro, podemos falar da primeira parte da frase: especificação. Mas antes eu quero falar de como o mercado compra software hoje.

O modelo dominante hoje no mercado é comprar projetos fechados de software. Isso significa que o cliente determina o que quer, e os fornecedores dizem quanto vai custar. A visão geral, que entendo ser muito equivocada, é que o fornecedor é especialista, e vai conseguir um preço muito abaixo do que o próprio cliente conseguiria atingir, dada uma condição de competição.

A questão é que nesse cenário todos os fornecedores colocam a margem de risco no projeto. Nenhum deles vai assumir que a margem de risco é zero só para ganhar uma venda. Sabem porque? Porque não basta vender, tem que entregar. E é aí que o negócio complica. Sabendo disso, todo mundo coloca uma “gordurinha” no projeto, mesmo os departamentos internos, que atendem clientes da própria empresa.

Voltando então à especificação. É muito comum também no mercado brasileiro que a compra de software, seja ela interna ou externa, seja feita com base em uma especificação. Só que, se as especificações, da maneira com que em geral são feitas, só permitem a venda no estilo “Time and Material”, ou seja, hora aberta. O cliente geralmente pede o que vai querer, e não como vai querer. O “como” é responsabilidade do fornecedor que ganhar a concorrência, ou do departamento interno de TI, caso seja ele o fornecedor. Só que dizer “o que” mas não “como” aumenta ainda mais o risco da estimativa, que já é, por definição, imprecisa, e portanto arriscada, porque o fornecedor pode errar feio na definição de como vai fazer o que o cliente pediu. O resultado é que o custo proposto para a execução do projeto acaba ficando muito acima do que seria se o “como” tivesse sido definido.

Um bom exemplo é especificação baseada em casos e cenários de uso. São documentações de negócio, de alto nível. Dizem “a nota fiscal deve ser emitida clicando em x, y e z.” Isso é “o que” deve ser feito (emitir a NF). O “como” vai ser definido pelo fornecedor, que não tem a menor idéia do que é o projeto. Dessa maneira o cliente está pedindo para pagar mais. Ah, e a todos os analistas de sistemas: MER e diagrama de classes têm o mesmo problema.

MER, use cases, diagrama de classes, todos vão gerar especificações incompletas? Vão. Qual o resultado? Estimativas ruins. Nesse cenário, dou um passo além das propostas de Patrick Hynds, e digo que estimativa, por ser imprecisa por natureza, em pouco se beneficia de uma especificação mais completa, mesmo que ela indique o “como”. Digo isso porque ninguém sabe exatamente o que precisa quando compra um software, e mesmo que soubesse, isso poderia mudar, como de fato muda. Realizar uma especificação apurada em momento de escolha de fornecedor, ou seja, muito antes da codificação iniciar, é pedir para ter documentação desatualizada, ou seja, o projeto já começa com problema.

Como fazer então? Só há uma resposta: processo iterativo e curto. Nesse cenário as estimativas são trabalhadas com maior aproximação, e, ainda que imprecisas, tendem a ficar mais próximas do que será depois executado. Isso se deve porque a quantidade de informação a ser trabalhada é pequena, e porque o time trabalha com feedback constante entre, e durante, as iterações. Nesse cenário não faz nenhum sentido gerar estimativa para todo o projeto, a não ser que ela seja entendida como o que é: um chute.

Fica a dica então: compre desenvolvimento iterativo, e peça estimativas de períodos curtos. Não se engane.