Estimar ou não estimar?
Thiago Brito
11 de Fevereiro de 2019 4 minutos de leitura

Estimar uma tarefa é algo difícil e que gera diversas discussões, será que vale a pena fazer isso? Quando não devemos estimar?

Estimar as tarefas é algo complicado e totalmente diferente de dar prazo: quando você diz que vai levar um dia, de forma isolada e sem conversar com o time, Murphy traz aquele monte de interrupções que fazem com que uma tarefa leve dois dias. Fora as situações do completo oposto: você pensa que algo vai levar uma semana e descobre algo diferente que resolve o problema em uma manhã.

Com tantas possibilidades de erro, afinal pra que alguém dá prazo hoje em dia? A resposta é simples: todo mundo precisa disso.

Quando você vai no mecânico e ele diz que precisa trocar a correia dentada pois ela está a 1 km de explodir, você pede um prazo.

Quando alguém vai no médico com algo gravíssimo e em estado terminal. A primeira coisa que se pergunta é quanto tempo tem de vida.

E com tantas outras situações, o que faz um programador pensar que é especial a ponto de não conseguir ou querer dar um prazo?

E se mudarmos um pouco a lógica, no lugar de dar um prazo. Ex.:

Esta tarefa ficará pronta na próxima sexta-feira!

Que tal dar uma estimativa? Ex.:

Esta tarefa é de complexidade X e poderá ser incluída na versão Y, que tem uma previsão de ficar pronta na próxima sexta-feira.

Complicou? Talvez. Mas vamos falar um pouco mais sobre isso.

Existe alguma vantagem em estimar?

Para deixar claro sobre estimativa e prazo. Vamos ver o que diz o dicionario:

Estimate: an approximate calculation or judgment of the value, number, quantity, or extent of something.

Em suma, estimar algo é dar um valor, um julgamento. Ele pode ser qualquer coisa. Ex.: dificil, médio, fácil ou 1, 2, 3, 5, 8, 13 (onde 1 é mais fácil de todos e 13 é super difícil).

Este processo deve ser analisado com todo o time e devem chegar em um consenso. Uma das formas de trabalhar é analisar a complexidade de algo, trazendo várias vantagens:

  • Entender melhor a tarefa que está sendo feita
  • Lembrar de tarefas similares e ter uma ideia de comparação
  • Discutir com o time sobre o que pode dar certo/errado
  • Possibilidade grande de simplificar ao máximo a tarefa antes de qualquer coisa
  • Troca de conhecimentos entre o time
  • Com o tempo, seu time consegue medir quanto tempo uma tarefa com baixa complexidade costuma levar e quanto a mais um de alta complexidade leva.

    Será que é possível transformar uma tarefa de alta complexidade em duas de média complexidade? Assim, reduzimos o risco e conseguimos entregar mais valor aos clientes.

    Estas discussões, não importa como você trabalha, elas devem existir. Todos os envolvidos no desenvolvimento do projeto e, quando possível até mesmo os clientes, devem estar presentes para entender melhor o contexto e fazer suas estimativas.

    Tá, mas e quando alguém pedir prazo?

    É claro que você vai dar o prazo, mas somente depois de entender o contexto de tudo o que deve ser feito. O que é mais válido aqui, antes de dar o prazo, é que todo o time esteja com o máximo de informação sobre as tarefas.

    Simplifique ao máximo as tarefas e se comprometa inicialmente em entregar o que mais gera valor ao cliente primeiro, deixe claro ao cliente que o início do projeto algumas tarefas podem ficar de lado e isso é normal.

    Depois da primeira iteração, o time deve verificar o quanto foi entregue, quais tarefas ficaram de lado, o que deu certo e o que deu errado. Na próxima iteração, com mais conhecimento sobre o time, produto, empresa e cliente, seu time será mais capaz de entender qual é a sua verdadeira carga de trabalho.

    Desta foma, será cada vez mais capaz de trazer prazos mais e mais assertivos aos clientes e o time só tem a ganhar.

    Em geral, nenhum time gosta de estimar e dar prazo. A tendencia é sempre levar os números às alturas. Foram inúmeras vezes em que vi uma tarefa bastante simples se tornar algo que levaria dias para ser feita.

    E o problema não está nos desenvolvedores, eles estão apenas tentando se proteger. Se for este o seu caso, analise o real motivo de isso estar acontecendo e converse ao máximo com o time.

    O que deve ficar claro, é que esta é uma ferramenta para o time. Para a troca de conhecimentos, para o entendimento melhor do projeto, aumentando a produtividade, evitando desgastes com o cliente e trabalhando menos.

    Sim, analisar a tarefa antes de ser dado um prazo ao cliente e principalmente depois de todo o time analisar o que pode ou não dar errado elimina de forma bastante significativa o retrabalho que possa aparecer.

    Por fim, o trabalho de estimar resolve aquela chatice de dizer “entregamos na próxima sexta-feira” e ficar a semana inteira rezando e torcendo para que o time entregue dentro daquele chute que foi dado ao cliente.

    Não sofra, não de chute e não estime sem conversar com o seu time. Aos poucos aquela dor de cabeça vai passando e você nem lembra mais como viveu sem este processo...