6 min lectura • Guide 454 of 877
Creando Wikis de Proyecto en GitScrum
Los wikis de proyecto centralizan el conocimiento institucional que de otra manera viviría en documentos dispersos, hilos de Slack y las cabezas de las personas. NoteVault de GitScrum proporciona un sistema de documentación estructurado integrado directamente con tu gestión de proyectos, manteniendo la documentación cerca del trabajo que describe.
Problemas de Documentación que los Wikis Resuelven
| Problema | Impacto | Solución Wiki |
|---|---|---|
| Conocimiento en cabezas | Punto único de fallo | Documentación escrita |
| Docs dispersos | No se encuentra nada | Ubicación centralizada |
| Información desactualizada | Decisiones incorrectas | Procesos de revisión |
| Onboarding toma semanas | Productividad lenta | Guías autoservicio |
| Mismas preguntas repetidas | Pérdida de tiempo | FAQ buscable |
Template de Estructura de Wiki
ORGANIZACIÓN DEL WIKI DE PROYECTO
┌─────────────────────────────────────────────────┐
│ │
│ 📁 Comenzando │
│ ├── Overview del Proyecto │
│ ├── Equipo y Contactos │
│ ├── Guía de Inicio Rápido │
│ └── Configuración de Desarrollo │
│ │
│ 📁 Arquitectura │
│ ├── Overview del Sistema │
│ ├── Stack Tecnológico │
│ ├── Flujo de Datos │
│ └── Infraestructura │
│ │
│ 📁 Desarrollo │
│ ├── Estándares de Código │
│ ├── Workflow de Git │
│ ├── Proceso de Code Review │
│ └── Directrices de Testing │
│ │
│ 📁 Operaciones │
│ ├── Proceso de Deployment │
│ ├── Configuración de Entorno │
│ ├── Monitoreo y Alertas │
│ └── Respuesta a Incidentes │
│ │
│ 📁 Procesos │
│ ├── Ceremonias de Sprint │
│ ├── Proceso de Release │
│ ├── Rotación On-Call │
│ └── Guía de Comunicación │
│ │
│ 📁 Decisiones │
│ ├── ADR-001: Elección de Base de Datos │
│ ├── ADR-002: Arquitectura de API │
│ └── ADR-003: Estrategia de Auth │
│ │
└─────────────────────────────────────────────────┘
Templates de Páginas Esenciales
TEMPLATE GUÍA DE ONBOARDING
┌─────────────────────────────────────────────────┐
│ # Onboarding Nuevo Desarrollador │
│ │
│ ## Día 1 │
│ □ Obtener acceso a [sistemas] │
│ □ Clonar repositorios │
│ □ Ejecutar entorno local │
│ │
│ ## Semana 1 │
│ □ Completar primer bug fix │
│ □ Revisar docs de arquitectura │
│ □ Reunirse con miembros del equipo │
│ │
│ ## Mes 1 │
│ □ Lanzar primer feature │
│ □ Participar en on-call │
│ □ Contribuir a documentación │
└─────────────────────────────────────────────────┘
TEMPLATE RUNBOOK
┌─────────────────────────────────────────────────┐
│ # Runbook [Servicio] │
│ │
│ ## Overview │
│ Propósito, dependencias, owners │
│ │
│ ## Problemas Comunes │
│ | Síntoma | Causa | Resolución | │
│ │
│ ## Deployment │
│ Comandos paso a paso │
│ │
│ ## Rollback │
│ Procedimiento de rollback de emergencia │
│ │
│ ## Contactos │
│ Ruta de escalación │
└─────────────────────────────────────────────────┘
TEMPLATE REGISTRO DE DECISIÓN
┌─────────────────────────────────────────────────┐
│ # ADR-XXX: [Título] │
│ │
│ **Estado:** Propuesto/Aceptado/Superseded │
│ **Fecha:** YYYY-MM-DD │
│ │
│ ## Contexto │
│ ¿Qué problema estamos resolviendo? │
│ │
│ ## Decisión │
│ ¿Qué decidimos? │
│ │
│ ## Consecuencias │
│ ¿Cuáles son los trade-offs? │
└─────────────────────────────────────────────────┘
Configurando NoteVault para Wikis
Estructura Inicial
SETUP INICIAL DE WIKI
═════════════════════
PASO 1: Crear Estructura
─────────────────────────────────────
NoteVault → Nuevo Espacio → "Wiki del Proyecto"
Crear carpetas principales:
├── Comenzando
├── Arquitectura
├── Desarrollo
├── Operaciones
└── Procesos
PASO 2: Migrar Documentación Existente
─────────────────────────────────────
Identificar docs dispersos:
├── READMEs en repositorios
├── Docs de Google/Confluence
├── Mensajes de Slack fijados
├── Emails con procesos
└── Conocimiento en cabezas de personas
PASO 3: Asignar Ownership
─────────────────────────────────────
Cada sección → Owner dedicado
├── Arquitectura: @lead-backend
├── Operaciones: @devops
├── Desarrollo: @tech-lead
└── Procesos: @scrum-master
PASO 4: Establecer Calendario de Revisión
─────────────────────────────────────
Crear tarea recurrente trimestral:
"Revisar y actualizar wiki del proyecto"
Mejores Prácticas
Para Wikis de Proyecto
- Comenzar con onboarding — ROI más alto
- Mantener estructura superficial — Máximo 3 niveles de profundidad
- Usar templates — Para consistencia
- Asignar owners — A cada sección
- Fechar todas las páginas — Con última actualización
- Enlazar desde código — A docs relevantes
- Revisar trimestralmente — Para precisión
- Hacerlo buscable — Con buenos títulos
Anti-Patrones
ERRORES DE WIKI:
✗ Crear wiki pero nunca actualizar
✗ Duplicar información en múltiples lugares
✗ Sin ownership = sin accountability
✗ Estructura profundamente anidada que nadie puede navegar
✗ Títulos genéricos que no describen contenido
✗ Wiki como medio solo-escritura
✗ Información desactualizada marcada como actual
✗ Sin proceso de revisión regular
Dashboard de Wiki
MÉTRICAS DE WIKI
════════════════
SALUD DE DOCUMENTACIÓN:
┌─────────────────────────────────────────────────────────┐
│ Páginas totales: 47 │
│ Actualizadas (último mes): 23 (49%) │
│ Desactualizadas (>6 meses): 8 (17%) │
│ Sin owner: 5 (11%) │
├─────────────────────────────────────────────────────────┤
│ PÁGINAS MÁS VISITADAS: │
│ 1. Configuración de Desarrollo (342 vistas) │
│ 2. Proceso de Deployment (287 vistas) │
│ 3. Respuesta a Incidentes (201 vistas) │
├─────────────────────────────────────────────────────────┤
│ PÁGINAS QUE NECESITAN ATENCIÓN: │
│ ⚠ Guía de API - Última actualización hace 8 meses │
│ ⚠ Lista de Contactos - Sin owner │
│ ⚠ Legacy Auth - Marcada para deprecación │
└─────────────────────────────────────────────────────────┘