6 min lectura • Guide 703 of 877
El Conocimiento Se Pierde Cuando Miembros del Equipo Se Van
Las salidas del equipo no deberían significar salidas de conocimiento. GitScrum ayuda a capturar conocimiento institucional a través de features de documentación, historial de tareas y registros de decisiones que preservan contexto independientemente de quién esté en el equipo.
Evaluación de Riesgo de Conocimiento
Tipos de Conocimiento
CATEGORÍAS DE CONOCIMIENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CONOCIMIENTO EXPLÍCITO (Más fácil de capturar): │
│ • El código en sí │
│ • Documentación escrita │
│ • Documentación de procesos │
│ • Diagramas de arquitectura │
│ │
│ CONOCIMIENTO TÁCITO (Más difícil de capturar): │
│ • Por qué se tomaron decisiones │
│ • Quirks del sistema y workarounds │
│ • "No hagas esto porque..." │
│ • Contexto de relaciones │
│ • Contexto histórico │
│ │
│ CONOCIMIENTO TRIBAL (Mayor riesgo): │
│ • "Pregúntale a Sara, ella sabe" │
│ • Reglas no escritas │
│ • War stories sobre fallas pasadas │
│ • Atajos y trucos │
│ │
│ ÁREAS DE ALTO RIESGO: │
│ ☐ Áreas que solo una persona conoce │
│ ☐ Sistemas legacy complejos │
│ ☐ Integraciones custom │
│ ☐ Sistemas críticos de producción │
│ ☐ Relaciones clave con stakeholders │
└─────────────────────────────────────────────────────────────┘
Auditoría de Conocimiento
MAPEO DE CONOCIMIENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CHECK DE CONCENTRACIÓN DE CONOCIMIENTO: │
│ │
│ Sistema/Área │ Primario │ Backup │ Nivel Riesgo │
│────────────────────────┼──────────┼────────┼───────────────│
│ Integración de pagos │ Alex │ Maria │ 🟢 Bajo │
│ Sistema billing legacy │ Jordan │ - │ 🔴 Crítico │
│ Pipeline CI/CD │ Alex │ Jordan │ 🟢 Bajo │
│ Herramienta import clientes│Maria │ - │ 🔴 Crítico │
│ API principal │ Equipo │ Equipo │ 🟢 Bajo │
│ │
│ CHECK DE BUS FACTOR: │
│ "Si esta persona es atropellada por un bus, ¿qué tan mal sería?"│
│ │
│ • Bus factor = 1 → Riesgo crítico (una persona sabe) │
│ • Bus factor = 2 → Riesgo moderado │
│ • Bus factor = 3+ → Riesgo menor │
│ │
│ RIESGOS IDENTIFICADOS: │
│ • Jordan es la única persona que conoce billing legacy │
│ • Maria es owner de todo el proceso de import de clientes │
│ │
│ PLAN DE MITIGACIÓN: │
│ • Jordan: Documentar y parear con miembro del equipo │
│ • Maria: Crear runbook y capacitación shadow │
└─────────────────────────────────────────────────────────────┘
Estrategias de Prevención
Documentación Continua
DOCUMENTACIÓN-MIENTRAS-TRABAJAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ NO: Esperar hasta que alguien se vaya para capturar conocimiento│
│ SÍ: Capturar continuamente mientras el trabajo ocurre │
│ │
│ DOCUMENTACIÓN BASADA EN TRIGGERS: │
│ │
│ Cuando esto pasa... │ Crea/Actualiza esto... │
│──────────────────────────┼──────────────────────────────── │
│ Decisión mayor tomada │ Architecture Decision Record │
│ Incidente de producción │ Post-mortem + Runbook │
│ Nuevo proceso introducido│ Documentación de proceso │
│ Integración construida │ Guía de integración │
│ Feature compleja done │ Doc de overview de feature │
│ "Cosa rara" descubierta │ Documento de gotchas/quirks │
│ │
│ EMBEBIDO EN FLUJO DE TRABAJO: │
│ • Code review: "¿Hay un doc para esto?" │
│ • Completación de sprint: "¿Qué debe documentarse?" │
│ • Resolución de incidente: "¿Actualizamos el runbook?" │
│ │
│ BAJA FRICCIÓN: │
│ • Usa templates │
│ • Acepta "suficientemente bueno" sobre perfecto │
│ • Cualquier doc es mejor que ningún doc │
└─────────────────────────────────────────────────────────────┘
Cross-Training
DISTRIBUCIÓN DE CONOCIMIENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ROTACIÓN DE PAIRING: │
│ │
│ Semana 1: Jordan enseña a Maria sobre sistema billing │
│ Semana 2: Maria enseña a Jordan sobre herramienta import │
│ Semana 3: Alex enseña al equipo sobre integración de pagos │
│ │
│ OPCIONES DE FORMATO: │
│ │
│ Pairing (Mejor para conocimiento tácito): │
│ • Trabajar juntos en tareas reales │
│ • Explicar proceso de pensamiento │
│ • Sesiones de 2-4 horas │
│ │
│ Demo (Bueno para overview): │
│ • Mostrar cómo funciona el sistema │
│ • Responder preguntas │
│ • Grabar para referencia futura │
│ │
│ Code Review (Bueno para contexto): │
│ • Incluir contexto en descripciones de PR │
│ • Explicar por qué, no solo qué │
│ • Conocimiento se transfiere durante review │
│ │
│ OBJETIVO: Ningún punto único de falla para ningún sistema │
│ │
│ TRACKING: │
│ ☑ Jordan/Maria parearon en billing - 4 horas │
│ ☐ Maria/Jordan pairing en imports - programado próx semana │
│ ☑ Alex grabó walkthrough de integración de pagos │
└─────────────────────────────────────────────────────────────┘
Proceso de Salida
Transferencia de Conocimiento
TRANSFERENCIA DE CONOCIMIENTO EN SALIDA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CUANDO SE DA AVISO: │
│ │
│ SEMANA 1: INVENTARIO │
│ • Listar todos los sistemas/áreas que la persona posee │
│ • Identificar gaps en documentación │
│ • Priorizar qué debe transferirse │
│ • Programar sesiones de transferencia │
│ │
│ SEMANA 2-3: TRANSFERENCIA │
│ │
│ Sesiones de transferencia diarias: │
│ • Mañana: 1-2 horas pairing/demo │
│ • Tarde: Receptor practica, hace preguntas │
│ │
│ Creación de documentación: │
│ • Runbooks para procesos críticos │
│ • ADRs para decisiones no documentadas │
│ • Guías de troubleshooting │
│ • Lista de contactos/relaciones clave │
│ │
│ SEMANA FINAL: VERIFICACIÓN │
│ • Receptor demuestra capacidad │
│ • Gaps identificados y abordados │
│ • Documentación revisada y aprobada │
│ • Handoff formal completado │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Documenta continuamente no solo en salidas
- Identifica puntos únicos de falla temprano
- Rota pairing para distribuir conocimiento
- Usa templates para reducir fricción
- Cross-training regular como práctica del equipo
- Auditoría de conocimiento trimestral