5.4Documentación y procedimientos de TI
Lo esencial en 30 segundos
- Un saber guardado «en la cabeza» es un riesgo: ausencia, baja, olvido — y la actividad se bloquea por falta de alguien que sepa.
- Tres formas útiles: procedimiento (cómo hacer), runbook (qué hacer en caso de avería), base de conocimiento (soluciones capitalizadas).
- Una buena documentación está viva: al día, localizable y accionable — si no, induce a error.
Mini-caso hilado — Sofiane escribe un runbook antes de sus vacaciones
Sofiane, técnico de soporte en una pyme de distribución en Argel, es el único que sabe reiniciar el servidor de archivos cuando se cuelga. Pronto se va de vacaciones y no quiere dejar al equipo en pánico. Aplica el enfoque de la sección: escribe un runbook «el servidor de archivos no responde», con pasos precisos y en orden, comprensibles para un compañero no experto. Lo hace probar por otro técnico: allí donde este se atasca, corrige la documentación. Guarda el runbook en un sitio localizable, anota la fecha de actualización y reduce así la dependencia de una sola persona.
Caso autónomo de esta sección: reaparece en el curso, el esquema, el script y el reto de 48 h de la sección 5.4.
1. El saber en la cabeza = un riesgo
Cuando una operación solo existe «en la cabeza» de una persona, la empresa depende de ella: ausencia, baja, olvido, y llega el bloqueo. Documentar convierte un saber personal en saber compartido. Sofiane lo vive: único en saber reiniciar el servidor de archivos, prepara a los demás. No es papeleo — es continuidad, calidad y tiempo ahorrado.
2. Procedimientos, runbooks, base de conocimiento
Tres formas útiles. El procedimiento describe cómo realizar una operación (instalar un puesto, crear una cuenta). El runbook es una pauta precisa para una situación dada, a menudo una avería («qué hacer si el servidor X no responde»). La base de conocimiento capitaliza las soluciones a problemas ya encontrados, reutilizables por todo el equipo y a veces por los usuarios. Sofiane combina las tres según las necesidades.
3. Una buena documentación está viva
Una documentación útil está al día, es localizable y accionable: pasos claros, probados, que otra persona pueda seguir sin ti. Se actualiza cuando cambia la realidad — si no, induce a error — y se escribe para el lector, no para uno mismo. Documentar sobre la marcha cuesta poco; reconstruir después cuesta caro. Sofiane anota sistemáticamente la fecha de actualización.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — El compañero de vacaciones
Sofiane imagina la avería del servidor de archivos durante su ausencia:
Sin runbook: bloqueo hasta su vuelta, o tanteos arriesgados
Con runbook «El servidor de archivos no responde»:
pasos probados → un compañero restablece el servicio en 20 minLectura: el runbook hace al equipo autosuficiente frente a la avería.
Lección: documentar es no depender de una sola persona.
Vocabulario de la sección
- Procedimiento
- Descripción paso a paso de una operación que realizar.
Ejemplo sencillo: Sofiane documenta la creación de una cuenta de usuario.
Lo que no es: una explicación vaga dejada de viva voz.
Reflejo: procedimiento = cómo hacer.
- Runbook
- Pauta precisa para una situación dada (a menudo una avería).
Ejemplo sencillo: El runbook «el servidor de archivos no responde» de Sofiane.
Lo que no es: improvisar cuando surge la avería.
Reflejo: runbook = qué hacer en caso de avería.
- Base de conocimiento
- Recopilación reutilizable de soluciones a problemas ya encontrados.
Ejemplo sencillo: Sofiane anota allí las soluciones encontradas para el equipo.
Lo que no es: resolver el mismo incidente diez veces desde cero.
Reflejo: capitalizar las soluciones.
- Documentación viva
- Documentación al día, localizable y accionable, actualizada cuando cambia la realidad.
Ejemplo sencillo: Sofiane fecha cada documento y lo corrige tras probarlo.
Lo que no es: un documento nunca actualizado que engaña.
Reflejo: al día, localizable, accionable.
- Factor autobús (bus factor)
- Número de personas que, si faltaran, bloquearían la actividad; la documentación lo eleva.
Ejemplo sencillo: Sofiane eleva el factor autobús compartiendo su saber.
Lo que no es: hacer descansar todo en una sola persona.
Reflejo: cuanto más compartida es la documentación, menos se depende.
En la práctica — En la práctica — Escribir un runbook
- Elige una avería frecuente que sepas resolver (como el servidor de archivos de Sofiane).
- Escribe los pasos precisos, en orden, como para un compañero no experto.
- Haz que otra persona lo pruebe: si se atasca, es la documentación lo que hay que corregir.
- Guárdalo en un sitio localizable y anota su fecha de actualización.
Script paso a paso — escribir un runbook como Sofiane (10 min)
1) Elige una avería que sepas resolver. 2) Escribe el título tal como se describiría de viva voz. 3) Enumera los pasos precisos, en orden, con las rutas y los comandos exactos. 4) Añade el final feliz: cómo comprobar que está restablecido. 5) Dáselo a probar a un compañero no experto. 6) Corrige cada punto donde se atasque, guárdalo y féchalo.
La pregunta mágica para validar una documentación: «¿otra persona lo logra sin mí?». Si no, corrígela.
Plantilla copiar-pegar — mi runbook
Título: ___ (p. ej. «El servidor de archivos no responde»)
Síntoma observado: ___
1. ___
2. ___
3. ___
Comprobación de que está restablecido: ___
Dónde guardarlo: ___ (localizable por el equipo)
Última actualización: ___
Regla: al día · localizable · accionable.Un runbook de avería
Sofiane escribe qué hacer si el servidor de archivos no responde, paso a paso.
Un procedimiento de rutina
Sofiane documenta la instalación de un puesto estándar para la pyme.
Una base de conocimiento
Sofiane capitaliza las soluciones ya encontradas para que el equipo no vuelva a empezar de cero.
Una documentación viva
Sofiane fecha y corrige sus documentos cuando cambia la configuración.
✓ Buenas prácticas
- Documentar sobre la marcha: cuesta mucho menos que después.
- Escribir para el lector: pasos claros, probados por otro.
- Mantener la documentación al día y localizable.
✗ Errores frecuentes
- Guardar el saber en la cabeza.
- Escribir una documentación nunca actualizada: engaña.
- Documentar para uno mismo, ilegible para los demás.
Puntos clave
- El saber no documentado es un riesgo de bloqueo.
- Procedimiento (cómo hacer), runbook (qué hacer en caso de avería), base de conocimiento (soluciones capitalizadas).
- Una buena documentación está al día, es localizable y accionable.
- Documentar sobre la marcha cuesta menos que reconstruir después.
Reto 48 h — aplícalo mañana
Como Sofiane, escribe UN runbook para una avería que sepas resolver: título, síntoma, pasos precisos en orden y comprobación final. Haz que lo pruebe otra persona y corrige donde se atasque. Guárdalo en un sitio localizable y féchalo.
- Puedo explicar por qué el saber no documentado es un riesgo.
- Distingo procedimiento, runbook y base de conocimiento.
- Sé qué hace buena a una documentación: al día, localizable, accionable.
Preguntas frecuentes
¿Documentar no hace perder tiempo?
A corto plazo un poco; a medio plazo ahorra mucho: menos rediagnósticos, autonomía del equipo, continuidad en caso de ausencia. El verdadero coste es el de un saber que desaparece con la persona que lo tenía.
¿Cómo sé si una documentación es buena?
Haz que otra persona la ejecute: si lo logra sin consultarte, la documentación es accionable. Cada bloqueo encontrado indica exactamente qué corregir.
¿Cuál es el principal interés de documentar los procedimientos de TI?