Como usar métricas sem cair na armadilha de otimizar o número em vez do resultado.
Em algum momento, depois de alguns sprints consistentes, os painéis começam a mostrar melhora nos indicadores operacionais. O lead time encurta, o backlog diminui, a disponibilidade da aplicação fica dentro do SLA (service level agreement) e o fechamento da sprint termina com sensação de avanço.
Aos poucos, porém, o sistema de incentivos muda o comportamento do time. A decomposição saudável, feita para reduzir incerteza, aprender cedo e entregar valor, vira uma técnica defensiva para reduzir exposição ao risco e evitar qualquer variação que possa “estragar o número”. Itens que exigem mudanças mais profundas passam a ser adiados porque “demoram demais”, correções estruturais são empurradas para fora do escopo, e decisões técnicas começam a priorizar previsibilidade do indicador em vez de valor entregue ao negócio.
O fluxo parece estável no gráfico, mas é frágil na prática. Entregas pequenas e de baixo impacto sistêmico atravessam o pipeline, enquanto causas-raiz, refactors necessários e riscos arquiteturais seguem acumulando e atravessando sprints sem dono. A métrica permanece correta, o sistema, não necessariamente. O resultado é um time progressivamente menos propenso a mudanças estruturais e uma operação que preserva indicadores, mas não reduz fragilidades técnicas.
Esse comportamento não exige coordenação central nem má-fé. Quando uma métrica se torna critério explícito de sucesso, ela passa a influenciar decisões locais em todos os níveis do sistema. Cada escolha isolada parece racional: reduzir escopo, evitar riscos, adiar trabalho estrutural. Individualmente, essas decisões aumentam a chance de “ir bem” no indicador, coletivamente, podem degradar a capacidade do sistema. O time aprende rapidamente quais decisões são mais fáceis de explicar (e de defender) quando o número está a seu favor. Com o tempo, o padrão se estabiliza e vira modo de operação.
Esse é o tipo de dinâmica descrita por Donella Meadows ao explicar como sistemas se reorganizam em torno dos sinais usados para controlá-los. Na prática, as pessoas continuam tentando fazer o trabalho, mas passam a operar dentro das novas regras de sobrevivência. A distorção não está no indicador em si, mas no papel que ele assume dentro do sistema social e na forma como é utilizado.
Nada disso invalida métricas como lead time, vazão ou MTTR (mean time to recovery). Elas continuam sendo instrumentos valiosos de alinhamento organizacional e observação de capacidade. O problema começa quando deixam de orientar investigação e passam a sustentar conclusões, quando deixam de provocar perguntas e passam a encerrar discussões, especialmente fora do time, sem contexto.
Lead time curto isoladamente não garante sistema estruturalmente estável. Vazão alta não implica arquitetura consistente. MTTR baixo mostra que o time reage rápido a falhas, mas não diz nada sobre o acúmulo de risco estrutural no sistema. Essas métricas são sinais incompletos por definição. Usá-las bem exige aceitar que mostram apenas parte da realidade e que, quando tratadas como prova de sucesso, simplificam decisões complexas demais para caberem em um gráfico.
É nesse ponto que a tensão fica explícita: decisões técnicas precisam ser explicadas para fora do time. Números são uma linguagem de fácil aceitação por reduzirem ambiguidade, acelerarem conversas e reforçarem a sensação de objetividade. O risco surge quando passam a decidir sozinhos, quando o gráfico deixa de ser insumo e vira argumento final.
Se métricas isoladas são insuficientes, o problema deixa de ser apenas como medi-las e passa a ser como gerimos engenharia.
“Métricas devem abrir a conversa e puxar investigação. Quando viram decisão descontextualizada, deixam de orientar e passam a distorcer.”
Retomando o pensamento da Donella Meadows, sistemas devem ser compreendidos a partir de seus padrões e interações ao longo do tempo, não apenas por eventos isolados. Para gestão de engenharia, métricas individuais são eventos. O comportamento emerge das relações.
A degradação raramente aparece em um número isolado, ela surge primeiro nas relações entre métricas.
Como compreender na prática
Considere um cenário concreto. O time decide melhorar o lead time reduzindo o tamanho médio das mudanças. Pull requests menores passam a ser incentivadas. O tempo de ciclo cai, a vazão aumenta levemente, a métrica melhora. Algumas semanas depois, a frequência de incidentes começa a subir. A integração entre mudanças se torna mais sensível. O MTTR, que mede o tempo necessário para restaurar o sistema após falha, permanece baixo. O time reage rápido, mas as ocorrências se tornam mais frequentes.
Isoladamente, cada indicador parece aceitável: entregas mais rápidas, sugeridas pelo leve aumento da vazão, boa capacidade de reação demonstrada pelo encurtamento do lead time. Mas, analisados em conjunto, revelam outro padrão. A fragmentação excessiva aumentou pontos de integração, elevou o acoplamento implícito e reduziu a visão sistêmica das alterações. O sistema não ficou mais resiliente, ficou apenas mais rápido para modificar e corrigir. Nenhum gráfico individual dispara alerta. A relação entre eles, sim. É ali, nas interações, que o sistema começa a revelar o que os números isolados escondem.
É nessa diferença que acompanhar métricas e entender o sistema deixam de ser a mesma coisa.
Como métricas devem ser vistas
A discussão, então, deixa de ser sobre quais métricas usar e passa a ser sobre como interpretá-las. Métricas não são instrumentos de controle, são instrumentos de aprendizado. Funcionam como termômetros: indicam variações, mas não explicam causas e, como todo termômetro, precisam ser analisadas em contexto.
Vazão baixa não significa automaticamente baixa produtividade. Pode indicar investimento em trabalho estrutural. Um lead time alto pode ser desorganização ou pode refletir mudança arquitetural profunda. O número não deve ser visto como resposta, mas como ponto de partida para investigação.
Toda métrica é uma projeção parcial de um sistema complexo. Ela mostra o efeito visível de decisões técnicas e organizacionais anteriores. Quando olhamos para uma métrica como se fosse a realidade, erramos o nível de análise. O número é consequência, a estrutura é a causa. Por isso, usar métricas com maturidade exige três deslocamentos mentais.
- Do número para a estrutura que o produz: Toda métrica é efeito, nunca causa. Quando um indicador se move, a pergunta relevante não é “como ajustamos o número?”, mas “que parte da estrutura está produzindo esse comportamento?”. Arquitetura, dependências, modelo organizacional e acoplamento são variáveis estruturais. O foco deve estar nelas.
- Do valor isolado para o padrão ao longo do tempo: Um ponto no gráfico pode ser apenas variabilidade natural. Reagir a cada oscilação cria instabilidade artificial. O que importa é padrão: tendência sustentada, mudança de inclinação, alteração de variabilidade ou divergência entre indicadores. Engenharia lida com comportamento sistêmico, não com eventos isolados.
- Da reação imediata para a investigação sistêmica: Quando um número se move, a reação instintiva é corrigir rapidamente. Agir sobre o sintoma pode piorar a causa. Antes de decidir, vale investigar:
- Isso é ruído ou mudança estrutural?
- Quais outros indicadores estão se movendo juntos?
- O que mudou recentemente na arquitetura ou no processo?
- Que tensão estrutural pode estar ocorrendo?
“Reagir ao número otimiza o indicador, investigar o sistema melhora a capacidade estrutural.”
As métricas fazem parte do sistema de feedback, e feedback molda o comportamento. Quando números são usados como veredito final, o sistema aprende a protegê-los. Quando são usados como instrumento de aprendizado, o sistema aprende a evoluir.
O papel da liderança técnica não é proteger métricas nem combatê-las. É garantir que sejam usadas como ferramenta de aprendizado sistêmico, não como atalho decisório. Medir é inevitável. Interpretar é responsabilidade. E evitar um dos erros mais custosos na engenharia exige deslocar o foco do efeito para a estrutura que o produz.
