Por que metrificar os dados gerados nos projetos é tão importante?
E ai, bença! Tudo belezinha?
"Dados são o petróleo do futuro". Com certeza já vimos essa frase muitas vezes, sempre que ouvimos falar sobre dados. Cada clique que deixamos no rastro das nossas redes sociais, marketplaces, e-commerces e derivados vale ouro para muitas empresas (tá ai lembrando nos anúncios da Shopee que ficam aparecendo na tua tela sem tu entender porquê né, abençoado?). O mercado quer os nossos dados para que, por exemplo, ações de marketing sejam direcionadas, a fim de fisgar novos consumidores e fidelizar os já convertidos. Quando atuamos em projetos uma grande quantidade de informações também acaba sendo gerada: horas trabalhadas, dados de fluxo de entregas, dados financeiros, dados de qualidade e por ai vai. Mas a existência dos dados por si só não garante muita coisa se os mesmos não forem metrificados e não fizerem sentido. Quando falamos em metrificar estamos falando em medir e isso faz muito sentido quando estamos no contexto de gestão, porém, como diria Peter Drunker, "se você não pode medir, você não consegue gerenciar".
Dados não metrificados
Ter o dinheiro que foi planejado para executar determinada atividade e quanto foi efetivamente gasto são dados produzidos em um projeto, porém isoladamente não nos diz muita coisa, só diz o que eu tinha e o que eu gastei. Mas se eu conseguir entender o quão eficiente foi esse gasto relacionado ao que foi entregue, isso sim pode me dar uma métrica importante: o valor agregado, e assim posso calcular o índice de desempenho dos custos (CPI) e ter uma noção se o projeto está com tendencia de atrasado nas entregas ou não. O mesmo acontece com os dados históricos. Imagine que você gerencia um projeto de desenvolvimento de software, que encontra-se na 11a. interação (sprint 11) e portanto está munido de dados sobre essas sprints: estórias planejadas em cada Sprint e estórias entregues em cada sprint. Novamente, dados que, isoladamente, não trazem muita coisa, mas metrificados podem nos dar uma informação importante, que nos dá mais assertividade nas previsões de entrega de novas features: a cadência de entrega do time.
Tipo de Métricas
Quando falamos de métricas o grande desafio é estabelecer um propósito para cada uma delas. A métrica, acima de qualquer coisa, precisa fazer sentido. Muitos gestores utilizam métricas que endossam cenários já conhecidos, mas falam muito pouco sobre como nos planejarmos para otimizarmos os números no futuro. Quando gerenciamos projetos geralmente estamos mais propensos a construir métricas de eficiência, tais como Troughtput, Leadtime, Work in Progress, CPI, SPI e cycle time, porém, existem outros domínios de métricas que podem ser considerados:
Métricas de Negócio:
NPS (Net Promote Score);
Payback
Fit For Purpose;
Churn
Métricas Culturais:
Squad Health Check;
Radar da Felicidade;
Turnover;
Métricas de Produto:
Engagement;
Acquisition;
Retention;
Métricas Técnicas:
Análise de Bugs;
Qualidade de Código;
Cobertura de Testes; Essas mais voltados para o Desenvolvimento de Sotwares
Muitas vezes (por não dizer, em sua maioria) há um prévio descrédito dessas métricas, principalmente quando apresentadas aos times, por acharem (erroneamente) que é uma forma de apontar problemas ou de prover microgerenciamento. Na verdade essas métricas são um produto do trabalho do time para benefício do próprio time e se isso não ficar claro para todos o engajamento necessário para mudança de comportamento fornecida por essas métricas por não ocorrer. É extremamente recomendável que essas métricas sejam regularmente compartilhadas com o time, a fim de buscar, dentre outras coisas, a causa-raiz de gargalos e demais problemas identificados.
Metrificando dados dos projetos
O primeiro grande desafio aqui é coletar os dados produzidos no projeto. Nem sempre esses dados estão facilmente disponíveis e tudo depende das ferramentas utilizadas no projeto e a disponibilidade do GP em coletar alguns dados manualmente (as vezes se faz necessário). Algumas métricas de fluxo, por exemplo, precisam de um input diário de informações para que seja possível realizar a análise adequada.
Um exemplo prático: o time planejou desenvolver na Sprint XX uma nova feature, duas melhorias, 2 débitos técnicos e 4 bugs, divididos em 17 UDs (unidades de desenvolvimento), que podem ser estórias, melhorias, bugs, tech debits, etc. Por um acordo prévio o time definiu que o percentual de trabalho em WORK IN PROGRESS (WIP) não deveria passar de 45% do total do backlog da sprint, para não comprometer o fluxo. Como pode ser visto no Controle de Fluxo Diário, no terceiro dia da Sprint o PO informou que deveríamos incluir mais uma melhoria considerada crítica para a próxima release, aumentando o escopo de entrega. Ainda no terceiro dia a limitação do WIP deu o sinal de alerta - chegou a 39%. Mesmo assim foram incluídos no WIP mais UDs nos dias correntes, sem muitas saídas. O resultado disso foi que o WIP extrapolou o limite pré-acordado e chegou a 68,4%.
Um outro ponto importante a ser observado é que já é possível ver onde há um gargalo no fluxo - os testes e os bloqueios já representam mais de 60% do WORK IN PROGRESS. Para complicar, mais uma UD foi incluída na sprint no oitavo dia, sem contestação do time de desenvolvimento. Como não poderia ser diferente, o backlog planejado da sprint não foi entregue.
Uma métrica que geralmente utilizo é o Delivery Variation Coeffitient (DVC), que nada mais é do que a medida de variação de entrega do time em termos de Unidades de Desenvolvimento (UDs). Quando a variação de entrega é muito alta indica que a cadência de desenvolvimento sustentável do time ainda não foi encontrada. O limite aceitável dessa variação geralmente é DVC <= 15%.
DesPad = Cálculo do desvio padrão das UDs planejadas nas últimas sprints;
Méd. Geométrica = Utilizamos a média geométrica para compensar grandes oscilações que possam ocorrer entre uma sprint e outra;
DVC = DesPad / Med. Geométrica
Outras métricas apoiam em tomadas de decisão importantes, tais como a Capacity de entrega do time (em termos de UDs). Conforme pode ser visto abaixo, nas ultimas 5 sprints o time planejou entregar, em média, aproximadamente 17 UDs. Porém a média de entregas não passou de 12 UDs por sprints.
Spill Over = quantidade média de UDs do sprint backlog que não foram entregues ao término da sprint.
Ao término da sprint XX todas as métricas foram apresentadas ao time, onde identificamos os gargalos e alinhamos ações para as lições aprendidas.
Na sprint posterior (Sprint XY) o time, já ciente das lições aprendidas com as métricas, resolveu encaixar o planejamento dentro da média de capacity planejada e entregue. O time entendeu que precisava absorver as UDs que estavam presas no WIP da sprint anterior e adicionar novas UDs, conforme direcionado pelo time de produto. No entanto limitamos a sprint em 16 UDs e aceitamos iniciar com o % de WIP maior do que o acordado (que é de 45%). Com o decorrer da sprint algumas ações para apoiar o time de QA foram feitas e conseguimos começar a dar vazão ao fluxo. A partir do quarto dia já estávamos com o percentual de trabalho no WIP em 37,5%, o que nos habilitou a puxar mais tasks para iniciarem no fluxo.
No fim todas as UDs foram entregues e os indicadores melhorados, conforme podemos ver abaixo:
No fim das contas as métricas são balizadores de ações e "moldam comportamentos" (vou ficar devendo a quem atribuir essa frase kkkk). É muito importante tratarmos esses dados e entendermos quando uma métrica pode fazer sentido e quando não. Mas o fato é que, quando o time está comprometido e engajado com as métricas por ele produzidas, é capaz de tomar melhores decisões e planejar melhor suas entregas.