Cómo documentar correctamente los datos de una empresa

Introducción

La documentación de los datos debe conservar su significado, su origen y las reglas que permiten utilizarlos. Saber dónde está una tabla no basta para interpretarla. Una columna llamada “fecha” puede indicar cuándo llegó una solicitud, cuándo se aceptó o cuándo alguien la introdujo en la aplicación. Si esa diferencia no está escrita, cada consulta puede producir una respuesta distinta.

En una pequeña empresa, buena parte de ese conocimiento vive en conversaciones: “ese importe todavía no lleva el descuento”, “los registros antiguos no incluyen cancelaciones” o “el estado cerrado no significa que el cliente haya aceptado la solución”. Son detalles que afectan directamente a informes, integraciones y decisiones operativas.

Documentar correctamente los datos de una empresa consiste en transformar ese conocimiento en referencias verificables y mantenibles. No exige describir de golpe todas las columnas existentes. Exige empezar por la información que otras personas necesitan interpretar, corregir o reutilizar sin depender de quien la creó.

Este artículo propone cómo redactar esas referencias: definiciones de negocio, fichas de conjuntos, diccionarios de campos, relaciones, transformaciones, limitaciones y cambios. El foco está en explicar los datos; no en inventariar servidores ni en redactar manuales de instalación.

Índice

• Qué debe resolver la documentación y qué pertenece a otros documentos
• Elegir los primeros datos que merece la pena documentar
• Redactar definiciones de negocio que no se limiten a repetir el nombre
• Crear una ficha que explique cada conjunto de datos
• Construir un diccionario de campos con detalle suficiente
• Explicar nulos, unidades, fechas y estados sin ambigüedades
• Documentar relaciones y granularidad antes de unir tablas
• Registrar el recorrido del dato y las transformaciones que cambian su interpretación
• Documentar reglas aplicadas, controles pendientes y límites conocidos
• Conectar cada definición con responsables y condiciones de acceso
• Mantener versiones del significado, no solo fechas de edición
• Caso práctico: documentar una solicitud que se resuelve y después se reabre
• Organizar las referencias y comprobar que siguen siendo utilizables
• Preguntas frecuentes
• Conclusión

Qué debe resolver la documentación y qué pertenece a otros documentos

Una documentación útil permite responder tres preguntas consecutivas: qué estoy mirando, cómo debo interpretarlo y qué límites tiene su uso. El nombre del archivo o de la tabla solo resuelve una pequeña parte de la primera.

Por ejemplo, un conjunto llamado “clientes activos” necesita aclarar si incluye a quienes tienen un contrato vigente, a quienes han comprado durante un periodo o a quienes no están dados de baja. Las tres definiciones pueden ser legítimas para propósitos distintos; ninguna debería quedar implícita.

Separar documentos que cumplen funciones diferentes

Un catálogo ayuda a localizar activos de información. Un diccionario describe sus campos. Un glosario fija conceptos de negocio. Un procedimiento explica cómo realizar una tarea. Un esquema técnico muestra estructuras y relaciones implementadas. Pueden enlazarse entre sí, pero no sustituirse unos por otros.

El catálogo corporativo de datos puede ser el punto de entrada a la documentación sin repetir todo su contenido. Desde la ficha de un conjunto debería llegarse a la definición que se mantiene como referencia, no a una copia adicional que acabará desactualizada.

Asimismo, documentar una base de datos implica cuestiones propias del esquema y su mantenimiento. La documentación empresarial del dato atraviesa aplicaciones, exportaciones y hojas de cálculo: puede existir aunque no se administre ningún motor de base de datos.

Esta separación evita dos extremos. El primero es reducir la documentación a una lista de columnas. El segundo es intentar incluir en la misma ficha todos los manuales técnicos de la organización. El objetivo es proporcionar el contexto necesario y enlazar el detalle especializado cuando corresponda.

Elegir los primeros datos que merece la pena documentar

Empieza por los datos que provocan decisiones o preguntas recurrentes. Un listado usado cada semana para asignar trabajos suele ser más urgente que un archivo histórico que nadie consulta. La prioridad depende del uso, de la dificultad de interpretación y del coste de equivocarse.

Una selección inicial razonable puede incluir un proceso completo: solicitud, trabajo realizado y cierre. Seguir ese recorrido permite descubrir cómo cambia el significado entre fuentes sin convertir el proyecto en un inventario interminable.

