1. Come accade solitamente
La scena è familiare: fine progetto, tutti stanchi, qualcuno scrive “ti ho mandato tutto” su Slack e allega un link a una cartella condivisa chiamata final_v3_ok_definitivo. Dopo qualche settimana emergono domande: mancava una feature? L’API era completa? I test erano inclusi? La documentazione era aggiornata?
Nel mondo SaaS la consegna è ancora più sfumata. A volte non c’è un file da scaricare: c’è un ambiente accessibile, una dashboard, un endpoint, un modello AI in produzione. Il cliente dice “non funziona come concordato”, il fornitore risponde “è esattamente ciò che abbiamo rilasciato”. Senza una fotografia precisa del momento della consegna, la discussione diventa una partita a memoria.
Un aneddoto tipico: un team consegna un sistema AI con prompt e logiche interne ben strutturate. Il cliente modifica alcuni parametri “solo per provare”. Due mesi dopo, i risultati sono diversi e nessuno ricorda più quale fosse la configurazione originale. A quel punto la domanda non è più tecnica, è storica: cosa esisteva davvero il giorno della consegna?
Un punto di vista meno ovvio: anche ciò che non è stato consegnato conta. Funzionalità escluse, limitazioni dichiarate, parti ancora in sviluppo. Spesso le incomprensioni nascono proprio lì.
2. Cosa devi dimostrare
L’obiettivo è costruire una prova credibile del contenuto effettivo della consegna in un preciso momento.
Può essere utile dimostrare:
- quali file o componenti sono stati consegnati;
- la versione esatta del codice o del software;
- lo stato dell’applicazione o del servizio al momento del rilascio;
- le funzionalità incluse e quelle escluse;
- il contenuto della documentazione tecnica allegata;
- le configurazioni, parametri o prompt usati (soprattutto in sistemi AI);
- le modalità di accesso fornite (account, credenziali, URL, ambienti);
- cosa è stato comunicato al cliente su “cosa include la consegna”;
- eventuali limitazioni o condizioni esplicitate.
In sostanza, devi poter rispondere in modo concreto alla domanda: “cosa c’era dentro la consegna, esattamente quel giorno?”
3. Cosa raccogliere
Serve un pacchetto completo, che tenga insieme parte tecnica e parte comunicativa.
Raccogli:
- codice sorgente o export del repository (ZIP);
- build rilasciata o pacchetto deployato;
- documentazione tecnica in PDF o Markdown;
- file README con descrizione della consegna;
- screenshot della piattaforma, dashboard o interfaccia;
- video brevi che mostrano le funzionalità principali;
- elenco delle API e relativa documentazione;
- configurazioni, file .env, parametri o prompt rilevanti;
- report di test o checklist di consegna;
- e-mail di consegna inviate al cliente;
- chat esportate (Slack, Teams, ecc.) con conferme o chiarimenti;
- contratti, offerte e specifiche funzionali;
- eventuali ticket o task chiusi legati alla consegna;
- log o report che mostrano lo stato del sistema al rilascio.
Un dettaglio spesso trascurato: salva anche la struttura delle cartelle e i nomi originali dei file. Cambiare i nomi dopo rende più difficile ricostruire il contesto.
4. Come procedere
Prima di consegnare, prepara tu la narrativa tecnica della consegna. Non lasciare che sia ricostruita dopo, quando le versioni si sono già mescolate.
Crea una cartella dedicata alla consegna, con un nome chiaro e una data. Inserisci tutto ciò che rappresenta il “pacchetto consegnato”. Aggiungi un README che spiega cosa contiene, come usarlo e cosa aspettarsi.
Procedura pratica:
- identifica cosa fa parte della consegna e cosa resta fuori;
- esporta codice, build e documentazione nella versione esatta rilasciata;
- aggiungi un README descrittivo e leggibile;
- includi prove visive come screenshot o video;
- raccogli le comunicazioni di consegna (e-mail, chat);
- crea un archivio ZIP completo della consegna;
- attesta il pacchetto e i documenti principali;
- invia la consegna usando canali tracciabili (e-mail, sistemi di ticketing);
- conserva una copia interna identica a quella inviata.
Se la consegna è un servizio SaaS o un sistema AI online, documenta lo stato con screenshot, export di configurazioni e video di utilizzo. È come fotografare una stanza prima di consegnare le chiavi: dopo, qualcuno potrebbe spostare i mobili.
5. Errori da evitare
Molte difficoltà nascono da consegne informali o frammentate.
Errori frequenti:
- consegnare tramite link modificabili senza salvare una copia statica;
- inviare file sparsi in più messaggi senza un pacchetto unico;
- aggiornare i file dopo la consegna senza distinguere le versioni;
- non documentare cosa è escluso dalla consegna;
- affidarsi solo a comunicazioni verbali o call;
- dimenticare configurazioni, dipendenze o parametri chiave;
- usare nomi ambigui come ultima_versione_buona.zip;
- non conservare le comunicazioni di consegna.
Oltre all’attestazione tecnica, cura anche il processo: definisci chiaramente cosa significa “consegna completata”, usa checklist interne, e fai confermare per iscritto la ricezione. L’attestazione gratuita è utile perché consente di fissare rapidamente il contenuto della consegna senza appesantire il flusso operativo.
6. Dopo la documentazione
Dopo aver documentato la consegna, mantieni una linea chiara tra versione consegnata e sviluppi successivi. Ogni modifica dovrebbe generare una nuova versione, con un nuovo pacchetto e una nuova documentazione.
Condividi internamente il materiale con team tecnico e management, così tutti sanno cosa è stato effettivamente rilasciato. Se emergono contestazioni, raccogli subito i documenti già preparati e valuta il coinvolgimento di consulenti tecnici o legali a livello europeo.
Se lavori con clienti o partner, usa questa pratica come standard: consegne più chiare, meno discussioni, e una memoria tecnica che non dipende da “chi si ricorda meglio”. In fondo, nei progetti software la memoria è utile, ma i file salvati al momento giusto lo sono molto di più.