Defendemos o uso de métricas há algum tempo. No entanto, vemos times as utilizarem ativamente e não alcançarem o resultado esperado.
Neste artigo, compilei os erros mais comuns que os times cometem quando usam métricas, assim você saberá o que evitar quando adotá-las.
1 – Não ter reação
Se você coleta métricas, precisa usá-las de alguma maneira. Portanto, um dos erros mais comuns é não reagir ao que as métricas apontam. Métricas podem lhe dar insights e, para reagir, você precisa entender como elas funcionam e o que significam.
2 – Usar métricas com poucos dados
Outro grande erro é utilizar métricas quando não existem dados suficientes para suportar suas conclusões. No começo de um projeto, ou quando se inicia a coletagem das métricas, geralmente ficamos ansiosos para melhorarmos nosso processo. No entanto, com uma quantidade baixa de dados, as métricas não são tão confiáveis.
Uma boa dica seria observar o comportamento dos dados e verificar se algum padrão já foi formado. No caso de ter um padrão, você provavelmente já pode começar a usá-las e atuar em cima dos dados.
É importante notar que esse não é o único método, mas em geral, eu esperaria no mínimo 3 semanas para começar a questionar o processo.
Uma possível saída, caso você tenha um projeto curto e precise de métricas o quanto antes, seria utilizar métricas diárias.
3 – Usar métricas sem considerar o contexto
Esse é um erro muito comum, não só no desenvolvimento de software, mas em toda conclusão construída estatisticamente. Números sozinhos são usados apenas em álgebra ou cálculo. Você precisa do contexto nos quais os números estão inseridos para entendê-los. Com isso em mente, para dizer se a vazão do seu projeto está saudável ou não, para entender se a variância do seu lead time é muito grande ou não, observe o contexto.
4 – Comparar métricas entre times
Esse problema está de certa forma relacionado ao 3. Não faz sentido falar algo como “time A está melhor que o time B pois eles têm uma vazão maior”. E se o time A possui 10 pessoas enquanto o time B possui 3? E se o time A trabalha com o desenvolvimento simples de um website e o time B com algum deep learning complexo? Tenha cuidado.
5 – Ter métricas individuais
Esse é um problema de microgerenciamento e está relacionado com os erros 3 e 4. Pessoas, tentando melhorar o máximo o processo, acabam medindo métricas de indivíduos. É praticamente impossível comparar as pessoas diferentes. Apenas não o faça. Se o fizer, estará afetando o ambiente do seu time e vai até diminuir a produtividade geral. Além disso, as métricas do processo devem ser usadas para entender a saúde do processo.
6 – Simplificar demais a leitura das métricas
Ainda relacionado ao contexto, mas ao contexto dos números. Por exemplo, se você comunica às outras pessoas que um time entrega em média 4 histórias por semana, é só isso, você não está dizendo nada do time. Talvez os dados sejam {0, 0, 0, 0, 0, 24}, talvez sejam {4, 4, 4, 4, 4, 4}. Então, tenha certeza que você não está simplificando demais a leitura das suas métricas e que todo o seu ferramental constrói a imagem que você está tentando desenhar.
7 – Usar apenas as métricas convenientes
Relacionado ao erro anterior, pessoas reportam as métricas para seus gerentes/diretores mostrando apenas os “números bons”. Então, se a vazão aumenta, você mostra apenas a vazão. Se o backlog diminui, você mostra apenas isso. Seja transparente. Caso contrário, eles estarão vivendo uma mentira e, quando a verdade vier à tona, você não conseguirá se explicar.
8 – Usar apenas os dados convenientes
Outro problema é usar apenas métricas com os dados que você quer. Recortar os dados para ter resultados mais relevantes, como considerar apenas os últimos 2 meses em um projeto de 10 meses, pode fazer sentido já que o contexto de um projeto muda com o tempo e você quer ter certeza que está considerando o contexto certo nos seus resultados. No entanto, tenha cuidado quando fizer isso, pois você pode estar escondendo muitas informações úteis de você mesmo.
9 – Falsificar métricas
Este é de longe o mais comum. Pessoas têm medo de mostrar os gargalos ou problemas e mascaram resultados (às vezes sem perceber). Agrupam histórias para diminuir backlog, quebram histórias desnecessariamente para aumentar a vazão ou até mesmo mudam pontos de história (quando os usam) para manter a velocidade do time constante. Com isso, você está apenas enganando você mesmo e não está melhorando o processo.
10 – Ter metas baseadas em métricas
Esse é um assunto muito polêmico. As métricas não foram feitas para serem metas. Foram feitas para ajudar o time a entender como o processo está e tentar melhorar o fluxo. Metas relacionadas a métricas podem colocar muita pressão no time e ter o efeito contrário ao desejado, fazendo com que o time cumpra uma métrica, mas desregule todo o processo. Então, antes de definir uma meta com base em métricas, pense se a meta precisa ser tão baixo-nível e, caso precise, confirme com o time se é possível, de fato, atingir essa meta ou se existe algum impedimento inerente ao processo.
11 – Tentar diminuir o lead time a todo custo
Lead time (LT) é uma métrica que serve para entendermos quanto tempo um item leva para passar por todo o processo. Então, existem duas perguntas que podem ser feitas aos dados:
- O LT está muito alto?
- A variância do LT está muito alta?
A segunda pergunta é muitas vezes mais importante para o time do que a primeira. Ter um LT com distribuição {0, 5, 2, 8} é geralmente pior do que ter uma como {4, 4, 4, 4}. Na primeira os dados não são confiáveis o suficiente para se ter uma predição assertiva, enquanto no segundo você tem maior probabilidade de acertar. No entanto, não esqueça de olhar para o seu contexto.
12 – Tentar aumentar a vazão ao invés de focar na eficácia
Ser eficaz é fazer a coisa certa. Vazão não é importante se você não está fazendo a coisa certa. Então, foque no seu produto, no que é melhor para ele, antes de se importar com o quão rápido você entrega.
O que achou desses erros? Já cometeu algum deles?
