Control de versiones de documentos: cómo evitar trabajar con información obsoleta

Qué es el control de versiones

En un proyecto, los documentos no se emiten una sola vez. Un plano, una especificación o un cálculo cambian a medida que avanza el diseño, se incorporan comentarios o se modifican los requisitos. El control de versiones es el conjunto de reglas y herramientas que permite gestionar esos cambios sin perder información y sin generar dudas sobre cuál es la buena.

Conviene distinguir cuatro conceptos:

Documento

La entidad que se gestiona a lo largo del tiempo, identificada por su código: por ejemplo, el plano de cimentación de un edificio. Sigue siendo el mismo documento aunque cambie su contenido.

Revisión o versión

Cada estado concreto del contenido de ese documento en un momento dado, normalmente asociado a un archivo. Según la organización se habla de revisiones (A, B, C…), de versiones (1, 2, 3…) o de una combinación de ambas.

Versión vigente

La versión que el proyecto reconoce como actual para ese documento. Solo debería haber una.

Versión histórica

Cualquier versión anterior a la vigente. Ya no es la referencia, pero forma parte del registro del proyecto y debe poder consultarse.

Los términos «revisión» y «versión» se usan de forma distinta según el sector y la organización. Algunas reservan «revisión» para las emisiones formales y «versión» para los cambios de trabajo; otras los emplean como sinónimos. Lo importante es que la convención esté acordada y se aplique igual en todo el proyecto.

Por qué «final_v3_OK.pdf» no es un sistema de versionado

Casi cualquier técnico ha visto alguna vez una carpeta como esta:

El nombre del último archivo sugiere que es el bueno, pero no lo garantiza. ¿«OK» significa aprobado por el cliente o revisado por un compañero? ¿La copia «(1)» es idéntica o alguien la cambió después? ¿Existe una versión posterior en el correo de otra persona? El nombre del archivo intenta hacer de sistema de versionado, y no puede:

• Nombres de archivo. Dependen de quien guarda el archivo, no siguen una regla común y no dicen nada fiable sobre el estado o la aprobación.
• Archivos duplicados. Cada copia es un candidato a «versión buena»; con el tiempo, nadie sabe cuál es la original.
• Adjuntos de correo. Cada envío crea una copia fuera del control del autor, que sigue circulando aunque el documento cambie.
• Copias locales. Quien descargó un plano hace dos semanas puede seguir trabajando con él sin saber que existe una revisión nueva.
• Sobrescrituras sin control. Si alguien guarda encima del archivo existente, la versión anterior desaparece junto con la evidencia de lo que decía.

El problema de fondo es que la información sobre la versión —cuál es, quién la hizo, si está aprobada— vive fuera del sistema: en la memoria de las personas o en convenciones informales. Un control de versiones real la registra de forma explícita, junto al propio documento.

Versión vigente frente a versiones históricas

Un proyecto necesita a la vez dos cosas que parecen opuestas: una única referencia clara y la certeza de que no se pierde nada de lo anterior.

Una única versión vigente, claramente identificada. Quien consulta un documento debe saber, sin interpretar nombres ni fechas, cuál es la versión actual. Si pueden coexistir dos versiones «actuales», el control de versiones no está cumpliendo su función.

Conservación de las versiones anteriores. Las versiones históricas no son residuos: son la evidencia de lo que se emitió en cada momento. Si un contratista fabricó a partir de la revisión B, hay que poder consultar exactamente qué decía la revisión B, aunque la vigente sea ya la D.

Contexto histórico. Una versión antigua sin contexto sirve de poco. Además del archivo, interesa conservar en qué estado estaba, para qué estaba autorizada, quién la aprobó y por qué se sustituyó. Ese contexto es lo que permite, meses después, entender una decisión y no solo encontrar un archivo. Lo desarrollamos en la guía de trazabilidad documental.

Qué debe registrar una versión

Cada organización y cada herramienta definen sus propios campos, pero una versión útil suele ir acompañada de información como esta:

Identificador

Número o código de versión o revisión, según la convención del proyecto.

Fecha

Cuándo se creó o se emitió la versión.

Autor

Quién la subió o la elaboró, y de qué organización.

Estado

En qué punto del ciclo de vida está: en trabajo, compartida, publicada…

Archivo

El contenido concreto de esa versión, conservado tal como se registró.

Comentarios

Qué cambia respecto a la anterior o por qué se emite.

Decisión

Si se revisó o aprobó: con qué resultado, quién decidió y con qué justificación.

Integridad

Cuando procede, una huella del archivo (por ejemplo, un hash criptográfico) que permite comprobar que no ha cambiado.

No todos los campos son necesarios en todos los proyectos, ni todas las herramientas los implementan igual. Lo relevante es que la información mínima para identificar, entender y verificar cada versión se registre en el momento en que se crea, y no haya que reconstruirla después.

