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

  1. 01

    Copie o prompt

    Preencha os campos entre [colchetes] ou deixe como estão: o assistente pergunta o que faltar.

  2. 02

    Cole no seu app de IA

    Claude, ChatGPT, Cursor ou o seu próprio app, conectado ao DevStats MCP. Configurar o MCP DevStats

  3. 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 exemplo
Puxado do DevStatsPlayersPR ListIssue ListCode ReviewPlayer MetricsPR Cycle Time
Mapa de risco + mitigação Baixar o exemplo
Mapa de risco + mitigação — Quem é um ponto único de falha?

Pare 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.