Compartir Conocimiento en Equipos Dev | GitScrum
Crea sistemas para compartir conocimiento en equipos de desarrollo. Reduce silos, acelera onboarding y previene puntos únicos de fallo.
8 min de lectura
Acaparar conocimiento mata equipos. Cuando la información permanece en la cabeza de una persona, obtienes cuellos de botella, riesgo de bus factor y miembros del equipo frustrados. El compartir conocimiento sistemático hace a los equipos más resilientes, rápidos y felices.
Problemas de Conocimiento
| Problema | Consecuencia | Solución |
|---|---|---|
| Experto único | Cuello de botella + bus factor | Cross-training |
| Decisiones sin documentar | Debates repetidos | ADRs |
| Conocimiento tribal | Onboarding largo | Documentación |
| Silos de información | Esfuerzo duplicado | Sesiones de compartir |
| Contexto perdido | Malas decisiones | Logs de decisiones |
Sistemas de Documentación
Base de Conocimiento NoteVault
SETUP NOTEVAULT GITSCRUM
════════════════════════
ESTRUCTURA BASE DE CONOCIMIENTO:
─────────────────────────────────────
NoteVault/
├── 📁 Arquitectura
│ ├── Overview del Sistema
│ ├── Mapa de Servicios
│ ├── Flujo de Datos
│ └── ADRs/
│ ├── ADR-001: Usar PostgreSQL
│ ├── ADR-002: Microservicios
│ └── ADR-003: Auth JWT
│
├── 📁 Onboarding
│ ├── Comenzando
│ ├── Setup de Entorno de Dev
│ ├── Guía del Primer PR
│ └── Procesos del Equipo
│
├── 📁 Runbooks
│ ├── Guía de Deployment
│ ├── Respuesta a Incidentes
│ ├── Migraciones de Base de Datos
│ └── Procedimientos de Rollback
│
├── 📁 Servicios
│ ├── Servicio de Auth
│ ├── Servicio de Pagos
│ ├── Servicio de Notificaciones
│ └── API Gateway
│
└── 📁 How-To
├── Debuggear Issues de Producción
├── Configurar Entorno Local
├── Escribir Tests de Integración
└── Deploy a Staging
BUSCABLE, ENLAZADO, VERSIONADO
Registros de Decisiones
REGISTROS DE DECISIONES DE ARQUITECTURA (ADRs)
══════════════════════════════════════════════
TEMPLATE ADR:
─────────────────────────────────────
# ADR-005: Usar Redis para Almacenamiento de Sesiones
## Estado
Aceptado
## Fecha
2024-01-15
## Contexto
Necesitamos almacenar sesiones de usuario para el nuevo
sistema de autenticación. Opciones consideradas:
- PostgreSQL
- Redis
- En memoria (servidor único)
- JWT (stateless)
## Decisión
Usaremos Redis para almacenamiento de sesiones.
## Justificación
- Lecturas sub-milisegundo (lookup de sesión frecuente)
- TTL incorporado (sesiones expiran automáticamente)
- Ya en nuestro stack para caching
- Escalado horizontal via Redis Cluster
- Equipo tiene experiencia operacional
## Consecuencias
- Redis se convierte en infraestructura crítica
- Necesita monitoreo de Redis
- Pérdida de datos de sesión si Redis falla
- Aceptado: Recuperación rápida, sesiones recreadas
─────────────────────────────────────
BENEFICIOS:
├── Equipo futuro entiende "por qué"
├── Sin debates de arquitectura repetidos
├── Contexto de onboarding
├── Audit trail de evolución
└── Historial buscable
Prácticas de Compartir
Pair Programming
PAIR PROGRAMMING PARA TRANSFERENCIA DE CONOCIMIENTO
═══════════════════════════════════════════════════
CUÁNDO PAREAR:
├── Feature nuevo complejo
├── Área de codebase desconocida
├── Onboardeando nuevo miembro del equipo
├── Fix de producción fuera de horario (aprender)
├── Trabajo cross-domain (frontend + backend)
└── Cualquier momento con riesgo de concentración de conocimiento
PATRONES DE ROTACIÓN:
─────────────────────────────────────
Semana 1: Sarah + Mike (servicio de pagos)
Semana 2: Mike + Alex (pagos + auth)
Semana 3: Alex + Sarah (auth + frontend)
Semana 4: Nuevas combinaciones
Resultado: Conocimiento distribuido en el equipo
SESIONES DE PAIRING:
├── Driver: Escribe código
├── Navigator: Revisa, piensa adelante
├── Cambiar cada 25-30 minutos
├── Ambos aprenden del otro
└── Transferencia de conocimiento ocurre naturalmente
Sesiones Brown Bag
COMPARTIR CONOCIMIENTO BROWN BAG
════════════════════════════════
SESIONES SEMANALES:
─────────────────────────────────────
Cada Jueves, 12-1pm (almuerzo permitido)
TEMAS ROTAN:
├── Semana 1: "Cómo Funciona Nuestro Sistema de Pagos"
│ Presentador: Sarah (experta)
│ Audiencia: Todo el equipo
│
├── Semana 2: "Nuevas Features de TypeScript 5"
│ Presentador: Mike (aprendió recientemente)
│ Audiencia: Equipo frontend
│
├── Semana 3: "Debuggeando Issues de Producción"
│ Presentador: Alex (owner de incidente reciente)
│ Audiencia: Todo el equipo
│
├── Semana 4: "Mejores Prácticas de Diseño de API"
│ Presentador: Talk externo (YouTube)
│ Audiencia: Equipo backend
FORMATO:
├── 30-40 min presentación/demo
├── 15-20 min Q&A
├── Grabación para viewing async
├── Notas capturadas en NoteVault
└── Baja presión, alto valor
Code Reviews como Aprendizaje
CODE REVIEWS EDUCATIVOS
═══════════════════════
REVIEW = MOMENTO DE ENSEÑANZA
─────────────────────────────────────
En lugar de: "Cambia esto"
Di: "Considera X porque Y"
COMENTARIOS DE EJEMPLO:
─────────────────────────────────────
❌ "Usa Promise.all aquí"
✓ "Como estas llamadas API son independientes,
podemos ejecutarlas en paralelo con Promise.all.
Esto reduciría la latencia de ~600ms a ~200ms.
Aquí hay un ejemplo: [código snippet]"
─────────────────────────────────────
❌ "Patrón incorrecto"
✓ "Este es el patrón Repository, que funciona,
pero nuestro codebase usa el patrón Service.
Ver src/services/UserService.ts como ejemplo.
La diferencia: [explicación breve]"
ROTACIÓN DE REVIEWS:
├── Junior revisa código de senior (aprende patrones)
├── Senior revisa código de junior (enseña)
├── Reviews cross-domain (distribuye conocimiento)
└── Todos revisan = todos aprenden
Onboarding
Onboarding de Nuevo Miembro
TRANSFERENCIA DE CONOCIMIENTO EN ONBOARDING
════════════════════════════════════════════
SEMANA 1: Orientación
─────────────────────────────────────
Día 1:
├── Presentaciones del equipo
├── Leer: Doc de procesos del equipo
├── Setup: Entorno de dev (con buddy)
├── Primer PR: Arreglar typo (aprender workflow)
Día 2-3:
├── Sesión overview de arquitectura
├── Leer: Documentación del sistema
├── Parear: Con cada miembro del equipo (1hr cada uno)
├── Hacer preguntas en #dev-onboarding
Día 4-5:
├── Primera tarea pequeña (con mentor)
├── Walkthrough de code review
├── Walkthrough de deployment
└── Retro: ¿Qué está confuso?
SEMANA 2-4: Ramping Up
─────────────────────────────────────
├── Tareas progresivamente más grandes
├── Continuar pairing
├── Asistencia a brown bag
├── Comenzar a contribuir a docs
├── Preguntar libremente, sin vergüenza
DESPUÉS DE 1 MES:
├── Productivo en mayoría de tareas
├── Dar un brown bag (compartir perspectiva fresca)
├── Actualizar docs de onboarding (¿qué faltaba?)
└── Buddy para próximo nuevo contratado
Sistema de Buddy
SISTEMA DE BUDDY DE ONBOARDING
══════════════════════════════
RESPONSABILIDADES DEL BUDDY:
─────────────────────────────────────
├── Primer punto de contacto para preguntas
├── Parear en primeras tareas
├── Explicar reglas no escritas
├── Presentar a la cultura del equipo
├── Check-in diario primera semana
├── Check-in semanal primer mes
└── Handoff cuando esté cómodo
SELECCIÓN DE BUDDY:
├── Diferente del manager
├── 1-2 años en la empresa (recuerda onboarding)
├── Paciente y comunicativo
├── Disponible para preguntas
└── Rota por nuevo contratado
PREGUNTAS AL BUDDY:
├── "¿Quién sabe sobre X?"
├── "¿Por qué lo hacemos de esta manera?"
├── "¿Es esto normal?"
├── "¿Preguntas tontas OK?"
└── Sí, siempre OK
Preservación de Conocimiento
Previniendo Pérdida de Conocimiento
MITIGACIÓN DE BUS FACTOR
════════════════════════
IDENTIFICAR PUNTOS ÚNICOS DE FALLO:
─────────────────────────────────────
Evaluación de riesgo:
Servicio Experto Backup Acción
─────────────────────────────────────
Pagos Sarah ¡Ninguno! Cross-train
Auth Mike Alex Documentar
Data Pipeline Jordan ¡Ninguno! ¡Prioridad!
Frontend Emma, David OK Mantener
PLAN DE ACCIÓN:
─────────────────────────────────────
Alto Riesgo (sin backup):
├── Pagos: Sarah documenta + parea
├── Pipeline: Jordan graba walkthrough
├── Ambos: Programar transferencia de conocimiento
TIMELINE:
─────────────────────────────────────
├── Mes 1: Documentación crítica completada
├── Mes 2: Cross-training en progreso
├── Mes 3: Backup capabilities establecidas
└── Ongoing: Mantener documentación actualizada
Métricas de Compartir Conocimiento
Midiendo Éxito
MÉTRICAS DE COMPARTIR CONOCIMIENTO
══════════════════════════════════
MÉTRICAS CUANTITATIVAS:
├── Tiempo de onboarding a productividad
├── Bus factor por servicio
├── Páginas de documentación creadas/actualizadas
├── Sesiones de brown bag por mes
├── % code reviews con comentarios educativos
MÉTRICAS CUALITATIVAS:
├── Encuesta: "¿Puedes encontrar información que necesitas?"
├── Encuesta: "¿Te sientes cómodo haciendo preguntas?"
├── Retro: "¿Qué conocimiento está faltando?"
├── Feedback de nuevos contratados
INDICADORES DE SALUD:
├── ✓ Nadie es cuello de botella para información
├── ✓ Nuevos miembros productivos en < 1 mes
├── ✓ Documentación usada y referenciada
├── ✓ Preguntas se responden rápidamente
└── ✓ Conocimiento distribuido, no concentrado