Scorecard DORA vs benchmarks

Quero saber onde realmente estamos em DORA, qual das quatro métricas está nos segurando e o que fazer a respeito dela. ## Contexto - Escopo: [todos os squads | nome do squad] - Período: [últimos 90 dias], comparados com os 90 dias anteriores - Do que o negócio mais reclama: [nada específico | as coisas demoram demais | as coisas quebram | os dois] - Se eu deixei algo entre [colchetes], mantenha o que for um padrão (um período, um número de dias, a primeira de várias opções) e me pergunte o resto de uma vez só, antes de puxar qualquer dado. - Escreva tudo, inclusive o entregável, no idioma deste prompt. ## Puxe estes dados do DevStats (os dois períodos, mesmos filtros) 1. DORA Metrics — PR cycle time, deploy frequency, MTTR, change failure rate 2. Deploy — quantidade de deploys 3. Benchmarks — o tier de cada métrica 4. PR Cycle Time — quebra em coding / pickup / review / deploy 5. Code Review — tamanho médio dos PRs, PRs mergeados sem review ## Como analisar - As quatro métricas são dois pares: velocidade (lead time, deploy frequency) e estabilidade (change failure rate, MTTR). Leia como pares. Velocidade Elite com estabilidade baixa não é elite, é quebrar coisas rápido. - Um change failure rate de 0% ou um MTTR zero quase sempre significa que os incidentes não estão sendo registrados, não que nada falhou. Confira se existem dados de incidentes antes de comemorar, e diga com todas as letras se não existirem. - Deploy frequency é consequência do tamanho do lote. Se está baixa, olhe o tamanho dos PRs e a etapa de deploy do cycle time antes de pedir a alguém para "fazer mais deploys". - Para lead time, diga qual etapa é dona da maior parte dele. Pickup e review são hábitos do time. Deploy é pipeline e processo de release. Pedem correções diferentes. - Os tiers de benchmark são faixas largas. Um Medium que melhorou 30% é uma história melhor do que um High que está escorregando. Relate o movimento, depois o tier. - Não persiga Elite nas quatro. Escolha a métrica que limita o negócio: se a reclamação é lentidão, lead time; se é quebra, change failure rate. - Case as práticas com a evidência. PRs grandes pedem um limite de tamanho e fatias menores. Etapa de deploy longa pede trabalho no pipeline e feature flags. Failure rate alto pede testes nos caminhos que falharam e rollback automatizado. Não recomende uma prática que os dados não pedem. - Uma etapa que volta vazia em um dos períodos (deploy time é a mais comum) não foi medida; ela não levou zero tempo. Os totais dos dois períodos deixam de ser comparáveis: compare as etapas que os dois períodos têm, e diga isso. ## Entregue Um one-pager: 1. **Scorecard** — tabela: métrica, atual, anterior, variação, tier de benchmark e o que isso significa em uma linha 2. **Velocidade vs estabilidade** — duas frases sobre como os pares se leem juntos 3. **A que corrigir primeiro** — qual métrica, por que essa e o número a mirar no próximo trimestre 4. **Três práticas** — cada uma ligada à evidência que a pede, com o menor primeiro passo 5. **Ressalvas sobre os dados** — qualquer coisa ausente ou suspeita, especialmente os dados de incidentes