O que significa “qualidade orientada por métricas”
Qualidade orientada por métricas é uma forma de gerir e melhorar a qualidade de software usando dados observáveis e comparáveis ao longo do tempo, em vez de depender apenas de percepções, opiniões ou relatos pontuais. A ideia central é transformar sinais do dia a dia (bugs, tempo de ciclo, falhas em produção, retrabalho, complexidade, cobertura de testes, tempo de revisão, etc.) em indicadores que permitam tomar decisões com menor incerteza.
Isso não significa “gerir por números” de maneira cega. Métricas são instrumentos: ajudam a detectar tendências, priorizar melhorias e validar se uma mudança realmente funcionou. Qualidade orientada por métricas combina três elementos: (1) um objetivo de qualidade explícito, (2) uma forma consistente de medir o que se relaciona a esse objetivo, e (3) um ciclo de ação e aprendizado baseado nesses dados.
Um ponto importante: métricas de qualidade não se limitam a defeitos. Defeitos são um resultado (um sintoma). Métricas bem escolhidas ajudam a enxergar o processo que produz esse resultado. Por exemplo, se a taxa de incidentes aumenta, pode ser que o problema esteja em revisões apressadas, testes insuficientes, mudanças grandes demais por deploy, ou em requisitos instáveis. Métricas orientadas a processo ajudam a localizar onde atuar.
Por que métricas mudam a forma de enxergar qualidade
Sem métricas, é comum que a discussão sobre qualidade vire um debate de narrativas: “o sistema está instável”, “o time está lento”, “o QA está pegando demais”, “o dev não testa”. Com métricas, você consegue separar percepção de evidência. Isso reduz conflitos, melhora previsibilidade e cria um vocabulário comum entre engenharia, produto e operações.
Além disso, métricas permitem:
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
Detectar tendências: piora gradual de estabilidade, aumento de retrabalho, crescimento de tempo de ciclo.
Comparar o time consigo mesmo: antes e depois de uma mudança (ex.: novo padrão de revisão, testes automatizados, feature flags).
Priorizar melhorias: focar no gargalo mais caro (ex.: incidentes críticos vs. pequenos bugs de UI).
Evitar “otimização local”: melhorar uma etapa (ex.: velocidade de desenvolvimento) às custas de outra (ex.: estabilidade em produção).
Princípios essenciais para não transformar métricas em armadilhas
Métrica não é objetivo; objetivo é objetivo
Um erro comum é transformar a métrica em meta rígida e esquecer o objetivo real. Exemplo: “aumentar cobertura de testes para 90%” pode virar uma corrida por linhas cobertas, com testes frágeis e pouco úteis. O objetivo real pode ser “reduzir regressões em funcionalidades críticas”. A cobertura pode ser um meio, não o fim.
Uma métrica isolada raramente explica o fenômeno
Qualidade é multidimensional. Quase sempre você precisa de um conjunto pequeno de métricas complementares. Por exemplo, reduzir tempo de ciclo pode aumentar incidentes se o time estiver cortando validações. Então, ao acompanhar tempo de ciclo, acompanhe também indicadores de estabilidade (incidentes, rollback, falhas pós-deploy).
Defina claramente o que entra e o que não entra
Métricas precisam de definições operacionais. “Bug” significa o quê? Inclui melhoria? Inclui tarefa técnica? “Incidente” inclui alerta falso? “Tempo de ciclo” começa quando: no primeiro commit, no “in progress”, ou quando a tarefa é puxada? Sem definição, os números viram ruído.
Evite métricas que incentivem comportamento disfuncional
Se você mede “quantidade de bugs encontrados por pessoa”, você incentiva caça a bugs triviais ou, pior, cria competição. Se mede “número de commits”, incentiva commits pequenos sem valor. Prefira métricas de fluxo e resultado do sistema, não de performance individual.
Trate métricas como instrumentos de melhoria, não de punição
Quando as pessoas sentem que serão punidas por números, elas passam a “jogar o jogo”: reclassificar tickets, evitar registrar incidentes, adiar deploys para não “estragar” a estatística. A consequência é perda de confiança nos dados. A regra prática: métricas devem apoiar conversas e decisões, não servir como ranking.
Tipos de métricas em qualidade orientada por dados
Métricas de resultado (outcomes)
Medem o que o usuário e o negócio sentem. Exemplos: taxa de incidentes em produção, tempo de indisponibilidade, erros por requisição, taxa de crash, reclamações, churn por falha, NPS relacionado a estabilidade (quando disponível). São importantes, mas costumam ser tardias: quando pioram, o dano já ocorreu.
Métricas de processo (leading indicators)
Medem sinais anteriores ao problema. Exemplos: tamanho médio de mudança (linhas alteradas por PR), tempo de revisão, taxa de retrabalho (reabertura de tickets), flakiness de testes, frequência de deploy, tempo entre merge e deploy, taxa de rollback, proporção de mudanças sem testes automatizados, complexidade ciclomática em módulos críticos.
Métricas de fluxo
Medem como o trabalho atravessa o sistema. Exemplos: lead time, cycle time, WIP (trabalho em progresso), throughput, tempo em fila para revisão, tempo em fila para QA, tempo de espera por ambiente. Fluxo afeta qualidade porque filas e pressa aumentam risco: quanto mais tempo parado, mais contexto se perde; quanto mais correria no fim, mais atalhos aparecem.
Métricas de confiabilidade e operação
Medem robustez e capacidade de recuperação. Exemplos: tempo médio para detectar (MTTD), tempo médio para restaurar (MTTR), taxa de falhas por deploy, porcentagem de deploys com rollback, cobertura de monitoramento em endpoints críticos, taxa de alertas acionáveis vs. ruído.
Como escolher métricas: do objetivo ao indicador
Uma forma prática de escolher métricas é começar pela pergunta: “qual decisão queremos tomar com base nesses dados?”. Se você não consegue descrever a decisão, a métrica tende a virar curiosidade.
Exemplos de objetivos e decisões associadas:
Objetivo: reduzir regressões em produção. Decisões: aumentar testes automatizados em áreas críticas, reduzir tamanho de PR, reforçar checklist de revisão, adicionar feature flags.
Objetivo: diminuir tempo de recuperação de incidentes. Decisões: melhorar observabilidade, runbooks, automação de rollback, treinamento de on-call.
Objetivo: aumentar previsibilidade de entrega sem sacrificar estabilidade. Decisões: limitar WIP, ajustar política de branch/merge, melhorar refinamento, reduzir dependências externas.
Depois, selecione um conjunto pequeno (geralmente 5 a 10) de métricas que cubram: (1) resultado, (2) processo, (3) fluxo, e (4) confiabilidade. O conjunto deve ser suficiente para explicar “o que aconteceu” e “por que aconteceu”, sem virar um painel impossível de manter.
Passo a passo prático para implementar qualidade orientada por métricas
1) Defina o escopo e o sistema observado
Escolha um produto, serviço ou domínio específico. Evite começar “na empresa toda”. Defina também o período de observação (ex.: últimas 8 semanas) e o que será considerado dentro do sistema (ex.: backend X, app mobile Y, APIs públicas).
Exemplo de escopo: “API de pagamentos e seus deploys semanais”.
2) Declare objetivos de qualidade em linguagem operacional
Evite objetivos vagos como “melhorar qualidade”. Prefira algo observável:
Reduzir incidentes P1/P2 em 30% em 3 meses.
Reduzir retrabalho (tickets reabertos) de 18% para 10%.
Diminuir MTTR de 90 para 45 minutos em incidentes críticos.
Mesmo que você não “bata” o número, ele ajuda a calibrar esforço e acompanhar direção.
3) Faça um inventário de dados disponíveis e lacunas
Liste fontes e o que elas registram: repositório (PRs, commits), ferramenta de issues (status, datas), pipeline (builds, testes), observabilidade (erros, latência), incidentes (severidade, duração). Identifique lacunas: por exemplo, incidentes sem severidade padronizada, tickets sem data de início real, PRs sem link para issue.
Saída esperada: uma lista do tipo “temos / não temos / precisamos padronizar”.
4) Defina métricas com fórmulas e regras
Para cada métrica, escreva: nome, definição, fórmula, fonte, periodicidade, e como interpretar. Exemplos:
Taxa de incidentes por semana: número de incidentes P1/P2 abertos na semana. Fonte: registro de incidentes. Interpretação: tendência de estabilidade; não usar para culpar deploy específico sem análise.
Tempo de ciclo: data/hora de “in progress” até “done”. Fonte: issue tracker. Regra: pausar contagem quando “blocked” (se existir esse estado).
Tamanho de PR: linhas adicionadas + removidas. Fonte: Git. Interpretação: PRs grandes elevam risco e tempo de revisão.
Esse passo evita discussões futuras do tipo “mas eu achei que era diferente”.
5) Estabeleça uma linha de base (baseline)
Antes de mudar o processo, meça por algumas semanas para entender o comportamento atual. A baseline não precisa ser perfeita, mas deve ser consistente. Registre também eventos relevantes (ex.: pico sazonal, mudança de equipe, migração de infraestrutura) para contextualizar.
Exemplo: “baseline de 6 semanas mostrou média de 4 incidentes P1/P2 por semana, MTTR mediano de 70 minutos, PR mediano de 420 linhas alteradas”.
6) Crie um painel mínimo e uma rotina de leitura
Um painel mínimo pode ter:
2 métricas de resultado (ex.: incidentes P1/P2, erros 5xx por minuto)
2 métricas de processo (ex.: tamanho de PR, flakiness de testes)
2 métricas de fluxo (ex.: tempo de ciclo, WIP)
1 métrica de recuperação (ex.: MTTR)
Defina uma rotina: semanal para fluxo/processo e quinzenal/mensal para tendências de resultado (dependendo do volume). O ponto não é “olhar o painel”, e sim discutir ações: o que mudou, o que piorou, o que vamos testar.
7) Transforme métricas em hipóteses e experimentos
Quando uma métrica sinaliza problema, formule hipótese e teste uma intervenção pequena. Estrutura simples:
Sinal: PRs grandes e tempo de revisão alto.
Hipótese: PRs grandes aumentam tempo de revisão e elevam risco de regressão.
Experimento: limitar PRs a no máximo 300–400 linhas alteradas (com exceções justificadas) por 4 semanas.
Métricas de validação: tempo de revisão, taxa de rollback, incidentes pós-deploy, tempo de ciclo.
Se melhorar fluxo mas piorar estabilidade, ajuste a intervenção (ex.: reforçar testes em módulos críticos) em vez de “forçar” a métrica.
8) Padronize a classificação de defeitos e incidentes (quando aplicável)
Para conectar “bug” a indicador de processo, você precisa de consistência. Um padrão simples de classificação:
Severidade: impacto no usuário/negócio (P1, P2, P3…)
Tipo: regressão, falha de requisito, erro de integração, performance, segurança, dados
Origem provável: requisito, design, implementação, teste, configuração, dependência externa
Fase de detecção: antes do merge, em QA, em staging, em produção
Isso permite análises como: “regressões estão escapando para produção” ou “erros de configuração são recorrentes”.
9) Faça análise de causa com foco em sistema, não em pessoas
Quando houver incidentes relevantes, use os dados para entender padrões: mudanças grandes, horários de deploy, falta de testes, alertas tardios, dependências instáveis. O objetivo é ajustar o sistema de trabalho: checklists, automações, validações, limites de WIP, padrões de revisão.
Exemplo prático: se incidentes P1 ocorrem com frequência após deploys noturnos, uma ação pode ser mover deploys críticos para janelas com suporte, ou automatizar rollback e validações pós-deploy.
10) Reavalie o conjunto de métricas periodicamente
Quando o time amadurece, algumas métricas deixam de ser úteis e outras se tornam mais relevantes. Se a estabilidade melhorou, talvez o foco passe a ser previsibilidade. Se o fluxo está bom, talvez o foco passe a ser qualidade de requisitos e redução de retrabalho.
Exemplos práticos de leitura e ação a partir de métricas
Cenário A: incidentes sobem, mas tempo de ciclo cai
Leitura: o time está entregando mais rápido, porém com mais falhas. Isso sugere que a redução de tempo veio de cortes em validações, aumento de risco por mudança, ou pressão por entrega.
Ações possíveis:
Reduzir tamanho de PR e aumentar frequência de deploy (mudanças menores).
Definir checklist mínimo de revisão (ex.: casos de borda, migrações, flags).
Adicionar testes automatizados em rotas críticas e medir flakiness.
Cenário B: tempo de ciclo sobe, incidentes não mudam
Leitura: o time está mais lento sem ganho claro de estabilidade. Pode haver gargalo em revisão, QA, ambientes, dependências ou excesso de WIP.
Ações possíveis:
Medir tempo em fila por etapa (espera por review, espera por QA).
Limitar WIP e priorizar terminar antes de começar.
Automatizar validações repetitivas no pipeline.
Cenário C: poucos incidentes, mas muitos bugs reabertos
Leitura: talvez os defeitos estejam sendo detectados antes de produção (bom), mas a correção está incompleta, ou os critérios de aceite estão ambíguos.
Ações possíveis:
Reforçar critérios de aceite e exemplos de comportamento esperado.
Adicionar testes de regressão para bugs recorrentes.
Revisar padrões de validação (ex.: dados nulos, concorrência, permissões).
Como conectar “bug” a indicador de processo
Um bug isolado diz pouco. Um conjunto de bugs classificado e correlacionado com o fluxo revela oportunidades de melhoria. Um caminho prático:
Registrar para cada bug: severidade, tipo, módulo, fase de detecção e se é regressão.
Relacionar bugs a mudanças: PR/commit, release, feature flag.
Observar padrões: “70% dos bugs de dados vêm de migrações sem validação”, “regressões concentram-se em um módulo com alta complexidade”, “bugs de integração aumentam quando dependência externa muda”.
Com isso, você cria indicadores de processo, por exemplo:
Taxa de regressão: proporção de bugs classificados como regressão por release.
Escape rate: proporção de defeitos detectados em produção vs. antes de produção.
Defeitos por tipo: distribuição por categoria (integração, dados, UI, performance).
Esses indicadores orientam ações específicas: testes de contrato para integração, validações de migração, revisão de design para módulos complexos, ou melhoria de observabilidade para reduzir tempo de detecção.
Checklist de implementação (resumo operacional)
Escolher um escopo pequeno e um período de baseline.
Definir objetivos observáveis e decisões que as métricas suportarão.
Padronizar definições (bug, incidente, início/fim de ciclo).
Selecionar um conjunto enxuto de métricas (resultado, processo, fluxo, recuperação).
Criar painel mínimo e rotina de leitura com ações.
Rodar experimentos curtos e validar com múltiplas métricas.
Revisar periodicamente métricas e regras para manter utilidade.
Exemplo de especificação de métricas (modelo para copiar)
Objetivo: reduzir regressões em produção no serviço de pagamentos em 3 meses. Métrica 1 (resultado): Incidentes P1/P2 por semana - Definição: incidentes com impacto alto (P1/P2) abertos na semana - Fonte: registro de incidentes - Frequência: semanal - Interpretação: tendência de estabilidade; investigar picos Métrica 2 (processo): Taxa de regressão por release - Definição: bugs em produção classificados como regressão / total de bugs em produção - Fonte: issues + classificação - Frequência: por release - Interpretação: indica falha em validação de mudanças Métrica 3 (processo): Tamanho de PR (linhas alteradas) - Definição: adições + remoções por PR - Fonte: Git - Frequência: semanal (mediana e p90) - Interpretação: PRs grandes elevam risco e tempo de revisão Métrica 4 (fluxo): Tempo de revisão - Definição: abertura do PR até primeira aprovação - Fonte: Git - Frequência: semanal - Interpretação: gargalo de revisão; pode aumentar pressa no fim Métrica 5 (recuperação): MTTR P1/P2 - Definição: início do incidente até restauração do serviço - Fonte: incidentes/observabilidade - Frequência: mensal - Interpretação: capacidade de resposta e recuperação Experimento inicial (4 semanas): - Limitar PR a 400 linhas alteradas (exceções justificadas) - Checklist de revisão para mudanças em pagamentos - Meta de observação: reduzir p90 de tamanho de PR e tempo de revisão sem aumentar incidentes
