Gestión de archivos de proyecto: mejores prácticas para equipos

Una gestión sólida de archivos de proyecto se apoya en cinco hábitos: una jerarquía de carpetas poco profunda y predecible (máximo tres niveles), una convención de nomenclatura escrita que se aplique desde el primer día, una fuente única de verdad por tipo de archivo (un archivo de Figma, un .docx maestro, un .xlsx canónico), retención de versiones de al menos 180 días y archivado planificado al cierre del proyecto. El caos documental en los equipos no suele ser un problema de herramientas: es un problema de decisiones. Los equipos que se saltan la conversación de 30 minutos sobre dónde vive cada cosa acaban con siete archivos duplicados Presupuesto_Final.xlsx repartidos entre tres aplicaciones.

La regla de los tres niveles de carpeta

Las carpetas que superan los tres niveles se vuelven imposibles de encontrar. Haz la prueba: ¿puede tu equipo localizar el deck de revisión de diseño del Q2 2026 en menos de 30 segundos? Si la ruta es /Clientes/Acme/2026/Q2/Diseño/Revisiones/Junio/Deck_v3.pptx, la respuesta es no.

Una estructura que funciona tiene este aspecto:

/Proyectos
  /2026-Q2-Acme-Rebrand
    /01-brief
    /02-trabajo
    /03-final
    /04-archivo

Los prefijos numéricos fuerzan el orden de clasificación, el nombre de la carpeta del proyecto codifica el trimestre y el cliente para que la búsqueda lo encuentre al instante, y las cuatro subcarpetas se corresponden con estados reales del flujo de trabajo. Los equipos que adoptan este patrón reducen los mensajes de "¿dónde está el archivo?" en un 60-80 % durante el primer mes.

Convenciones de nomenclatura que sobreviven al contacto con la realidad

Una convención de nomenclatura solo funciona si cada miembro del equipo puede aplicarla sin pensar. El formato que funciona en la mayoría de sectores:

AAAA-MM-DD_CódigoProyecto_TipoDoc_Descriptor_vNN.ext

Ejemplo: 2026-06-12_ACME-RB_brief_alcance-trabajo_v03.pdf

Cinco reglas hacen esto sostenible:

• Fechas ISO 8601 (AAAA-MM-DD): se ordenan correctamente y se interpretan en cualquier idioma
• Códigos de proyecto, no nombres completos: ACME-RB es mejor que Proyecto Rebrand Acme 2026
• Sin espacios: usa guiones o guiones bajos, nunca los dos en el mismo campo
• Números de versión con dos dígitos: v03 se ordena correctamente más allá de v09; v3 no
• Minúsculas siempre que sea posible: la sensibilidad a mayúsculas da problemas en algunos sistemas de archivos

Escríbelo. Ponlo en tu documentación de incorporación. Revisa los archivos no conformes en el sync semanal del proyecto durante dos semanas; después se convierte en memoria muscular.

Fuente de verdad y copias de trabajo

Cada archivo en un proyecto entra en uno de dos grupos: la fuente canónica o una copia de trabajo. La fuente canónica es la que se entrega, se factura y revisan los interesados. Las copias de trabajo son borradores, ramas, experimentos.

El mayor fallo de gestión es perder de vista cuál es la copia canónica. Soluciones:

• Bloquea el archivo canónico: la mayoría de DAM (Bynder, Frontify) e incluso Dropbox tienen bloqueo en el momento de extracción.
• Nombra las copias de trabajo con un prefijo de propietario: jperez_WIP_2026-06-12_ACME-RB_hero.psd
• Mueve los activos finalizados a 03-final y elimina las versiones de trabajo al cierre del sprint. No las archives: las archives se convierten en "puntos de partida" y el problema se reinicia.

Seguimiento de archivos entre herramientas

