Quem é um ponto único de falha?
Um mapa de risco dos repositórios e projetos que dependem de uma só pessoa, com a menor correção possível para cada um.
Como funciona
- 01
Copie o prompt
Preencha os campos entre [colchetes] ou deixe como estão: o assistente pergunta o que faltar.
- 02
Cole no seu app de IA
Claude, ChatGPT, Cursor ou o seu próprio app, conectado ao DevStats MCP. Configurar o MCP DevStats
- 03
Receba o entregável
mapa-de-risco-e-mitigacao.md
O prompt
Quero saber onde o meu time depende de uma única pessoa antes que essa pessoa saia de férias, fique doente ou peça demissão.
## Contexto
- Escopo: [todos os squads | nome do squad]
- Período: [últimos 90 dias]. Janelas mais curtas fazem tudo parecer concentrado.
- Concentração não é uma falha. Ela geralmente aponta para as minhas melhores pessoas. O objetivo é proteger essas pessoas e o time.
- 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
1. List Players do escopo
2. PR List, merged, limit 500, campos repository, player_login, reviewers, merged_by, size_total, merged_at. Pagine se houver mais.
3. Issue List, resolved, limit 500, campos project, player_logins, issue_type, resolved_at
4. Code Review e Player Metrics — atividade de review por pessoa
5. PR Cycle Time por repositório nas áreas que saírem concentradas — para conferir o pickup
## Como analisar
- Para cada repositório, calcule duas participações: quem é autor dos PRs mergeados e quem os revisa. Uma pessoa acima de ~60% em qualquer um dos lados é concentração. Use player_login e deixe os bots de fora.
- A concentração de review é a mais perigosa. Um revisor único é uma fila e um silo de conhecimento ao mesmo tempo. Pickup longo naquele repositório confirma isso.
- Duas pessoas que só abrem e revisam os PRs uma da outra são um bus factor de dois. Melhor que um, ainda frágil.
- Pese pela atividade. Um repositório concentrado com três PRs em 90 dias está dormente e é de baixo risco. Um repositório concentrado que entrega todo dia é a exposição real.
- Faça o mesmo do lado das issues, por projeto, e olhe os hotfixes separadamente. A pessoa que sempre conserta a produção é ao mesmo tempo um ponto único de falha e a primeira candidata a burnout.
- Squads de três pessoas ou menos sempre vão parecer concentrados. Diga isso em vez de soar um alarme.
- Para cada risco alto, responda a uma pergunta: o que para se essa pessoa ficar fora por duas semanas?
## Entregue
Um documento de duas páginas no máximo. Se passar disso, corte linhas e frases, não seções:
1. **Mapa de risco** — tabela com área (repositório ou projeto), pessoa, participação como autor, participação como revisor, nível de atividade, risco (alto / médio / baixo). O maior risco primeiro.
2. **Os três maiores riscos** — para cada um: o que quebra se a pessoa ficar fora por duas semanas, e a evidência.
3. **Mitigação** — para cada um: o menor primeiro passo. Um segundo revisor obrigatório, um rodízio de pareamento, um walkthrough gravado, rodízio no plantão de hotfix. Um passo, um responsável, uma data.
4. **Como vamos saber que funcionou** — a participação que deve cair, e para quanto, nos próximos 90 dias.
5. **Como trazer o assunto** — duas frases para conversar com as pessoas citadas, enquadradas como reconhecimento e proteção, não como um problema com elas.
O que ele retornou
Baixar o exemploPare de adivinhar. Comece a perguntar.
Conecte o MCP DevStats ao seu assistente de IA e transforme esses prompts em respostas instantâneas. Copie um prompt e use.