Buscar preguntas que hoy requieren interrumpir a alguien

Reúne dudas reales: qué registros incluye un informe, cuál es la fuente correcta de una fecha, quién puede corregir un identificador, cómo se tratan cancelaciones o qué significa un campo vacío. Cada duda señala un elemento que la documentación debería resolver.

También conviene recoger contradicciones. Si dos personas interpretan “resuelto” de forma diferente, no basta con escribir la opinión de quien responde primero. Registra la discrepancia y pide una decisión a la función que conoce y gobierna ese proceso.

En una empresa unipersonal, redactar estas diferencias sigue siendo útil. Permite separar una regla estable de una costumbre que solo se recuerda mientras se trabaja en ella. Además, facilita revisar una automatización meses después sin reconstruir toda su historia.

No presupongas que la exportación más accesible es la fuente autorizada. Identifica quién la genera, qué filtros aplica y si deriva de otra aplicación. Documentar una copia sin conocer su origen puede consolidar un malentendido en lugar de resolverlo.

Para contener el alcance, define una entrega verificable: “otra persona podrá interpretar estos datos de solicitudes y distinguir lo pendiente de lo finalizado”. Es un objetivo más útil que “documentar el veinte por ciento de las tablas”, porque relaciona el trabajo con una capacidad concreta.

Redactar definiciones de negocio que no se limiten a repetir el nombre

Una definición debe diferenciar el concepto de otros cercanos. “Fecha de cierre: fecha en la que se cierra” es circular. No aclara qué evento constituye el cierre, quién lo confirma ni qué ocurre si el caso se reabre.

Una redacción mejor describe el hecho observable y el criterio: “momento en que se registra la aceptación final de la resolución; permanece vacío mientras el caso está abierto o reabierto”. Esta frase ya permite discutir si el comportamiento del sistema coincide con la definición.

Incluir alcance, exclusiones y ejemplos

Para cada término importante, especifica qué incluye, qué excluye y un ejemplo representativo. En “trabajo completado”, puede ser necesario excluir borradores, cancelaciones y pruebas internas. No es suficiente escribir “trabajos válidos” si validez también está por definir.

Evita combinar conceptos distintos para simplificar un informe. “Cliente activo comercialmente” y “cliente con contrato vigente” pueden mantener nombres separados. Una definición más precisa permite después construir la relación entre ambas poblaciones sin fingir que son idénticas.

El glosario no debe convertirse en un ensayo. Su calidad se demuestra cuando dos personas aplican una definición al mismo caso y obtienen la misma clasificación, o identifican explícitamente la situación que falta por regular.

Crear una ficha que explique cada conjunto de datos

Antes de describir columnas, explica qué representa el conjunto. Una tabla puede contener una fila por cliente, por intervención, por línea de intervención o por cambio de estado. Esa unidad determina cómo se puede contar, sumar y relacionar la información.

La ficha debería dar un identificador estable al conjunto, un nombre comprensible, su finalidad y una descripción de la población incluida. Añade la fuente autorizada, la localización consultable, el responsable funcional y la referencia al diccionario de campos.

Documentar cobertura y temporalidad

Indica desde qué fecha existe información, qué registros quedan fuera y si los datos reflejan el estado actual o una historia de eventos. Una exportación que solo conserva solicitudes abiertas no permite medir por sí sola todas las solicitudes recibidas durante un año.

Registra cómo se actualiza el conjunto y qué retraso puede existir. “Actualización diaria” necesita contexto: cuándo se intenta obtener la información, qué periodo se considera cerrado y cómo se identifica la última actualización realmente completada. La hora programada no demuestra que el proceso haya terminado.

Identificador: solicitudes_servicio
Finalidad: seguimiento de solicitudes y sus estados actuales
Unidad: una solicitud aceptada por el canal de entrada
Incluye: solicitudes abiertas y cerradas del sistema vigente
Excluye: mensajes descartados antes del registro y datos de prueba
Fuente autorizada: aplicación de servicio
Historia: el estado es actual; los cambios viven en otro conjunto
Actualización de la exportación: según ejecución registrada
Responsable de significado: función de operaciones
Detalle: diccionario y reglas de solicitudes_servicio

La ficha anterior es un ejemplo propuesto, no una descripción de una empresa real. Las exclusiones deben adaptarse y comprobarse; no deberían copiarse como una fórmula de documentación.

