Gestiona el conocimiento técnico del equipo de ingeniería: el wiki técnico, los ADRs y las prácticas de documentación que evitan que el conocimiento viva solo en la cabeza de los developers más antiguos.
Cuándo usarlo: Implementar gestión del conocimiento técnico en un equipo de ingeniería
Herramienta recomendada: Claude
Eres un experto en gestión del conocimiento técnico para equipos de ingeniería de software. Quiero que me ayudes a construir el sistema que captura las decisiones arquitectónicas, los procesos técnicos y el know-how del equipo para que no dependa de las personas que llevan más tiempo. Mi contexto: - Tamaño del equipo de ingeniería: [número de developers y roles] - Stack tecnológico: [lenguajes, frameworks, infraestructura] - Problema principal: [bus factor alto, onboarding lento, decisiones que nadie recuerda por qué se tomaron, docs desactualizados] - Herramientas de documentación actuales: [Confluence, Notion, GitHub Wiki, Readme.io, nada organizado] - Madurez del equipo en documentación: [startups sin docs, empresa con docs desactualizados, intentos fallidos previos] Con esa información, quiero que me entregues: 1. ARCHITECTURE DECISION RECORDS (ADRs): DOCUMENTAR EL POR QUÉ Explica qué son los ADRs, por qué son la pieza más valiosa de conocimiento técnico que un equipo puede documentar y cómo implementarlos: el formato estándar de un ADR (contexto, decisión, consecuencias, alternativas consideradas), dónde almacenarlos (en el repositorio de código, en el wiki), cómo integrarlos en el proceso de diseño técnico y cómo hacer que el equipo los escriba antes de la implementación, no después. Dame una plantilla de ADR completa y un ejemplo ficticio para una decisión de base de datos. 2. EL WIKI TÉCNICO: ESTRUCTURA Y GOBIERNO Diseña la estructura de un wiki técnico que funcione de verdad: la jerarquía de secciones (arquitectura del sistema, runbooks de operaciones, guías de desarrollo, onboarding, decisiones tomadas), las convenciones de nombrado y etiquetado que facilitan la búsqueda, el proceso de revisión para que el contenido no quede desactualizado y quién es responsable de qué sección. Explica la diferencia entre documentación evergreen y documentación temporal y cómo gestionar cada tipo. 3. RUNBOOKS Y PLAYBOOKS OPERACIONALES Explica cómo construir runbooks que el equipo realmente use en producción: el formato de un runbook de incidente (síntoma, diagnóstico, solución paso a paso, rollback), cómo mantenerlos actualizados después de cada incidente, cómo integrarlos en el alerting para que aparezcan cuando hacen falta y cómo cubrir los escenarios de on-call para que cualquier miembro del equipo pueda resolver los incidentes más comunes sin llamar al experto. 4. ONBOARDING TÉCNICO: DE CERO A PRODUCTIVO EN 30 DÍAS Diseña el plan de onboarding técnico para un nuevo developer: el roadmap de los primeros 30 días (arquitectura del sistema, entorno de desarrollo, primer PR, primera tarea de producción), los documentos que debe leer y en qué orden, las personas con quienes debe hablar y para qué, y el buddy system que garantiza que el nuevo miembro tiene a alguien a quien preguntar sin molestar a todo el equipo. Dame un template de plan de onboarding técnico de 30 días. 5. KNOWLEDGE SHARING RITUALS: LOS HÁBITOS DE UN EQUIPO QUE APRENDE Define los rituales de equipo que convierten el conocimiento individual en conocimiento colectivo: el tech talk interno (frecuencia, formato, quién participa), el postmortem sin culpa (estructura, facilitación, documentación de aprendizajes), el pair programming como herramienta de transferencia de conocimiento y el código review como mecanismo de aprendizaje mutuo. Explica cómo institucionalizar estos rituales sin que se conviertan en reuniones vacías. 6. MEDIR EL BUS FACTOR Y REDUCIRLO Explica cómo medir el bus factor del equipo: cómo identificar los cuellos de botella de conocimiento (las áreas del sistema que solo entiende una persona), cómo usar el análisis de código (git log, code ownership) para objetivizar el riesgo y cómo diseñar un plan de reducción del bus factor mediante rotación deliberada, documentación dirigida y pair programming en las áreas críticas. Termina con un plan de implementación priorizado para los primeros 60 días: qué construir primero para reducir el riesgo inmediato y qué construir en el segundo mes para crear un sistema sostenible a largo plazo.