O trimestre em revisão, squad por squad

O trimestre está fechando. Preciso mostrar à liderança o que a engenharia entregou, squad por squad, e entrar no planejamento do próximo trimestre com um número de capacidade que eu consiga defender. ## Contexto - Trimestre: [início do trimestre até fim do trimestre], comparado com o trimestre anterior. Use as datas exatas dos dois. - Squads: [todos os squads] (chame List Squads, e List Players se for citar o tamanho de um squad, sem os bots) - Público: a liderança e os engineering managers. Isto alimenta o planejamento trimestral. - 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 e a organização inteira, os dois trimestres, mesmos filtros) 1. Throughput — PRs mergeados 2. PR Cycle Time com a quebra por etapa, e Issue Cycle Time 3. DORA Metrics — deploy frequency, change failure rate, MTTR 4. Allocation — roadmap vs não planejado vs manutenção 5. Investment Profile — features, bugs, enhancements, hotfixes 6. Sprints e Planning Accuracy — só para os squads que trabalham com sprints 7. Benchmarks do trimestre atual ## Como analisar - Um trimestre é longo o bastante para chamar algo de tendência. Faça isso, mas antes me pergunte se algum squad mudou de tamanho ou de escopo; um squad que perdeu duas pessoas não "ficou mais lento". - Compare primeiro cada squad com ele mesmo. Entre squads, compare só proporções (cycle time, failure rate, participação na allocation), nunca volume. Os squads diferem em tamanho e em tipo de trabalho. - Dê a cada squad uma linha que una dois sinais: "entregou mais, com um terço do tempo perdido em trabalho não planejado" diz mais do que seis métricas. - Leia velocidade e estabilidade juntas. Deploys subindo com failure rate subindo é velocidade comprada com risco. Cycle time caindo com failure rate estável é uma melhora real. - O número com que a liderança mais se importa é a parcela de roadmap. Se ela caiu, mostre exatamente para onde foi: trabalho não planejado, manutenção, bugs, hotfixes. - Bugs mais hotfixes crescendo de um trimestre para o outro significa que a dívida de qualidade está sendo paga com tempo de roadmap. - Relate o movimento entre tiers de benchmark, não o tier em si. Nunca ranqueie squads. - Transforme o trimestre em insumo de planejamento. Se 35% do tempo foi para trabalho não planejado, o roadmap do próximo trimestre deve ser planejado com 65% da capacidade, não com 100%. - 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 Uma apresentação (.pptx): 1. O trimestre em uma frase 2. Scorecard da organização — seis números, trimestre contra trimestre 3. Um slide por squad (cinco squads no máximo; além disso, os que mais se moveram): a história em uma linha, quatro números, um gráfico 4. Para onde foi o tempo — allocation, os dois trimestres, organização inteira 5. Velocidade vs estabilidade — quem melhorou de verdade e quem trocou uma pela outra 6. Três coisas que aprendemos 7. Próximo trimestre — a premissa de capacidade para planejar, duas apostas e um pedido Linguagem simples, um gráfico por slide, notas do apresentador com os números de apoio em todos os slides.