Una ficha tampoco debe prometer una cobertura que nadie ha verificado. Cuando se desconoce si una migración incorporó todos los registros antiguos, conviene escribir “cobertura histórica pendiente de comprobar” e indicar quién resolverá la duda. La incertidumbre documentada es más útil que una certeza aparente.

Construir un diccionario de campos con detalle suficiente

El diccionario conecta el lenguaje del negocio con la representación técnica. Debe permitir identificar una columna y entender qué valores son admisibles, cómo se interpretan y qué condiciones especiales tienen.

Para los campos relevantes, incluye nombre técnico, etiqueta comprensible, definición, tipo de valor, unidad, obligatoriedad y ejemplos. Añade valores permitidos cuando exista un catálogo, y la referencia a otra entidad cuando el campo represente una relación.

Evitar una tabla enorme y horizontal

Una ficha de conjunto puede mostrar una vista resumida y enlazar fichas de campo para los detalles. Si se trabaja con una hoja, separa la descripción principal de las reglas complejas. Repetir veinte columnas casi vacías para cada campo suele dificultar la consulta.

El vocabulario de metadatos tabulares del W3C ofrece una referencia técnica para describir columnas, tipos, valores nulos, obligatoriedad y claves. No es obligatorio adoptar ese formato para empezar; permite distinguir qué puede expresarse de forma estructurada y qué explicación funcional debe añadirse.

No confundas tipo técnico y significado. Un campo numérico puede representar una cantidad, un porcentaje o un identificador. Aunque una aplicación almacene una referencia como número, la documentación debe advertir si no tiene sentido sumarla ni transformarla mediante operaciones aritméticas.

Explicar nulos, unidades, fechas y estados sin ambigüedades

Los problemas de interpretación suelen concentrarse en valores aparentemente pequeños. Un cero, una cadena vacía y un nulo pueden tener significados diferentes. También puede haber sistemas que los mezclen. La documentación debe describir el comportamiento observado y señalar dónde no coincide con la intención.

Para un importe, cero puede significar una operación sin cargo; nulo, que todavía no se ha calculado. Reemplazar ambos por la misma etiqueta impide distinguir una decisión comercial de una falta de información. Si el origen no permite separarlos, escribe esa limitación en lugar de afirmar que la distinción existe.

Unidades y escalas

Indica si una duración se expresa en minutos u horas y si un porcentaje se representa como 0,15 o como 15. Para cantidades monetarias, define moneda y criterio de inclusión de impuestos o descuentos según el uso del campo. No presupongas que todos los importes de una aplicación siguen la misma convención.

Documenta también qué redondeo se aplica y en qué momento cuando eso afecte al resultado. Sumar valores ya redondeados puede producir una cifra diferente de redondear únicamente el total; la documentación debe permitir reproducir el criterio adoptado.

Fechas y eventos

Una fecha sin hora representa algo distinto de un instante. “Día de servicio previsto” puede ser una fecha de calendario; “registro recibido” necesita una referencia horaria si se comparan sistemas. Indica la zona o el criterio temporal y cómo debe mostrarse al usuario, sin atribuirle precisión que el origen no aporta.

En los estados, incluye la condición de entrada y la condición de salida. No basta con enumerar “pendiente”, “resuelto” y “cerrado”. Explica qué evidencia permite pasar de uno a otro y si una reapertura conserva el cierre anterior como histórico.

Las normas para nombrar datos y documentos ayudan a dar nombres coherentes. El paso adicional consiste en fijar qué significa cada nombre y qué interpretaciones deben evitarse.

Documentar relaciones y granularidad antes de unir tablas

Una relación debe explicar qué une dos conjuntos, con qué clave y cuántos registros pueden corresponderse. Decir “solicitudes relacionadas con intervenciones” no permite saber si cada solicitud tiene una intervención o si puede requerir varias.

En un modelo propuesto de servicio técnico, una solicitud puede generar varias intervenciones; una intervención pertenece a una solicitud; cada intervención puede consumir varias piezas. Son niveles diferentes. Una consulta que los una debe respetar esa multiplicidad.

Advertir sobre la repetición de valores

Supongamos que una solicitud tiene un importe de 120 euros y dos intervenciones. Al unir la cabecera con las intervenciones, el importe puede aparecer en dos filas. Sumar esa columna sin considerar su nivel produciría 240 euros, aunque la solicitud siga teniendo un importe de 120.

