Painéis de métricas se multiplicaram nas áreas de tecnologia. Jean Pierre Lessa e Santos Ferreira, diretor de tecnologia do Grupo Carrefour Brasil, nota que poucos deles mudam alguma decisão: o time olha o gráfico na reunião semanal, comenta a variação e volta a trabalhar do mesmo jeito.
O sintoma é conhecido. Pontos de história, linhas de código e horas apontadas viram assunto de comitê enquanto o prazo continua estourando e ninguém sabe dizer em que ponto o trabalho para. Medir virou hábito antes de virar método. A diferença entre um painel útil e um painel decorativo não está na ferramenta. Está no que se escolhe medir e no que se faz com o resultado.
Quando a métrica vira meta, o time aprende a burlá-la
Um time cobrado por pontos entregues por sprint aprende a inflar a estimativa em duas ou três semanas. Não há má-fé nisso: a régua premia certo comportamento, e o comportamento se ajusta à régua. É a lei de Goodhart aplicada ao desenvolvimento de software.
O efeito piora quando a medida é individual. Software é trabalho de sistema: uma entrega passa por revisão, teste, aprovação e implantação, e boa parte do tempo total é espera, não digitação. Medir a pessoa dentro de um fluxo lento apenas transfere a ela a culpa pela lentidão.
Jean Pierre Lessa e Santos Ferreira destaca que a pergunta inicial deveria ser outra: quanto tempo uma ideia leva para chegar ao usuário e quantas vezes ela volta no caminho. As duas respostas descrevem o fluxo, e nenhuma delas exige julgar quem escreveu o código.
As quatro medidas que descrevem o fluxo de entrega
Existe um conjunto consolidado para isso, popularizado pela pesquisa DORA: frequência de implantação, tempo entre a mudança no código e a produção, taxa de falha das alterações e tempo para restaurar o serviço após um incidente.
O valor está no par que essas medidas formam. As duas primeiras tratam de velocidade, as duas últimas de estabilidade, e olhar só metade produz uma decisão ruim. Dá para implantar dez vezes por dia, quebrando tudo, ou nunca falhar, entregando uma vez por trimestre.
A leitura de Jean Pierre Lessa e Santos Ferreira é que esses números funcionam melhor como termômetro de arquitetura do que de esforço. Tempo de ciclo alto costuma denunciar acoplamento, fila de aprovação ou ambiente de teste compartilhado, problemas que nenhum aumento de dedicação resolve.
Do painel à decisão: o que fazer com o número?
Toda métrica acompanhada deveria vir com uma hipótese escrita antes. Se o tempo de ciclo cair pela metade, o que se espera que aconteça com o retrabalho e com o prazo prometido? Sem essa frase, o painel não pode ser desmentido, e o que não pode ser desmentido não ensina nada.
Jean Pierre Lessa e Santos Ferreira sugere um teste antes de incluir qualquer indicador: se ninguém muda de decisão por causa daquele número, ele não é métrica, é relatório. Painel que apenas informa ocupa tempo de reunião e não devolve nada em troca.
Uma queda de entrega pode significar rotatividade ou sobrecarga, não falta de empenho. Modelos como o SPACE, proposto por pesquisadores de engenharia de software, combinam fluxo com satisfação, colaboração e eficiência percebida justamente porque o número sozinho não distingue essas causas.
O que nenhum painel mostra?
Nenhuma dessas medidas captura a decisão de arquitetura que vai cobrar caro daqui a dois anos. Débito assumido de propósito para lançar um produto aparece nos indicadores só depois de já ter custado muito, e nessa altura o gráfico registra o efeito, nunca a causa.
Por isso o número serve para começar a conversa, não para encerrá-la. Uma queda no tempo de restauração é um fato. Entender que ela veio de um alerta melhor, e não de mais gente de plantão, é o que permite repetir o resultado no trimestre seguinte.
Equipes que evoluem com métricas tratam o painel como instrumento de aprendizado coletivo. A pergunta deixa de ser quem produziu menos e passa a ser o que, no sistema de trabalho, impediu o time de entregar aquilo que havia se comprometido a entregar.
