Você ainda acredita em estimativas? Nós, não.
Embora aceitemos que ter uma boa ideia de esforço e prazo sejam diferenciais para o negócio, deixamos de acreditar que temos condições de sermos assertivos através de estimativas.
Um mundo onde estimar é obrigatório
Durante muito tempo, na Guiando, acreditávamos que nossa baixa assertividade estava associada a qualidade do detalhamento das features que desejávamos entregar. Depois, passamos a acreditar que o problema era nossa base histórica. Depois, acreditávamos que o problema era o nosso método de trabalho. No fim, voltávamos ao começo…
Já tentamos de tudo. Já colocamos bons especialistas trabalhando junto ao time de negócio para deixar nossos descritivos mais claros. Já estimamos com base em pontos de função. Já juntamos nosso time em uma sala para “brincar” com planning poker. Entretanto, no final, continuávamos errando miseravelmente.
Nossa ânsia em estimar certo foi tornando nosso processo cada vez mais caro. Chegamos a gastar horas valiosas de trabalho em reuniões “planning” e de “review”. Mas, na prática, continuamos falhando.
Hoje, acreditamos que um mundo onde estimar é obrigatório é aquele onde migramos de uma abordagem para outra, muitas vezes mais exótica e mais cara, mas sem garantias de sucesso e com quase certeza de fracasso.
Por que paramos de estimar?
Em termos simples, porque entendemos que não é possível estimar assertivamente. Mesmo que fosse, seria pouco útil.
Na prática, percebemos que a ideia de esforço que a área de negócios busca tem de ser bem menos precisa do que achávamos (se a empresa cobra custo + margem, está fazendo errado). Percebemos que questões como o “custo de não ter uma feature” são mais relevantes do que o custo de desenvolver a feature.
Finalmente, vimos que a priorização tem muito mais impacto nos prazos de entrega do que os tempos de desenvolvimento (que podemos estimar).
O que estamos fazendo
Ainda fazemos estimativas para a área de negócio. Mas, agora, falamos em ordens de grandeza aproximadas e não em horas precisas (Sabemos que são estimativas, mas elas estão muito mais leves).
Aceitamos que os requisitos mudam. Também passamos a aceitar que as prioridades mudam. Isso é normal! Por isso, é mais prático trabalhar com deadlines (limitações de prazo e orçamento) do que com ideias fantasiosas de esforço e prazo.
Para sermos mais precisos, estamos focando em melhorar o processo como um todo. Aprendemos que o grande desafio é minimizar a variabilidade (tema para outro post) em nossas entregas e também entregar de forma mais frequente.
Hoje, olhamos com muita atenção para o leadtime, para o cycletime e para o throughput. Procuramos mais eficiência global do que local. Queremos gerar mais valor no todo do que em cada tarefa individualmente. E usamos essas métricas para medir o processo e acompanhar se tudo está caminhando bem.
Você ainda acredita que vale a pena estimar? Compartilhe por que pra você faz sentido (ou por que não!) nos comentários.
14 respostas
Achei bem bacana a publicação, até compartilhei com os integrantes do projeto aqui. No projeto atual passamos de story points no scrum poker pra micro tarefas de no máximo 8h. Sinto ainda que perdemos muito tempo tentando ser assertivos na estimativa e o escopo sempre muda.
Gosto mais dos pontos por isso, são uma estimativa leve e rápida, pode ser fundamentada em alguns pontos como quais componentes do projeto sofrerão alteração (cliente, serviços, banco de dados) e duram menos, focando mesmo na execução e análise das necessidades do negócio.
Obrigado por compartilhar Rogério! Também preferimos estimativas em pontos à estimativas em horas, mas ainda melhor é não estimar. Tínhamos a mesma sensação que você que gastávamos muito tempo tentando ser assertivos e na prática errávamos do mesmo jeito e tudo mudava a todo momento.
Algo que foi surpreendente para nós foi ver que o time de negócio não era assim tão dependente de estimativas assertivas.
Acho que esse é o grande benefício de estimar usando pontos e não horas. Mas enfim, estimar em pontos é outro problema! ?
Vinícius, sem dúvidas estimar em pontos tem várias vantagens em relação a horas, porém na nossa experiência era inevitável para as pessoas fazerem correlações diretas de pontos com horas.
Obrigado pelo comentário.
Elemar, num modelo de negócio com muitos clientes e um único software é difícil criar uma métrica para elaboração de custo e orçamentos. Você tem alguma sugestão?
Na minha opinião, custos podem e devem ser levantados. Mas, novamente em minha opinião, é uma falha usar a estratégia “custo + margem” para fonecer um orçamento. O custo deve ser um balisador para viabilidade.
Mas ao final pontos são convertidos em horas.
Eliminar completamente toda e qualquer idéia de “estimativa” é, na minha opinião, uma utopia que só seria alcançável em alguns ambientes muito específicos (e raros).
Ao mesmo tempo, não acredito em “estimativa precisa em horas”, nem mesmo em pontos de função pois eu nunca vi essas abordagens funcionarem na prática ao longo dos meus 16 anos trabalhando com desenvolvimento de software.
Precisamos sim ter uma idéia de ordem de grandeza da complexidade das features pois sem isso fica impraticável tomar qualquer decisão de negócio.
A prática com a qual fui mais bem-sucedido até o momento também foi a de monitorar métricas de throughtput e lead-time, quebrando as tarefas dentro de uma ordem de grandeza pré-determinada e utilizando alguma forma de “probabilistc forecasting” (como simulação Monte-Carlo) para auxiliar na definição de um deadline provável.
Rodrigo, obrigado por compartilhar sua experiência. Concordamos que eliminar completamente qualquer ideia de estimativa é difícil. No nosso caso foi possível eliminar todos processos, mas, por exemplo, no processo de entendimento das solicitações os POs fazem um dimensionamento dos itens para manter a variabilidade baixa. Todavia, não entendemos esse processo como uma estimativa, pois acaba sendo o processo natural de entendimento dos itens e não há nenhuma métrica ou esforço para tentar inferir quanto tempo vai levar a execução daquele item.
Conforme falamos no post, percebemos que o negócio é muito mais sensível ao custo de não ter uma feature do que ao custo de desenvolvê-la.
Elemar, faz um pouco de sentido o seu artigo quando você diz que não sabemos estimar corretamente. É muito bonito o seu discurso mas, pense no diretor da sua empresa pensando no lançamento de um produto novo no mercado, uma funcionalidade crucial para o crescimento do negócio, onde não há somente software envolvido, mas todo um planejamento de Marketing, análise de valor agregado, viabilização de fluxo de caixa, preparo de times de operação e suporte para estar à postos, contratos com fornecedores… Pense também no caso de você ser um empresário, quando seu cliente te pede um prazo para entrega do seu produto (ganha pão de sua casa), se ele não sabe quando ele vai ter o seu produto/serviço, certamente ele irá te trocar pelo seu concorrente. Acho que você deve refletir um pouco mais sobre seu artigo e tentar sair um pouco da caixa e olhar ao seu redor e enxergar o mundo e o mercado como ele é. Você não precisa ser tão extremista, não precisa tentar dar uma estimativa extremamente precisa mas acho que você vai sofrer se não der estimativa alguma…
Olá Camila. Obrigado pelo feedback. Mas, fazendo justiça, o autor do post é o Fernando e não eu. 🙂
De qualquer forma, é importante destacar que sou diretor da Guiando e estou na área de desenvolvimento de produtos de software há mais de 20 anos. Acho que isso me credencia para opinar sobre como as coisas funcionam no “mundo real”. Certo?
Desenvolver produto vai muito além de desenvolver o software. O primeiro ponto a destacar é, por exemplo, a definição da proposição de valor e a validação dessa proposição junto ao mercado. Isso sempre acontece de forma iterativa. NÃO HÁ COMO DETERMINAR SE A PROPOSIÇÃO DE VALOR ESTÁ CORRETA ATÉ VALIDAR COM O MERCADO. Daí, a necessidade de soluções mínimas. Essa é a atribuição da área de marketing e preocupação fundamental para determinar, inclusive, o “depósito de valor” que está sendo coberto e que irá determinar o preço do novo produto.
Também há de se considerar que as “demandas críticas” geralmente obedecem a uma janela. Ou seja, o lançamento tem data limite para ocorrer. Certo? Assim sendo, não seria a priorização mais relevante que a estimativa? No seu caso, quando ocorrem atrasos, eles ocorrem por “erro de estimativa” ou por alterações de prioridade? Onde está o maior tempo – no desenvolvimento, ou em filas para iniciar a implementação -> Testes -> Deploy?
Veja, obviamente preciso ter uma ideia de grandeza quanto a investimentos e esforços. Mas, não mais que isso.
Em tempo, recomendo a leitura desse post http://elemarjr.com/pt/2018/02/definindo-produto-pronto-para-apaziguar-entre-dev-mkt-e-vendas/
Sempre achei estimativas complicadas de se realizarem. É uma das coisas mais complicadas para mim como desenvolvedor. Ainda mais quando não se tem todos os requisitos necessários para cada tarefa (o que é praticamente impossível em uma proposta comercial). Ainda esbarramos em problemas como ambiente e massa para teste, disponibilidade desse mesmo ambiente, similaridade entre ambientes de teste e produção, disponibilidade de acesso à área de negócio para solução de dúvidas, etc.
Quer me deixar perdido é pedir para estimar o tempo que gasto para uma determinada atividade.
Creio que em algum momento do processo haverão estimativas, seja em horas ou dias. No processo de desenvolvimento na qual participo atualmente (com sprint e release semanal), não fazemos mais estimativas do tipo “chute”, onde a pessoa “chuta” quantos pontos ou horas leva para concluir uma tarefa. Adotamos ao invés disso o #NoEstimates, que tem se mostrado muito produtivo. https://jonwldw.com/planejando-uma-sprint-assertiva-sem-estimativas/