El ejemplo es una consecuencia de repetir la cabecera, no un error aritmético del programa. Una advertencia documental útil sería: “el importe pertenece a la solicitud; no sumar después de expandir intervenciones salvo que se aplique una agregación compatible con ese nivel”.

Registra además qué sucede con referencias ausentes. Un registro puede llegar antes que su entidad relacionada, pertenecer a una fuente histórica o contener una clave incorrecta. Cada situación requiere tratamiento distinto. No asumas que una coincidencia por nombre equivale a una relación confirmada.

Identificadores propios y correspondencias

Si dos sistemas usan identificadores distintos, documenta la correspondencia y quién la mantiene. Incluye el sistema de origen como parte de la clave cuando sea necesario. Evita unir por un número aislado cuyo ámbito no se conoce.

Una tabla de relaciones puede recoger conjunto de origen, campo de enlace, conjunto de destino, multiplicidad y excepciones conocidas. Para profundizar en el uso de estas relaciones en consultas, puede consultarse cómo unir tablas empresariales. La documentación debe preparar esa consulta antes de que alguien descubra duplicaciones en un informe.

Registrar el recorrido del dato y las transformaciones que cambian su interpretación

El linaje describe de dónde procede una información y qué operaciones la han convertido en el resultado que se consulta. No necesita empezar con un diagrama complejo. Puede ser una relación clara entre fuente, extracción, transformación y destino.

Para un listado de solicitudes pendientes, conviene saber si sale directamente de la aplicación o de una exportación que elimina ciertos estados, corrige etiquetas y combina registros de otras fuentes. El resultado puede ser perfectamente válido, pero no representa necesariamente todo lo que existe en origen.

Dar identidad a las transformaciones relevantes

Documenta las operaciones que cambian población, significado o valores: filtros, fusiones, cálculos, conversiones de unidad, selección de la versión vigente y reglas de deduplicación. No hace falta describir cada instrucción de un programa si no afecta a la interpretación.

Resultado: solicitudes_pendientes_revision
Origen: exportación de solicitudes_servicio
Filtro: estados recibida, pendiente_datos y en_tramitacion
Exclusión: registros identificados como prueba
Transformación: equivalencia de estados antiguos según tabla E-02
Relación: equipo_id con inventario vigente
Casos sin equipo confirmado: se conservan con advertencia
Regla aplicada: pendientes-2
Ejecución: identificador del lote y fecha de finalización

Este ejemplo es un esquema documental propio. Debe enlazar las reglas y equivalencias reales del sistema, no convertirse en una segunda definición independiente.

Conserva la diferencia entre versión de la transformación y ejecución concreta. La misma regla puede ejecutarse cada día sobre entradas diferentes. Para explicar una discrepancia hacen falta ambas referencias: qué lógica se aplicó y a qué datos.

Una descripción como “se limpia el archivo” es demasiado imprecisa. Sustitúyela por las operaciones relevantes y sus límites. Cuando existan varias aplicaciones, la documentación puede apoyarse en los flujos de intercambio de información, manteniendo visible qué cambios ocurren en cada paso.

Documentar reglas aplicadas, controles pendientes y límites conocidos

Una regla deseada no equivale a un control implantado. La documentación debe distinguir “este campo debería ser único” de “la aplicación impide duplicarlo” y de “se revisa su duplicidad mediante una consulta periódica”. Las tres frases describen niveles de garantía distintos.

Para cada control importante, registra condición, ámbito, implementación, respuesta ante fallo y evidencia disponible. Cuando no exista implementación, indícalo expresamente. De lo contrario, un consumidor puede confiar en una integridad que todavía no se comprueba.

No convertir calidad desconocida en calidad aceptada

Una ficha debe poder decir que hay registros sin verificar o periodos incompletos. La advertencia tiene que explicar la consecuencia: “no utilizar este histórico para comparar tiempos anteriores y posteriores a la migración” es más útil que “puede contener errores”.

Separa limitaciones permanentes y problemas temporales. Si una fuente nunca registró la hora de recepción, no se puede reconstruir con precisión por corregir el formato. Si una carga concreta se interrumpió, puede reprocesarse y retirar la advertencia al confirmar el resultado.

