C'è un momento, nei progetti di sviluppo software custom, che raramente viene raccontato: il giorno dopo il go-live.

Nei contratti che girano per il mercato italiano, il go-live è tipicamente la linea del traguardo. Il software viene consegnato, si fanno i test, si fa una breve formazione agli utenti, si firma l'accettazione, e da quel momento il rapporto tra committente e fornitore cambia natura. Quello che succede dopo è spesso lasciato a clausole generiche — "è previsto un periodo di garanzia di X giorni", "la manutenzione evolutiva è regolata da separato accordo" — che all'atto pratico significano poco.

Il problema è che, per un software custom che entra davvero in uso, il post-go-live è la fase più importante. Ed è anche quella in cui si concentra la maggior parte dei fallimenti.

Perché il post-go-live è il momento critico

Durante lo sviluppo, il software vive in un ambiente controllato: specifiche definite, dati di test puliti, pochi utenti, interazione ravvicinata tra sviluppatori e committente. Il go-live espone il software a un mondo molto diverso: utenti reali con abitudini imprevedibili, dati sporchi accumulati negli anni, casi d'uso che nessuno aveva descritto nelle specifiche perché erano dati per scontati.

Nei progetti che abbiamo seguito, una regola empirica torna costantemente: il primo mese di uso reale fa emergere un numero di affinamenti necessari pari ad almeno il 15-20% del lavoro fatto durante tutto lo sviluppo. Non sono bug in senso stretto — sono correzioni di tiro, piccoli adattamenti a come il software incontra la realtà di chi lo usa. Se non vengono fatte, il software resta tecnicamente funzionante ma poco usato. E un software poco usato è un investimento perso.

Cosa succede realmente nei primi tre mesi

Proviamo a nominare cosa emerge concretamente.

Bug sottili su percorsi non testati

Il software è stato testato sui percorsi d'uso principali. Nel momento in cui entra in produzione, una quindicina di utenti diversi iniziano a usarlo in modi che i tester non avevano previsto: combinazioni di input non considerate, ordine diverso delle operazioni, reazione a errori intermedi. Ne emergono bug che non sono disastrosi ma che, se non risolti, frustrano gli utenti e vengono ricordati per anni.

Casi d'uso non coperti

La specifica era corretta al 95%. Quel 5% mancante, che in fase di design sembrava marginale, all'atto pratico risulta essere proprio il caso che un reparto usa quotidianamente. Non è un errore di nessuno: è un limite fisiologico della specifica scritta rispetto alla pratica reale. Richiede una piccola evoluzione, veloce, ma va fatta.

Prestazioni su dati reali

Il software è stato sviluppato su dataset di test. Sui dati di produzione — più grandi, meno puliti, con relazioni storiche complesse — alcune operazioni vanno più lente del previsto. Serve ottimizzare, indicizzare, a volte riprogettare piccole parti.

Adattamento dell'abitudine degli utenti

Alcune persone in azienda si adattano velocemente, altre no. Chi non si adatta spesso non si lamenta direttamente — semplicemente torna a usare il vecchio modo. Se nessuno interviene, nei due o tre mesi successivi il nuovo software viene de facto abbandonato da una parte dell'organizzazione.

Cosa c'è di solito nei contratti standard

In molti contratti di sviluppo che abbiamo visto (non nostri), il post-go-live è coperto da una combinazione di:

  • Un periodo di garanzia, tipicamente 30-90 giorni, che copre solo bug "bloccanti" — una categoria volutamente stretta.
  • Un contratto di manutenzione separato, facoltativo, che viene proposto dopo il go-live e che tipicamente richiede settimane di negoziazione aggiuntiva proprio nel momento in cui l'azienda sta cercando di stabilizzare il software nuovo.
  • Un tariffario a ore per tutto ciò che non rientra nella garanzia, che disincentiva il committente a segnalare problemi minori — proprio quelli che fanno la differenza sull'adozione.

Il risultato è un vuoto strutturale: il software è consegnato, ma i primi tre mesi critici sono la terra di nessuno tra garanzia stretta e manutenzione da rinegoziare.

