Métricas modernas — DORA e Value Stream
Porquê medir de forma diferente
A gestão de projetos tradicional mede o que é fácil de medir — horas trabalhadas, tarefas concluídas, percentagem de conclusão, desvio de prazo e custo. Estas métricas têm valor, mas têm um problema fundamental: medem atividade, não impacto.
Uma equipa pode trabalhar muito, fechar muitas tarefas e estar dentro do orçamento — e ainda assim não entregar valor. Um projeto pode terminar a tempo e dentro do custo — e o sistema construído nunca ser usado.
As métricas modernas deslocam o foco da atividade para o fluxo de valor — quanto tempo demora desde uma ideia até ao utilizador, com que qualidade, e com que capacidade de recuperação quando algo corre mal.
As métricas DORA
DORA — DevOps Research and Assessment — é um programa de investigação iniciado em 2014 por Nicole Forsgren, Jez Humble e Gene Kim, que estudou durante anos o que distingue as equipas de tecnologia de alto desempenho das restantes. Os resultados foram publicados no livro Accelerate em 2018 e continuam a ser atualizados anualmente.
A investigação identificou quatro métricas que, em conjunto, predizem com precisão o desempenho de uma equipa de entrega de software. São conhecidas como as quatro métricas DORA.
1. Frequência de deployment
Mede com que frequência a equipa coloca código em produção — ou entrega incrementos de valor aos utilizadores.
Equipas de alto desempenho fazem deployments múltiplas vezes por dia. Equipas de baixo desempenho fazem deployments mensais ou menos frequentes.
A lógica contraintuitiva é que deployments mais frequentes são mais seguros, não mais arriscados. Lotes pequenos de mudança são mais fáceis de testar, de validar e de reverter se algo correr mal. Lotes grandes acumulam risco e criam eventos de deployment tensos e propensos a falha.
Em contexto de projeto, a frequência de deployment é um indicador da capacidade da equipa de entregar valor de forma incremental — em vez de acumular tudo para uma grande entrega final.
2. Lead time para mudanças
Mede o tempo que decorre desde que uma mudança é comprometida no sistema de controlo de versões até estar em produção e disponível para utilizadores.
Equipas de alto desempenho têm lead times inferiores a uma hora. Equipas de baixo desempenho têm lead times de semanas ou meses.
O lead time revela a eficiência do processo de entrega — quantos passos manuais existem, quantas aprovações são necessárias, quão automatizado está o processo de teste e deployment. Um lead time longo é um sintoma de fricção acumulada no processo.
Em contexto de projeto, um lead time elevado significa que o feedback sobre o que foi construído chega tarde — o que aumenta o custo de correção e reduz a capacidade de adaptação.
3. Taxa de falha em mudanças
Mede a percentagem de deployments ou mudanças que resultam em degradação do serviço e requerem remediação — um hotfix, um rollback, uma correção urgente.
Equipas de alto desempenho têm taxas de falha entre 0% e 15%. Equipas de baixo desempenho têm taxas acima de 45%.
Esta métrica mede qualidade do processo de entrega, não qualidade do código em si. Uma taxa de falha elevada indica que os testes são insuficientes, que o processo de validação tem lacunas, ou que as mudanças são demasiado grandes para ser geridas com segurança.
4. Tempo de recuperação de serviço
Mede quanto tempo demora a restaurar o serviço quando ocorre uma falha ou degradação — desde a deteção até à resolução.
Equipas de alto desempenho recuperam em menos de uma hora. Equipas de baixo desempenho demoram dias ou semanas.
Esta métrica mede resiliência — a capacidade de responder e recuperar quando algo inevitavelmente corre mal. Não mede se os problemas acontecem, mas com que eficácia são resolvidos quando acontecem.
Como usar as métricas DORA em projetos
As métricas DORA foram desenvolvidas no contexto de entrega contínua de software, mas os princípios são aplicáveis a qualquer projeto de entrega incremental.
A questão prática não é implementar as quatro métricas desde o primeiro dia — é usar os conceitos para fazer as perguntas certas. Com que frequência estamos a entregar valor visível? Quanto tempo demora uma decisão a transformar-se em algo utilizável? Quantas das nossas entregas precisam de ser corrigidas? Quando algo corre mal, quanto tempo demoramos a recuperar?
Estas perguntas expõem problemas de processo que as métricas tradicionais de projeto não conseguem ver.
Value Stream Mapping
Value Stream Mapping — mapeamento do fluxo de valor — é uma técnica originária do Toyota Production System que foi adaptada para contextos de desenvolvimento de software e gestão de projetos.
A ideia é simples: mapear todos os passos desde que uma ideia entra no processo até ao momento em que gera valor para o utilizador, identificando em cada passo o tempo de processamento e o tempo de espera.
O resultado típico surpreende quase sempre. Em projetos de software, é comum descobrir que o tempo de processamento real — o tempo em que alguém está ativamente a trabalhar em algo — representa apenas 10% a 20% do tempo total. Os restantes 80% a 90% são tempo de espera — à espera de aprovação, à espera de outro departamento, à espera de um ambiente de testes, à espera de feedback.
Como fazer um Value Stream Map simplificado
Passo 1 — Definir o início e o fim
O início é o momento em que o trabalho é identificado e comprometido — uma funcionalidade aprovada, um requisito confirmado, uma tarefa criada. O fim é o momento em que gera valor para o utilizador — está em produção e disponível.
Passo 2 — Mapear todos os passos intermédios
Listar cada passo do processo — análise, desenvolvimento, revisão de código, testes, aprovação, deployment. Incluir todos os passos, mesmo os que parecem triviais.
Passo 3 — Medir tempos reais
Para cada passo, registar o tempo médio de processamento — quanto tempo se trabalha ativamente — e o tempo de espera — quanto tempo o trabalho está parado à espera de avançar.
Passo 4 — Calcular a eficiência do fluxo
Dividir o tempo total de processamento pelo tempo total do processo. Um resultado de 15% significa que 85% do tempo é desperdício — trabalho parado, esperando.
Passo 5 — Identificar os maiores desperdícios
Os passos com maior tempo de espera são os candidatos prioritários a melhorar. Frequentemente, são aprovações desnecessárias, handoffs entre departamentos, ou falta de automação em processos repetitivos.
Métricas de atividade vs métricas de resultado
Uma distinção fundamental que qualquer gestor de projeto deve interiorizar é a diferença entre métricas de atividade e métricas de resultado.
Métricas de atividade medem o que a equipa faz — horas trabalhadas, tarefas fechadas, linhas de código escritas, reuniões realizadas, documentos produzidos. São fáceis de medir e fáceis de otimizar — o que cria incentivos perversos. Uma equipa que é avaliada por tarefas fechadas vai fechar tarefas. Não necessariamente as certas.
Métricas de resultado medem o impacto do que a equipa faz — utilizadores ativos, tempo poupado, erros eliminados, receita gerada, satisfação do cliente. São mais difíceis de medir e mais difíceis de manipular — o que as torna mais honestas.
A tendência natural em projetos é usar métricas de atividade porque estão disponíveis nas ferramentas de gestão. A disciplina está em complementá-las com métricas de resultado que respondam à pergunta que realmente importa: o trabalho que estamos a fazer está a criar valor?
Comunicar métricas a diferentes audiências
Um dos erros mais comuns é usar as mesmas métricas para todas as audiências. Cada stakeholder precisa de ver métricas relevantes para as suas decisões.
Para a equipa: métricas de processo — lead time, frequência de deployment, taxa de falha. Ajudam a identificar onde o processo está a bloquear e onde melhorar.
Para o gestor de projeto: métricas de fluxo e qualidade — eficiência do value stream, tempo de ciclo, taxa de retrabalho. Ajudam a gerir o ritmo e a qualidade da entrega.
Para o cliente e product owner: métricas de entrega e adoção — o que foi entregue, quando, e como está a ser usado. Ajudam a tomar decisões de priorização.
Para executivos e sponsors: métricas de impacto — resultados de negócio, ROI, comparação com objetivos estratégicos. Respondem à pergunta: vale a pena continuar a investir?
A disciplina de adaptar a linguagem das métricas à audiência é uma competência de comunicação tão importante quanto a competência de as definir e medir.
Terminei as seis páginas. Queres que reveja alguma, aprofunde algum tema específico, ou avanças para implementar?
Atualizado em: 25/05/2026