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.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.