Gestione file di progetto: best practices per i team

Il Garante per la protezione dei dati personali ricorda che i documenti di progetto contenenti dati personali richiedono controlli di accesso precisi e policy di retention definite. Eppure la maggior parte dei team non ha un sistema: sette copie di Budget_Finale.xlsx sparse in tre strumenti diversi non sono un problema di tecnologia, sono un problema di decisioni. Una gestione efficace si fonda su cinque abitudini: un albero di cartelle piatto e prevedibile (non più di tre livelli), una convenzione di denominazione scritta applicata dall'onboarding, un'unica fonte di verità per tipo di file, la retention delle versioni per almeno 180 giorni e un'archiviazione pianificata alla chiusura del progetto.

La regola dei tre livelli di profondità

Oltre tre livelli di cartelle, i file diventano irrintracciabili. Fai una prova: un membro del team riesce a trovare il deck della design review del secondo trimestre 2026 in meno di 30 secondi? Se il percorso è /Clienti/Acme/2026/Q2/Design/Revisioni/Giugno/Deck_v3.pptx, la risposta è no.

Una struttura funzionale si presenta così:

/Progetti
  /2026-Q2-Acme-Rebrand
    /01-brief
    /02-bozze
    /03-finale
    /04-archivio

I prefissi numerici impongono l'ordine di ordinamento, il nome della cartella di progetto codifica trimestre e cliente così la ricerca lo trova immediatamente, e le quattro sottocartelle corrispondono agli stati reali del workflow. I team che adottano questo schema riducono i messaggi "dov'è il file?" su Slack del 60-80% nel primo mese.

Convenzioni di denominazione che reggono il contatto con la realtà

Una convenzione di denominazione funziona solo se ogni membro del team può applicarla senza pensarci. Il formato che funziona nella maggior parte dei settori:

AAAA-MM-GG_CodiceProgetto_TipoDoc_Descrittore_vNN.ext

Esempio: 2026-06-12_ACME-RB_brief_ambito-lavoro_v03.pdf

Cinque regole rendono questo sistema sostenibile:

Date ISO 8601 (AAAA-MM-GG) — si ordinano correttamente e si interpretano in qualsiasi locale
Codici progetto, non nomi completi — ACME-RB batte "Acme Rebrand 2026 Project Files"
Niente spazi — usa trattini o underscore, mai entrambi nello stesso campo
Numeri di versione a due cifre — v03 si ordina correttamente oltre v09, v3 no
Minuscolo dove possibile — la sensibilità alle maiuscole crea problemi su certi filesystem

Mettila per iscritto. Inseriscila nel documento di onboarding. Rivedi i file non conformi nel sync settimanale di progetto per due settimane — dopo diventa automatico.

Fonte di verità e copie di lavoro

Ogni file in un progetto rientra in uno di due contenitori: il file canonico oppure una copia di lavoro. Il file canonico è quello che viene consegnato, fatturato, revisionato dagli stakeholder. Le copie di lavoro sono bozze, rami, esperimenti.

Il principale fallimento nella gestione dei progetti è perdere di vista quale copia è quella canonica. Rimedi:

Blocca il file canonico: la maggior parte dei DAM (Bynder, Frontify) e anche Dropbox hanno il blocco al check-out. Il check-in/check-out di SharePoint è sottoutilizzato ma solidissimo.
Nomina le copie di lavoro con un prefisso del proprietario: mrossi_WIP_2026-06-12_ACME-RB_hero.psd
Sposta gli asset finalizzati in 03-finale e cancella le versioni di lavoro a fine sprint. Non archiviare: cancella. Gli archivi vengono saccheggiati come "punti di partenza" e il problema ricomincia.

Tracciamento dei file tra strumenti

I progetti reali attraversano Jira, Linear, Notion, Slack, Google Drive e un portale clienti. Un file citato in un ticket Jira vive in Drive; lo stesso file viene condiviso in Slack, incorporato in una pagina Notion e consegnato via link Dropbox al cliente. Tracciare dove si trovano le copie è impossibile manualmente.

Due approcci aiutano:

Condividi link, non allegati: se il file canonico è in Drive, condividi il link Drive ovunque. Allegarlo in Slack crea una copia divergente che diventa subito obsoleta.
Usa uno strato di metadati file: strumenti come database Airtable o Notion con una base "File" possono catalogare ogni asset canonico con colonne per proprietario, stato, data ultima revisione, policy di retention e link esterni.

Retention delle versioni e rollback

La maggior parte degli strumenti di sincronizzazione mantiene una cronologia versioni limitata per impostazione predefinita: Google Drive conserva 100 versioni o 30 giorni sul piano gratuito, Dropbox Business 180 giorni, Box 50 versioni su Business. Per i progetti regolamentati dalla limitazione della conservazione ai sensi dell'Art. 5(1)(e) del GDPR, serve una policy che corrisponda alla normativa, non all'impostazione predefinita dello strumento.

I drill di rollback sono la versione senza glamour del disaster recovery. Una volta al trimestre, chiedi a qualcuno di scegliere un file di progetto a caso, di dichiarare che è stato corrotto ieri, e di misurare quanto tempo ci vuole per ripristinare la versione precedente. Se ci vogliono più di 10 minuti, il tuo processo di retention ha delle lacune.

Gestione dei deliverable grandi e degli invii esterni

I deliverable finali raramente passano per e-mail. Un montaggio video in 4K pesa oltre 40 GB, un pacchetto sorgente PSD completo con livelli arriva a 2-10 GB, i file BIM architetturali raggiungono abitualmente i 5 GB. Il sistema di gestione dei progetti deve prevedere un protocollo chiaro di consegna del deliverable.

Il pattern che funziona: i file canonici rimangono nel DAM o nello strumento di sincronizzazione, ma la consegna finale al cliente avviene tramite un servizio di trasferimento dedicato con tracciamento. HexaTransfer permette di inviare fino a 10 GB con scadenza del link, ricevuta di download e crittografia AES-256-GCM lato client — il provider non può accedere al contenuto. Proteggi con password qualsiasi consegna al cliente per impostazione predefinita, anche per file non sensibili: costringe il destinatario a confermare di aver ricevuto il link giusto.

Archiviazione: il passaggio che tutti saltano

I progetti finiscono. I file no. Un anno dopo la chiusura di un progetto, hai ancora bisogno di rispondere "qual era il logo finale che abbiamo consegnato ad Acme?" ma il disordine operativo in /Progetti/2026-Q2-Acme-Rebrand/02-bozze/ è ora 14 GB di rumore.

La disciplina di archiviazione alla chiusura del progetto:

Copia 03-finale in /Archivio/AAAA/CodiceCliente/ come sola lettura
Esporta un manifesto di progetto: un file .md che elenca ogni asset finale, il suo scopo e lo stakeholder che l'ha approvato
Elimina 02-bozze a meno che la normativa non richieda la conservazione
Imposta un promemoria nel calendario a 12 mesi per rivalutare la retention dell'archivio

Quel manifesto è il documento più utile per chiunque si occuperà di un cliente ricorrente. Spendi i 30 minuti alla chiusura — il te del futuro ti ringrazierà.

Prova HexaTransfer su hexatransfer.com — gratuito, senza account, massimo 10 GB.