Cuando una incidencia se resuelva, conserva la referencia al cambio si afecta a interpretaciones previas. No es necesario mantener todas las advertencias en la portada, pero sí permitir que un informe histórico pueda explicarse.

Hacer visibles los usos no permitidos por el significado

Un conjunto creado para seguimiento diario puede no servir para medir productividad individual, porque no recoge pausas ni complejidad del trabajo. Una buena documentación no solo explica cómo usar datos: también advierte cuándo una conclusión no está respaldada por lo que se ha registrado.

Los controles de detección se desarrollan en cómo detectar errores frecuentes en los datos empresariales. En la documentación interesa dejar claro cuáles se han aplicado realmente, sobre qué población y con qué resultado conocido.

Conectar cada definición con responsables y condiciones de acceso

Una definición que nadie puede aprobar o corregir pierde utilidad cuando aparece un conflicto. Cada conjunto crítico debe indicar qué función decide su significado y qué persona o función mantiene la referencia operativa.

La responsabilidad técnica es diferente. Quien administra una base puede conocer tipos y restricciones, pero no necesariamente qué eventos deberían considerarse una venta o una resolución. La documentación gana precisión cuando se revisa desde ambas perspectivas.

En una microempresa, la misma persona puede desempeñar todos esos papeles. Aun así, distinguirlos evita tratar una decisión de negocio como si fuera una simple opción de configuración. El modelo detallado se explica en cómo definir propietarios y responsables de los datos.

Documentar el acceso sin distribuir secretos

Describe cómo solicitar acceso, quién lo autoriza y qué usos están previstos. No copies contraseñas, claves privadas ni tokens en las fichas. Una referencia al mecanismo de acceso es suficiente para orientar al usuario autorizado.

Los ejemplos deben ser sintéticos cuando no sea necesario mostrar registros reales. Copiar fichas de clientes en una wiki de amplia consulta puede ampliar la exposición sin mejorar la explicación. También las rutas internas y los nombres de sistemas pueden requerir un acceso restringido según el contexto.

La documentación compartida puede tener dos niveles: una descripción general para localizar el activo y un detalle restringido para quienes deban administrarlo o tratarlo. Documentar que un dato existe no obliga a entregar su contenido a todas las personas.

Añade el criterio de conservación y retirada cuando esté definido, sin improvisar plazos. Distingue conservación operativa, histórica y de copias. Si existen obligaciones específicas, deben revisarse con quien corresponda; una plantilla de documentación no las determina por sí sola.

Mantener versiones del significado, no solo fechas de edición

La fecha de última modificación indica cuándo se tocó un documento, pero no qué cambió. Corregir una tilde no tiene el mismo efecto que modificar la definición de “cliente activo”. Ambos cambios pueden actualizar la fecha y solo uno alterar todos los indicadores posteriores.

Registra los cambios de significado con un identificador de versión, una fecha de entrada en vigor y una explicación de impacto. Identifica qué conjuntos y consumidores están afectados y quién aprobó la nueva interpretación.

Distinguir tres clases de cambio

Un cambio editorial mejora la redacción sin modificar el criterio. Un cambio estructural añade o retira campos o altera su representación. Un cambio semántico modifica lo que representan los datos. Esta clasificación ayuda a decidir qué pruebas y avisos hacen falta.

Por ejemplo, pasar de medir tiempo natural a medir tiempo laborable no es simplemente renombrar una columna. El resultado cambia aunque las fechas originales sigan siendo las mismas. Una serie histórica necesita indicar desde cuándo se aplica cada criterio o recalcularse de forma controlada.

No sobrescribas retrospectivamente todas las definiciones sin conservar la anterior. Puede ser necesario interpretar una exportación antigua o justificar por qué un informe cerrado arrojó determinada cifra. El histórico documental debe permitir esa reconstrucción.

Introducir la revisión donde se produce el cambio

Cuando se modifica un formulario, una integración o un catálogo, revisa las definiciones afectadas antes de dar el cambio por terminado. Una auditoría trimestral puede detectar olvidos, pero llega tarde para prevenir que un consumidor utilice una columna recién modificada con la interpretación anterior.

Para la relación entre pasado y presente resulta útil gestionar históricos empresariales sin perder trazabilidad. El documento también tiene historia: conservar versiones no significa mantener varias definiciones vigentes sin aclarar cuál corresponde a cada periodo.

Caso práctico: documentar una solicitud que se resuelve y después se reabre

