7 min leitura • Guide 707 of 877
Conhecimento Se Perde Quando Membros do Time Saem
Saídas de time não deveriam significar saídas de conhecimento. O GitScrum ajuda a capturar conhecimento institucional através de recursos de documentação, histórico de tarefas e registros de decisões que preservam contexto independentemente de quem está no time.
Avaliação de Risco de Conhecimento
Tipos de Conhecimento
CATEGORIAS DE CONHECIMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CONHECIMENTO EXPLÍCITO (Mais fácil de capturar): │
│ • Código em si │
│ • Documentação escrita │
│ • Documentação de processos │
│ • Diagramas de arquitetura │
│ │
│ CONHECIMENTO TÁCITO (Mais difícil de capturar): │
│ • Por que decisões foram tomadas │
│ • Peculiaridades do sistema e workarounds │
│ • "Não faça isso porque..." │
│ • Contexto de relacionamentos │
│ • Contexto histórico │
│ │
│ CONHECIMENTO TRIBAL (Maior risco): │
│ • "Pergunta pro João, ele sabe" │
│ • Regras não escritas │
│ • Histórias de guerra sobre falhas passadas │
│ • Atalhos e truques │
│ │
│ ÁREAS DE ALTO RISCO: │
│ ☐ Áreas que só uma pessoa conhece │
│ ☐ Sistemas legados complexos │
│ ☐ Integrações customizadas │
│ ☐ Sistemas críticos de produção │
│ ☐ Relacionamentos chave com stakeholders │
└─────────────────────────────────────────────────────────────┘
Auditoria de Conhecimento
MAPEAMENTO DE CONHECIMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ VERIFICAÇÃO DE CONCENTRAÇÃO DE CONHECIMENTO: │
│ │
│ Sistema/Área │ Primário │ Backup │ Nível Risco │
│────────────────────────┼──────────┼────────┼──────────────│
│ Integração pagamento │ Alex │ Maria │ 🟢 Baixo │
│ Sistema faturamento │ Jordan │ - │ 🔴 Crítico │
│ Pipeline CI/CD │ Alex │ Jordan │ 🟢 Baixo │
│ Ferramenta import │ Maria │ - │ 🔴 Crítico │
│ API principal │ Time │ Time │ 🟢 Baixo │
│ │
│ VERIFICAÇÃO DO FATOR ÔNIBUS: │
│ "Se essa pessoa fosse atropelada, quão ruim seria?" │
│ │
│ • Fator ônibus = 1 → Risco crítico (uma pessoa sabe) │
│ • Fator ônibus = 2 → Risco moderado │
│ • Fator ônibus = 3+ → Risco menor │
│ │
│ RISCOS IDENTIFICADOS: │
│ • Jordan é única pessoa que conhece faturamento legado │
│ • Maria é dona de todo processo de importação │
│ │
│ PLANO DE MITIGAÇÃO: │
│ • Jordan: Documentar e parear com membro do time │
│ • Maria: Criar runbook e treinamento shadow │
└─────────────────────────────────────────────────────────────┘
Estratégias de Prevenção
Documentação Contínua
DOCUMENTAÇÃO-ENQUANTO-TRABALHA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ NÃO: Esperar até alguém sair para capturar conhecimento │
│ SIM: Capturar continuamente conforme trabalho acontece │
│ │
│ DOCUMENTAÇÃO BASEADA EM GATILHOS: │
│ │
│ Quando isso acontece... │ Criar/Atualizar isso... │
│────────────────────────────┼───────────────────────────────│
│ Decisão importante tomada │ Architecture Decision Record │
│ Incidente em produção │ Post-mortem + Runbook │
│ Novo processo introduzido │ Documentação do processo │
│ Integração construída │ Guia de integração │
│ Feature complexa feita │ Doc de visão geral da feature │
│ "Coisa estranha" descoberta│ Documento de gotchas/quirks │
│ │
│ EMBUTIDO NO WORKFLOW: │
│ • Code review: "Existe doc para isso?" │
│ • Fim de sprint: "O que deve ser documentado?" │
│ • Resolução de incidente: "Atualizamos o runbook?" │
│ │
│ BAIXA FRICÇÃO: │
│ • Usar templates │
│ • Aceitar "bom o suficiente" sobre perfeito │
│ • Qualquer doc é melhor que nenhum doc │
└─────────────────────────────────────────────────────────────┘
Treinamento Cruzado
DISTRIBUIÇÃO DE CONHECIMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ROTAÇÃO DE PAREAMENTO: │
│ │
│ Semana 1: Jordan ensina Maria sobre sistema de faturamento │
│ Semana 2: Maria ensina Jordan sobre ferramenta de import │
│ Semana 3: Alex ensina Carlos sobre pipeline CI/CD │
│ Semana 4: Carlos ensina Alex sobre monitoramento │
│ │
│ SHADOW TRAINING: │
│ ────────────── │
│ Quando trabalhar em área crítica: │
│ • Sempre ter alguém observando │
│ • Revezar quem lidera vs observa │
│ • Documentar enquanto faz │
│ │
│ CODE REVIEW COMO APRENDIZADO: │
│ ────────────────────────────── │
│ • Rotacionar reviewers │
│ • Explicar "por quê" não só "o quê" │
│ • Usar reviews para espalhar conhecimento │
│ │
│ BROWN BAGS / TECH TALKS: │
│ ─────────────────────── │
│ Quinzenal: Alguém apresenta algo que sabe │
│ • "Como funciona nosso sistema de pagamento" │
│ • "Por que escolhemos Kubernetes" │
│ • "Debugging da fila de mensagens" │
│ │
└─────────────────────────────────────────────────────────────┘
Processo de Offboarding
Transferência de Conhecimento
CHECKLIST DE SAÍDA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUANDO ALGUÉM ESTÁ SAINDO: │
│ │
│ SEMANA 1 (Aviso): │
│ ☐ Identificar áreas de conhecimento crítico │
│ ☐ Mapear o que só essa pessoa sabe │
│ ☐ Priorizar transferência de conhecimento │
│ ☐ Agendar sessões de documentação │
│ │
│ SEMANAS 2-3 (Transferência): │
│ ☐ Sessões de documentação gravadas │
│ ☐ Pareamento em sistemas críticos │
│ ☐ Atualizar/criar runbooks │
│ ☐ Documentar decisões pendentes │
│ ☐ Transferir relacionamentos com stakeholders │
│ │
│ ÚLTIMA SEMANA: │
│ ☐ Revisão de documentação criada │
│ ☐ Sessão de perguntas com o time │
│ ☐ Transferência de acessos/contas │
│ ☐ Contato para dúvidas futuras (se possível) │
│ │
│ IMPORTANTE: │
│ • Não espere o último dia │
│ • Grave sessões de transferência │
│ • Teste documentação com alguém que não conhece │
│ │
└─────────────────────────────────────────────────────────────┘
Template de Handoff
DOCUMENTO DE HANDOFF:
┌─────────────────────────────────────────────────────────────┐
│ │
│ # Handoff: [Nome da Pessoa] - [Data de Saída] │
│ │
│ ## Áreas de Responsabilidade │
│ 1. Sistema de Faturamento │
│ 2. Integração com Gateway X │
│ 3. Relacionamento com Cliente Y │
│ │
│ ## Documentação Criada/Atualizada │
│ ├── 📄 Runbook: Deploy do Faturamento │
│ ├── 📄 ADR-023: Por que usamos Gateway X │
│ ├── 📄 Guia: Troubleshooting Faturamento │
│ └── 📄 Contatos: Cliente Y │
│ │
│ ## Trabalho em Progresso │
│ • GS-456: Migração de API (70% completo) │
│ → Transferido para: Maria │
│ → Context: [link para doc de contexto] │
│ │
│ ## Conhecimento Transferido Para │
│ • Maria: Sistema de faturamento │
│ • Alex: Gateway X │
│ • Carlos: Relacionamento Cliente Y │
│ │
│ ## Contato Pós-Saída │
│ Email: jordan@email.com │
│ Disponível para dúvidas até: [data] │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Prevenção
CHECKLIST DE GESTÃO DE CONHECIMENTO
═══════════════════════════════════
PREVENÇÃO CONTÍNUA:
☐ Auditoria trimestral de fator ônibus
☐ Rotação de pareamento ativa
☐ ADRs para decisões importantes
☐ Runbooks para sistemas críticos
☐ Code reviews como aprendizado
☐ Sessões de conhecimento regulares
QUANDO ALGUÉM ANUNCIA SAÍDA:
☐ Mapear conhecimento único
☐ Priorizar transferência
☐ Agendar sessões de doc
☐ Identificar sucessores
☐ Criar documento de handoff
CULTURA:
☐ Valorizar documentação
☐ "Se não está documentado, não existe"
☐ Premiar compartilhamento
☐ Normalizar perguntas
☐ Gravar sessões importantes
Conhecimento preservado significa times resilientes que sobrevivem e prosperam através de mudanças de pessoal.