Los proyectos reales abarcan Jira, Linear, Notion, Slack, Google Drive y un portal de cliente. Un archivo mencionado en un ticket de Jira vive en Drive; ese mismo archivo se comparte en Slack, se incrusta en una página de Notion y se entrega al cliente mediante un enlace de Dropbox. Hacer seguimiento manual de dónde están las copias es imposible.

Dos enfoques ayudan:

• Enlaza, no adjuntes: si el archivo canónico está en Drive, comparte el enlace de Drive en todas partes. Adjuntar en Slack crea una copia divergente que se queda obsoleta inmediatamente.
• Usa una capa de metadatos de archivo: herramientas como Airtable o bases de datos de Notion con una base "Archivos" pueden catalogar cada activo canónico con columnas para propietario, estado, fecha de última revisión, política de retención y enlaces externos.

Retención de versiones y recuperación

La mayoría de herramientas de sincronización mantienen un historial de versiones limitado por defecto: Google Drive conserva 100 versiones o 30 días en el nivel gratuito, Dropbox Business 180 días, Box 50 versiones en Business e ilimitadas en Enterprise. Comprueba tus valores predeterminados; probablemente tienes menos retención de la que crees.

Para proyectos regulados (limitación del almacenamiento según el artículo 5.1.e del RGPD, retención de 6 años según HIPAA), necesitas una política de retención que se ajuste a la normativa, no a los valores predeterminados de la herramienta. Configura exportaciones automáticas a almacenamiento en frío para todo lo que deba sobrevivir más allá de la ventana de retención de la herramienta.

Los ejercicios de recuperación son la versión aburrida de la continuidad de negocio. Una vez al trimestre, pide a alguien que elija un archivo de proyecto al azar, declare que se corrompió ayer y mida cuánto tarda en restaurar la versión anterior. Si supera los 10 minutos, tu proceso de retención tiene lagunas.

Gestión de entregas grandes y envíos externos

Las entregas finales de proyectos raramente caben en un correo electrónico. Un corte de vídeo en 4K supera los 40 GB, un paquete de fuentes PSD con capas llega a 2-10 GB, y los archivos BIM de arquitectura superan habitualmente los 5 GB. Tu sistema de gestión de proyectos necesita un protocolo claro de "entrega de deliverables".

El patrón que funciona: los archivos canónicos permanecen en tu DAM o herramienta de sincronización, pero la entrega final al cliente pasa por un servicio de transferencia dedicado con seguimiento. Servicios como WeTransfer Pro, Smash, SwissTransfer o HexaTransfer permiten enviar hasta 10-250 GB con caducidad de enlace, acuse de descarga y, en el caso de servicios con cifrado de extremo a extremo como HexaTransfer, cifrado AES-256-GCM del lado del cliente para que el proveedor no pueda acceder al contenido. Protege con contraseña cualquier entrega al cliente por defecto, aunque los archivos no sean sensibles.

El archivado: el paso que todos se saltan

Los proyectos terminan. Los archivos no. Un año después del cierre de un proyecto, todavía necesitas responder a "¿cuál fue el logotipo final que entregamos para Acme?", pero el caos de trabajo en /Proyectos/2026-Q2-Acme-Rebrand/02-trabajo/ ahora son 14 GB de ruido.

Disciplina de archivado al cierre del proyecto:

1. Copia 03-final en /Archivo/AAAA/CódigoCliente/ como solo lectura
2. Exporta un manifiesto del proyecto: un archivo .md que liste cada activo final, su propósito y el interesado que lo aprobó
3. Elimina 02-trabajo salvo que las normativas requieran su conservación
4. Establece un recordatorio de calendario para 12 meses después para reevaluar la retención del archivo

Ese manifiesto es el documento más útil para cualquier persona que se incorpore a una cuenta de cliente recurrente. Dedica los 30 minutos al cierre: tu yo futuro te lo agradecerá.

Prueba HexaTransfer en hexatransfer.com — gratuito, sin cuenta, máximo 10 GB.