Defendemos o uso de métricas há algum tempo, e já produzimos muito conteúdo sobre o assunto. No entanto, vemos times que usam métricas ativamente e não alcançam o resultado esperado.

Neste post, 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, você 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.

Para mais informações sobre como usá-las, dê uma olhada nesses posts:

• Cumulative Flow Diagrams e Lead Time Breakdown
• Throughput e gráfico de Burnup
• O que Lead Time fala sobre seu projeto

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 começamos a coletar 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á se formou. No caso de ter um padrão, você provavelmente já pode começar a usá-las e atuar em cima dos dados.

É importante notar também, 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. — Mais sobre como agir baseado em métricas pode ser encontrado em nossos blog posts.

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. Temos um post falando sobre isso também: Pros and cons of using daily metrics

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 com o 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 possível o processo, acabam medindo métricas de indivíduos. É praticamente impossível comparar 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 agora com o 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 que vejo. Pessoas tem 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 à 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 precesso.

11 – Tentar diminuir o lead time à 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? Deixe seus comentários abaixo!