Quando falamos em gestão de um time de engenharia de software, os principais desafios que vem à cabeça são como estimar as atividades, e como lidar com as expectativas dos stakeholders. O fato é que estimativas feitas durante a fase de planejamento sempre são otimistas, considerando o “caminho feliz”, o que na prática, é raro de acontecer. Além disso, mesmo com uma excelente especificação e bom planejamento das atividades, é quase impossível estimar a quantidade de horas ou dias exatos que vai levar para uma nova feature do sistema ficar disponível para o cliente.
E aqui vem o maior problema, nós estamos falando de estimativas e não de um prazo assertivo de quando a atividade será finalizada. Obviamente, não podemos deixar o projeto “correr solto”, precisamos ter um time-line e o mínimo de previsibilidade para podermos evoluir o produto, e fazer o roadmap acontecer, mas precisamos também trabalhar com a realidade. E aqui vão algumas dicas de como podemos trabalhar com prazos, mas realistas.
Como melhorar as estimativas do meu time?
Trabalhe com intervalos de tempo e não datas exatas
Uma das principais coisas que precisamos entender, é que não dá para definirmos um dia exato que uma feature, ou um pacote de features vai ser entregue em produção. Existem muitas variáveis envolvidas no processo, além dos impedimentos e desafios técnicos que podem ser encontrados durante o desenvolvimento, quem nunca precisou repensar uma feature? Ou então, achou uma falha lógica durante os testes/homologação da atividade, relacionada a uma regra ou módulo antigo do sistema, que não foram considerados durante o planejamento?
Bom, isso faz parte do dia a dia de trabalho de qualquer time de desenvolvimento, e reajustar a rota faz parte do processo. Da mesma forma que não podemos definir datas exatas, é também muito difícil conseguir prever todos esses problemas durante o planejamento e refinamento das atividades. Por isso, sempre faça estimativas com intervalos de tempo: sendo otimista entregamos isso em 10 dias, e sendo mais pessimista entregamos em 14 dias, então sabemos que aquele pacote será entregue entre 10 a 14 dias.
Arrume o trilho do trem, com o trem em movimento
É claro que simplesmente começar a trabalhar com intervalos, não vai solucionar todos os problemas das estimativas. Mas aqui entra um segundo passo, que combinado com essa questão da estimativa em intervalo, pode ajudar a melhorar as coisas.
Quando falamos em desenvolvimento de software e estimativas, normalmente nós temos 3 fatores principais que devem ser considerados: tempo, qualidade e investimento. Você já deve ter visto ou ouvido sobre isso quando procurava conteúdos de gestão de times de engenharia, então vou resumir o conceito.
Se você quer fazer em pouco tempo e com muita qualidade, vai gastar mais dinheiro. Se você quer economizar dinheiro, e manter a qualidade, vai gastar mais tempo. Agora, se você quer economizar tempo e dinheiro, provavelmente a qualidade vai ficar de lado. No mundo ideal seria: gastar pouco dinheiro, fazer rápido e com alta qualidade, mas isso é bem difícil. Por isso, normalmente nós prezamos por manter a qualidade, já temos um orçamento aprovado e a única coisa que podemos ajustar é o tempo.
Porém, existe um quarto elemento: o escopo, que nada mais é do que a forma como vamos entregar algo para o nosso cliente. Quando temos essa noção de que podemos entregar valor para o cliente, com mais ou menos detalhes numa feature do sistema, e combinamos isso com a nossa estimativa de intervalo de tempo, as coisas começam a tomar mais forma.
Em resumo, o que precisamos é ter muito claro o nosso intervalo de tempo e acompanhar o desenvolvimento a cada dia, se estamos perto da menor data do nosso prazo, e longe de concluir a feature, é hora de diminuir o escopo. E isso deve ser feito sem cerimônia, pois aquela ideia de colocar mais gente no meio da demanda para ajudar a entregar a tempo, só vai causar mais atrasos, foque em ajustar a entrega de valor dentro do tempo disponível.
Faça estimativas baseadas em dados históricos e não achismo
Uma coisa que vejo frequentemente os times errando, é que toda vez que vão estimar algo, sempre fazem aquela “conta de padaria”: isso dá pra fazer em 2 dias, aquilo em 3 e assim por diante. Ou então, ficam tentando lembrar quanto tempo gastaram para fazer uma feature X no passado, e tentam estimar a nova baseada nisso. É claro que isso não funciona bem, e as chances de definir um prazo (mesmo com intervalo) muito errado, são grandes.
Por isso, é muito importante coletar métricas do time, como Throughput, Lead Time, Lead Time Breakdown, WIP Limit e outras. Quando temos um histórico de métricas e sabemos quanto tempo em média leva para entregar uma feature, baseando-se no que o time já fez e não no que pretende fazer, nossas estimativas tendem a ser mais realistas.
E aqui vai um ponto importante, apesar de eu ter citado “tempo médio”, nunca considera a média de tempo que o time leva para entregar uma feature, a variação normalmente é alta, e pode tanto dar um prazo exageradamente grande, quanto também um prazo impossível de atingir. Uma forma melhor de fazer isso é usando percentis, e podemos combinar isso muito bem com a questão de prazos de entrega em intervalos de tempo.
Apenas para deixar mais claro, caso você não se lembre como funciona. Quando falamos, por exemplo, que o percentil 75 do tempo de entrega do time é de 7 dias, estamos dizendo que 75% das entregas que o time já realizou, ocorreram em até 7 dias.
Por isso, normalmente fazemos assim: o percentil 50 é o prazo otimista, o percentil 75 é mais realista, e o percentil 95 é o pessimista. Normalmente é mais seguro trabalhar entre o p75 e o p95, mas isso também depende da natureza da feature, se for algo com um escopo mais maleável, pode-se trabalhar com o p50 e p75.
De qualquer forma, olhando para as métricas históricas do time e usando percentis ao invés de média, os intervalos das estimativas de entrega do seu time, serão mais confiáveis.
Próximos passos
Lembre-se que essas são apenas algumas dicas de como melhorar as estimativas do seu time, mas se você se interessa pelo assunto de gestão de times de engenharia e como lidar com prazos e entregas, veja também nossos artigos sobre como funcionam cada uma dessas métricas: Throughput, Lead Time, Lead Time Breakdown.
Vale mencionar que essas métricas todas estão conectadas, então se nas últimas duas semanas a capacidade de entrega do seu time (Throughput) diminuiu, o seu Lead Time aumentou – e olhando o Lead Time Breakdown por etapa do fluxo, você pode encontrar uma fase que está gerando um gargalo e atrapalhando as entregas. Além disso, pode ser que o seu time esteja trabalhando com um limite de WIP muito alto, e que isso esteja dificultando o processo de entrega.
Gerir as métricas de um time pode dar trabalho, mas com certeza é um investimento de tempo que vale a pena fazer para melhorar os resultados do seu time.
E se você está procurando uma ajuda especializada nisso, conheça a Kody, nosso copilot de gestão de projetos com uso de IA. Toda essa parte de acompanhar as métricas do time, relacionar os resultados e entender se as atividades estão no prazo ou precisam de um ajuste de escopo, ela consegue fazer para você, além de muitos outros recursos como apoio para a daily, sumarização semanal dos resultados do time, chat para tirar dúvidas com a IA e muitos outros recursos.