Supongamos un servicio de asistencia con este caso hipotético: una solicitud se registra a las 08:00 UTC del día 15; se comunica una primera solución a las 10:00; se reabre a las 08:00 del día 16 y se cierra definitivamente a las 09:00 de ese mismo día.

Alguien pide “el tiempo de resolución”. Una persona responde dos horas porque usa la primera solución; otra responde veinticinco porque utiliza el cierre final. No hay necesariamente un error de cálculo: falta una definición compartida de la medida.

Separar conceptos y fuentes

La empresa decide documentar dos conceptos: “tiempo hasta primera resolución propuesta” y “tiempo hasta cierre definitivo”. Para este ejemplo ambos se expresan en horas naturales transcurridas, sin descontar pausas. Esa decisión se presenta como una regla del caso, no como el único criterio correcto para cualquier servicio.

La ficha identifica la solicitud como unidad de seguimiento. El diccionario indica qué significa cada fecha. El registro de eventos conserva propuesta, reapertura y cierre. El estado actual de la solicitud, por sí solo, no permite reconstruir toda la secuencia.

La tercera fila es especialmente importante. La documentación no debe convertir veinticinco horas transcurridas en veinticinco horas de trabajo. Si no existe registro de dedicación, esa medida no está respaldada por los datos.

Validación de la documentación

Una segunda persona recibe el conjunto y las definiciones, sin una explicación oral adicional. Debe poder reproducir las dos duraciones, reconocer que existe una reapertura y explicar por qué no puede calcular la dedicación.

Si lo consigue, la documentación ha resuelto una ambigüedad operativa real. Si todavía necesita preguntar qué columna usar o qué hacer con la reapertura, la ficha no está terminada, aunque todos sus apartados estén rellenados.

Organizar las referencias y comprobar que siguen siendo utilizables

Elige un soporte que permita encontrar, editar y conservar las definiciones sin crear copias descontroladas. Puede ser una wiki, documentos estructurados o tablas compartidas. La elección debe responder a quién mantiene el contenido y cómo se revisan los cambios.

El soporte no arregla por sí solo los desacuerdos de significado. Una plataforma sofisticada puede indexar miles de columnas y seguir sin explicar qué representa una de las más importantes. Empieza por definiciones fiables y amplía las capacidades cuando el mantenimiento lo requiera.

Una organización documental sencilla

Un punto de entrada puede enlazar el glosario común, las fichas de conjuntos y el registro de decisiones. Dentro de cada conjunto, reúne diccionario, relaciones, reglas y limitaciones. Conserva identificadores estables para que los enlaces no dependan de títulos que cambian con frecuencia.

Evita repetir la definición completa de un término en todas las fichas. Mantén una referencia principal y añade solo la particularidad local. Cuando un significado sea realmente distinto, dale un nombre diferente en lugar de ocultar la diferencia en una nota secundaria.

Medir utilidad, no volumen documental

Comprueba si una persona puede resolver preguntas habituales sin ayuda, si una modificación permite identificar consumidores afectados y si las dudas recurrentes encuentran respuesta. Contar páginas o campos documentados no demuestra ninguna de esas capacidades.

Como revisión práctica, selecciona un conjunto usado recientemente y pide que se explique un dato, un cálculo, una exclusión y una corrección. Si la respuesta depende de conversaciones no registradas, añade esa información a la referencia adecuada.

La disciplina general puede apoyarse en documentación tecnológica sencilla para una PYME. En el caso del dato, el criterio de cierre es preciso: otra persona debe poder interpretar la información, reconocer sus límites y encontrar a quien resuelve lo que aún no está definido.

Preguntas frecuentes

Conclusión

Documentar correctamente los datos de una empresa no consiste en describir tablas por obligación. Consiste en conservar las decisiones que permiten entenderlas: qué representa cada registro, qué significa cada campo, de dónde procede, cómo se transforma y para qué usos resulta adecuado.

Un glosario claro, una ficha de conjunto, un diccionario proporcionado y un registro de cambios pueden resolver más problemas que una documentación extensa basada en nombres y capturas. La diferencia está en hacer explícitas las reglas, las excepciones y las limitaciones.

La prueba definitiva es la transferencia de conocimiento. Cuando otra persona puede consultar, relacionar y corregir información sin reconstruir conversaciones pasadas, la documentación empieza a funcionar como parte del sistema de trabajo.