Para onde vai o tempo da engenharia?

Alguém acima de mim perguntou quanto da engenharia vai para produto novo e quanto vai para manter as coisas funcionando. Quero uma resposta real, não uma sensação. ## Contexto - Escopo: [todos os squads | nomes dos squads] - Período: [últimos 90 dias], comparados com os 90 dias anteriores - Unidade: [issues | story points]. Se as duas estiverem disponíveis, rode as duas. - A divisão que a liderança acredita estar financiando: [desconhecida | por exemplo 70% roadmap, 30% todo o resto] - 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. Allocation — roadmap, não planejado, manutenção planejada, manutenção não planejada 2. Engineering Investment — coisas novas, melhorias, manter as luzes acesas, produtividade 3. Investment Profile — features, bugs, enhancements, hotfixes, others 4. Work Breakdown — código novo vs refactor vs retrabalho 5. Throughput — volume, só como contexto 6. Issue List resolvidas no período com issue_type bug e depois hotfix, ordenada por cycle time decrescente, limit 10 cada, campos key, summary, project, cycle_time_formatted. Esses são os maiores itens não planejados. ## Como analisar - Os três reports cortam o mesmo trabalho de formas diferentes. Allocation responde planejado vs não planejado (previsibilidade). Investment responde novo vs manter (estratégia). Profile conta tipos. Use cada um para a sua própria pergunta; nunca some os três. - Contar por issues dá peso demais a bugs pequenos. Contar por story points dá peso demais a features grandes. Se as duas unidades estiverem disponíveis, mostre as duas e diga qual fica mais perto do esforço para este time. - Não existe uma divisão universalmente certa. Um produto jovem com 70% de trabalho novo é normal, e uma plataforma madura com 40% também. O que importa é a distância entre a divisão real e a que a liderança acha que está pagando. - Trabalho não planejado acima de ~30% significa que o roadmap é um desejo. Descubra o que o alimenta: hotfixes e bugs são qualidade, "others" é trabalho que ninguém classificou. - Uma parcela grande sem classificação significa que parte do quadro está às cegas. Diga quanto, e não tire conclusões dessa parte. - Parcela de retrabalho subindo significa que estamos pagando duas vezes pela mesma feature. - Diferenças entre squads podem ser intencionais. Um squad de plataforma com 80% em manter as luzes acesas está fazendo o trabalho dele. - Torne tangível sem inventar custos: "de cada dez dias de engenharia, três vão para trabalho que ninguém planejou". ## Entregue Um documento de uma página com um gráfico: 1. **A resposta** — uma frase no formato "de cada dez dias de engenharia..." 2. **Gráfico** — barras empilhadas, período atual vs anterior, roadmap vs o resto 3. **O que alimenta o trabalho não planejado** — as cinco principais fontes ou itens, com evidência 4. **A distância** — divisão real vs a divisão que a liderança espera, em pontos 5. **Duas alavancas** — as duas mudanças com mais chance de devolver dez pontos ao roadmap, e quanto cada uma custa 6. **Confiança** — quanto do trabalho está sem classificação e o que corrigir no tracker antes da próxima leitura