Qual squad precisa de ajuda?

Cuido de vários squads e a minha atenção é limitada. Quero saber qual squad está com dificuldade, em que tipo de problema ele está e que tipo de ajuda realmente funcionaria. ## Contexto - Squads: [todos os squads] (chame List Squads e depois List Players por squad para contar as pessoas, sem os bots) - Período: [últimos 90 dias], comparados com os 90 dias anteriores - O que eu posso oferecer: [nada ainda, só quero saber | o meu tempo | uma vaga | um investimento em plataforma ou ferramentas] - 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 (cada squad, os dois períodos, mesmos filtros) 1. PR Cycle Time com a quebra por etapa, e Throughput 2. DORA Metrics — deploy frequency, change failure rate, MTTR 3. Daily WIP, Aging Issues e Open PRs — o que está em andamento e o que está parado 4. Allocation — roadmap vs não planejado vs manutenção 5. Planning Accuracy — só para os squads que trabalham com sprints 6. Benchmarks ## Como analisar - Isto é triagem, não um ranking. Nunca produza uma tabela de classificação dos squads. - Um squad precisa de ajuda quando está piorando em relação a ele mesmo em duas ou mais dimensões ao mesmo tempo, ou quando ficou preso em um lugar ruim nos dois períodos. Uma métrica ruim é ruído. - Dê nome ao tipo de problema, porque cada um pede uma ajuda diferente: - Sobrecarga: WIP e aging subindo, throughput estável, parcela não planejada alta. Precisa de proteção e de menos escopo. - Atrito de fluxo: pickup e review longos, PRs abertos se acumulando. Precisa de ownership e de hábitos de review. - Instabilidade: failure rate ou MTTR subindo, hotfixes crescendo. Precisa de investimento em qualidade. - Planejamento: accuracy baixa, escopo mudando no meio da sprint. Precisa de uma conversa com produto. - Falta de trabalho: throughput e WIP caindo juntos com cycle time saudável. Não há trabalho pronto o suficiente. Isso é um problema de backlog, não de engenharia. - Contratar é a correção mais lenta e mais cara. Só a sobrecarga que durou os dois períodos e espremeu a parcela de roadmap justifica isso. Colocar mais gente em um squad com atrito de fluxo piora a situação: mais PRs na mesma fila de review. - Compare volume por pessoa, nunca totais brutos. Squads de três pessoas ou menos têm números ruidosos; diga isso. - Números ótimos com a maior parte do tempo em manutenção podem indicar um squad pouco desafiado. Sinalize. - Diga quais squads estão bem. A minha atenção também é uma interrupção. - 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. - 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. Diga isso em vez de comemorar. - Dois squads com números idênticos de PR, deploy ou DORA dividem um repositório, e o DevStats não consegue separá-los. Mostre esses números uma vez para a dupla, e diferencie os squads pelos relatórios baseados em issues (Allocation, Issue Cycle Time). ## Entregue Um documento de duas páginas no máximo. Se passar disso, corte linhas e frases, não seções: 1. **Tabela de triagem** — squad, estado (precisa de ajuda / observar / saudável), tipo de problema e os dois números por trás disso 2. **Squads que precisam de ajuda** — para cada um: o que está acontecendo em três frases, a ajuda que serve, a ajuda que sairia pela culatra e o primeiro passo 3. **Para onde vai a minha oferta** — qual squad a recebe, por quê e o que deve mudar em 60 dias se funcionar 4. **Perguntar antes** — as perguntas a fazer a cada engineering manager antes de agir 5. **Deixar em paz** — os squads que estão saudáveis, uma linha para cada