Versionado y revisión/aprobación

El control de versiones y los flujos de revisión y aprobación están muy relacionados, pero no son lo mismo. Confundirlos es una fuente habitual de problemas.

• El versionado responde a «qué ha cambiado»: registra cada nuevo contenido del documento.
• La revisión y aprobación responde a «si ese contenido es válido para un uso determinado»: registra una decisión sobre una versión concreta.

Un documento puede tener varias versiones mientras sigue en estado de trabajo: el autor sube la versión 1, corrige y sube la 2, completa y sube la 3. Ninguna está aprobada todavía. En algún momento, una versión concreta —la 3— entra en revisión; si el revisor pide cambios, aparece una versión 4, que es la que finalmente se aprueba y se publica.

De ahí se derivan dos consecuencias prácticas. La primera: «la última versión» y «la versión aprobada» no tienen por qué coincidir, y un buen sistema muestra ambas cosas por separado. La segunda: la aprobación debe quedar ligada a la versión exacta que se revisó. Si después se sube otra versión, esa aprobación no debería trasladarse a la nueva sin una decisión explícita.

Qué ocurre cuando se sobrescriben documentos

Sobrescribir un archivo parece inocuo: el documento sigue ahí, con el mismo nombre, solo que actualizado. Pero se pierde algo que no se echa en falta hasta que hace falta:

• Pérdida de evidencia. Desaparece lo que decía el documento antes del cambio. Si alguien actuó conforme a la versión anterior, ya no se puede demostrar qué recibió.
• Incertidumbre. Quien abre el archivo no sabe si es el mismo que revisó la semana pasada o si ha cambiado desde entonces.
• Imposibilidad de reproducir decisiones. Una aprobación sobre un contenido que ya no existe pierde su valor: no se puede comprobar qué se aprobó.
• Personas trabajando con información obsoleta. Las copias descargadas antes de la sobrescritura siguen circulando, y nada avisa de que ya no coinciden con el original.

Por eso los sistemas de control de versiones sólidos no permiten sobrescribir: cada cambio de contenido genera una versión nueva, y la anterior se conserva intacta.

Buenas prácticas

1. 01Versiones históricas inmutables. Una versión registrada no se modifica; si hay que cambiar algo, se crea otra.
2. 02Versión vigente explícita. Es el sistema, y no el nombre del archivo, el que indica cuál es la versión actual de cada documento.
3. 03Nomenclatura coherente. Un código de documento estable, acordado por el proyecto, y un identificador de versión que siga una regla común.
4. 04Cambios de estado controlados. Pasar de trabajo a compartido o a publicado requiere una decisión registrada, no mover un archivo de carpeta.
5. 05Responsabilidades claras. Se sabe quién puede subir versiones, quién revisa y quién aprueba cada tipo de documento.
6. 06Sin copias paralelas fuera de control. La referencia está en un único sitio; las copias locales o enviadas por correo se consideran informativas, no válidas.
7. 07Registro de auditoría. Cada versión, cambio de estado y decisión queda registrado con su autor y su fecha.

Ninguna herramienta sustituye estos acuerdos, pero una buena herramienta hace que sean fáciles de cumplir y difíciles de saltarse. Si todavía estás valorando qué tipo de herramienta necesitas, la comparación entre CDE y gestor documental puede ayudarte a situarte.

Ejemplo de ciclo

Un ciclo sencillo de un documento, desde su primera versión hasta su publicación:

El ciclo parece sencillo, pero cada flecha implica algo que una carpeta compartida no registra: quién pidió la revisión, qué se comentó, qué versión exacta se aprobó y cuándo pasó a ser la referencia para el resto del proyecto. Cómo se organizan estos estados en un entorno común de datos lo explicamos en cómo funciona un CDE.

Cómo lo gestiona CDE de VeritecGroup

En CDE de VeritecGroup, el control de versiones sigue estas reglas, descritas en la página de producto:

• Cada subida crea una versión nueva e inmutable: ninguna revisión sobrescribe a la anterior.
• El documento apunta siempre a una única versión vigente.
• Las versiones anteriores se conservan, consultables y descargables, con su estado e idoneidad de origen.
• El servidor calcula la huella SHA-256 de cada versión; nunca se confía en la que envía el cliente.
• Mientras hay un cambio de estado pendiente, no se admiten versiones nuevas del documento.
• Los cambios de estado se solicitan, se revisan y se deciden, y la decisión queda ligada a la versión exacta y a su comentario.
• Versiones y decisiones quedan en el registro de actividad del documento.

Cómo se protegen el acceso a los archivos y su almacenamiento se explica en seguridad. Si quieres ver el ciclo con tus propios tipos de documento, solicita una demo.

Todos los recursos