Cosa dovrebbe invece contenere un buon accordo

Un contratto di sviluppo scritto bene non lascia il post-go-live all'improvvisazione. Dal nostro punto di vista, un buon accordo contiene almeno queste componenti:

Un piano di manutenzione scritto prima del go-live, non dopo. Deve far parte del progetto iniziale, non essere una trattativa nuova. Anche se il piano è leggero, il fatto che sia stato concordato toglie attrito nel momento peggiore.

Un canone mensile di riferimento (o un monte-ore annuale) che copra interventi prioritari di piccola entità, proporzionato alla dimensione del software. Non deve essere grande. Deve essere prevedibile.

Una definizione chiara di cosa rientra e cosa no. Bug di codice rientrano. Casi d'uso non inclusi nelle specifiche originali non rientrano a pieno titolo, ma sono gestiti con un processo rapido di valutazione invece che con una richiesta di nuovo contratto.

Un canale di comunicazione diretto con uno sviluppatore che conosce il progetto, non un helpdesk generico che rimbalza i ticket.

Un impegno di tempo minimo di presidio: anche pochi giorni al trimestre dedicati espressamente a fare piccoli affinamenti proattivi, non solo a rispondere a segnalazioni.

Un orizzonte di responsabilità esplicito: per quanti mesi o anni il software è "seguito" dal fornitore originale, e cosa succede dopo.

Come negoziare il post-go-live prima di firmare

Se stai per firmare un contratto di sviluppo software custom, queste sono le domande concrete da fare al fornitore, prima di firmare e non dopo:

  • Cosa succede se, il mese dopo il go-live, scopriamo che 3-4 cose vanno corrette perché all'uso reale non funzionano? Dovremo fare un nuovo contratto o è previsto dall'inizio?
  • Chi avrò come interlocutore dopo il go-live? La stessa persona che mi segue adesso?
  • Con che tempi di risposta posso aspettarmi che vengano risolti bug non bloccanti?
  • Per quanti anni mantenete i progetti che sviluppate? Qualche esempio concreto di progetti che state ancora seguendo da tempo?
  • Se tra due anni devo fare un'evoluzione importante, chi mi fa il preventivo — voi o devo ritrovare qualcuno da capo?

Le risposte a queste domande dicono di più sul fornitore di quello che dice tutto il preventivo messo insieme.

Il modello che seguiamo noi

Nel nostro modo di lavorare, il post-go-live è incluso nel progetto fin dall'inizio, non rinegoziato dopo. Concordiamo con il committente, già in fase di preventivo, una forma di presidio proporzionata alla dimensione del software: può essere un canone mensile per interventi prioritari, un monte-ore annuale da consumare a richiesta, o una formula mista.

Questa scelta nasce da un'osservazione concreta: i progetti software che abbiamo seguito da vicino dopo il rilascio sono quelli che sono effettivamente usati due anni dopo. Quelli lasciati soli dopo la consegna, nella maggior parte dei casi, vengono progressivamente abbandonati. È il motivo per cui, nel nostro modo di lavorare, non prendiamo progetti one-shot senza alcuna forma di continuità: non perché non sia possibile, ma perché sappiamo come va a finire.

I sei prodotti software che manteniamo direttamente sono, da questo punto di vista, il miglior banco di prova del modello: se siamo ancora capaci di sviluppare e far vivere sei software propri a distanza di anni, vuol dire che il post-go-live lo sappiamo gestire davvero.

Se stai valutando uno sviluppo custom

Se stai per commissionare un software custom e il contratto che hai davanti non parla in modo concreto di cosa succede dopo il go-live, prendi qualche giorno in più e chiedilo esplicitamente. È il pezzo del contratto che pesa di più sull'esito del progetto, ed è quello più spesso trascurato.

Se vuoi parlarne con noi prima di decidere, scrivici. Se vuoi capire come strutturiamo l'accordo fin dall'inizio, vedi la linea di sviluppo software.

Fabio Gabelli è il founder di Revan SAS e cura direttamente lo sviluppo e la manutenzione dei prodotti interni che Revan mantiene in produzione.