Come scrivere un capitolato per software su misura

Un capitolato per un software su misura si scrive in cinque blocchi: il problema da risolvere con il perimetro di cosa è incluso e cosa no, i processi aziendali descritti come si svolgono oggi, le integrazioni con i sistemi già in uso, i dati da migrare e i criteri con cui il lavoro verrà accettato. Non serve descrivere la soluzione tecnica, che è il mestiere del fornitore: serve descrivere il problema in modo che due fornitori diversi capiscano la stessa cosa. Un documento scritto così produce preventivi confrontabili invece che cifre distanti fra loro del doppio.

Se hai chiesto tre preventivi per lo stesso gestionale e hai ricevuto numeri che non si somigliano, il problema quasi mai è il prezzo: è che i tre fornitori hanno immaginato tre progetti diversi. Alla fine di questa guida avrai la struttura del documento e saprai quali decisioni prendere prima di mandarlo in giro.

Cosa serve prima di iniziare

• Il processo che vuoi coprire, osservato davvero: chi fa cosa, con quale strumento, in quale ordine. Se la descrizione arriva solo dalla direzione, mancherà la metà delle eccezioni che il software dovrà gestire.
• L'elenco dei sistemi già in uso che il nuovo software dovrà toccare, con il nome del referente di ciascuno e l'informazione se dispongono di API.
• Un campione dei dati esistenti: qualche export reale, non un file di esempio ripulito. Serve a capire in che stato sono davvero.
• I vincoli non negoziabili: budget massimo, data oltre la quale il progetto perde senso, obblighi di conservazione dei dati, sistemi che non si possono sostituire.
• Il nome di chi decide. Una persona sola, con la possibilità di dire sì e no. È il vincolo che influisce di più sui tempi.

1. Il perimetro: scrivi anche cosa non è compreso

La sezione più utile di un capitolato è quella che dice cosa il progetto non farà. È anche quella che quasi nessuno scrive.

Descrivi l'obiettivo in tre righe, in termini di risultato aziendale e non di funzioni: ridurre il tempo di preparazione di un ordine, avere un unico archivio clienti, smettere di ridigitare i dati fra due sistemi. Il risultato atteso è una frase che chiunque in azienda riconosce come vera.

Elenca cosa è fuori perimetro in modo esplicito: la contabilità resta dov'è, il sito pubblico non si tocca, la app per i clienti finali si valuterà in una fase successiva. A questo punto avrai eliminato la principale fonte di sorprese in fase di preventivo, perché ogni fornitore starà quotando lo stesso lavoro.

Indica le fasi, se il progetto ne ha più di una, e cosa deve essere in funzione alla fine della prima. Un capitolato che descrive un traguardo unico a dodici mesi produce un preventivo unico a dodici mesi, che è il modo più rischioso di comprare software.

2. I requisiti: descrivi i processi, non le schermate

Qui si decide la qualità del documento. La differenza è fra "serve una schermata con l'elenco degli ordini e un filtro per stato" e "l'addetto deve poter vedere in un colpo d'occhio quali ordini della settimana non sono ancora partiti".

Scrivi un paragrafo per ogni processo, seguendo la sequenza reale: cosa arriva, chi lo prende in carico, quali controlli fa, cosa produce, dove finisce. Descrivi anche il caso in cui qualcosa va storto, perché è lì che i software generici si rompono.

Segna le eccezioni con una riga dedicata. Il cliente che paga a trenta giorni tranne due che pagano a novanta, l'ordine urgente che salta la coda, la pratica che a volte torna indietro di due passi. Le eccezioni sono il motivo per cui stai valutando un software su misura invece di uno a pacchetto: se non le scrivi, stai chiedendo un preventivo per un pacchetto.

Distingui i requisiti obbligatori da quelli desiderabili, con due sole etichette. Serve al fornitore per proporre una prima fase sensata, e serve a te quando il preventivo supera il budget: taglierai dalla lista dei desiderabili invece di rinegoziare tutto.

Aggiungi i numeri che descrivono la scala: quanti utenti contemporanei, quanti documenti al mese, quante righe ha l'anagrafica. Un archivio da tremila record e uno da tre milioni richiedono scelte tecniche diverse, e senza il numero il fornitore ipotizza.

3. Le integrazioni: il capitolo che decide i costi

Nei progetti gestionali le integrazioni sono la voce che più spesso viene sottovalutata, perché sembrano dettagli tecnici e invece sono lavoro vero.

Per ogni sistema da collegare, scrivi quattro cose: quale sistema è, in che direzione viaggiano i dati, con quale frequenza devono essere allineati, chi è il referente da contattare. Il risultato atteso è una tabella che il fornitore può leggere senza fare domande preliminari.

Verifica prima se esiste un modo documentato di scambiare dati. Se il sistema esistente non espone API e l'unico canale è un export manuale, questo cambia il costo dell'integrazione in modo sostanziale e va scritto nel capitolato, non scoperto a metà progetto.

Dichiara quale sistema comanda su ciascun dato. Se l'anagrafica cliente esiste in due posti, uno dei due deve essere la fonte e l'altro la copia. Questa singola riga previene la categoria di problemi più fastidiosa dopo il lancio, cioè due archivi che divergono lentamente senza che nessuno se ne accorga.

4. Dati esistenti e migrazione

Indica da dove arrivano i dati e in che formato: fogli di calcolo, database di un sistema in uso, archivi cartacei da digitalizzare. Allega un campione reale anonimizzato, con nomi di fantasia e contatti tipo mario.rossi@esempio.it, così il fornitore vede la qualità effettiva.

Decidi quanto storico portare. La regola pratica è tutta l'anagrafica attiva e uno o due anni di movimenti; il resto resta in un archivio consultabile. Migrare dieci anni raddoppia il lavoro di pulizia in cambio di dati che si consultano una volta l'anno.

Chiarisci chi fa la pulizia dei duplicati. È un lavoro noioso che qualcuno deve fare: se non è scritto, verrà quotato dal fornitore a tariffa oraria oppure ricadrà su di te in una settimana in cui non avevi previsto di lavorarci.

5. Requisiti non funzionali e criteri di accettazione

Scrivi le tre o quattro condizioni tecniche che contano davvero: dove risiedono i dati, chi accede a cosa, con quale frequenza si fanno i backup e in quanto tempo si deve poter ripristinare, quali prestazioni sono accettabili sulle operazioni più frequenti. Evita gli elenchi copiati da altri documenti: un requisito che non sai verificare è un requisito che non esiste.

Definisci i criteri di accettazione come prove concrete. Non "il sistema deve essere affidabile", ma "un operatore inserisce un ordine completo di cinque righe, il documento si genera e arriva al cliente, il magazzino si aggiorna". Il risultato atteso è un elenco di prove che si eseguono in un pomeriggio davanti a un tavolo, con esito sì o no.

Metti la procedura di variazione: chi può chiedere una modifica, come viene valutata, entro quanto arriva la risposta con l'impatto su tempi e costi. È la sezione che tiene insieme il progetto quando emerge la funzione a cui nessuno aveva pensato.

Varianti: come cambia il documento a seconda del progetto

Se stai facendo un gestionale interno, il peso sta sui processi e sui ruoli: chi vede cosa, chi approva cosa. Dedica una tabella ai profili utente con i permessi principali.

Se stai facendo un'app per clienti finali, il peso si sposta sull'esperienza d'uso e sui casi limite: registrazione, recupero password, comportamento senza rete, notifiche. Aggiungi i dispositivi e le versioni di sistema che devono essere supportati, perché incidono direttamente sul lavoro di test.

Se il progetto è soprattutto integrazione fra sistemi esistenti, il capitolato diventa quasi tutto tabella dei flussi: origine, destinazione, campi, frequenza, cosa succede se un sistema non risponde. Qui l'errore tipico è descrivere il caso normale e tacere sulla gestione degli errori, che è dove sta metà del lavoro.

Errori comuni

Descrivere la soluzione invece del problema. Un capitolato che dice "serve un menu a tendina con questi valori" ha già deciso l'interfaccia, spesso copiandola dallo strumento attuale con i suoi limiti. Descrivi cosa deve ottenere l'utente e lascia che sia il fornitore a proporre come.

Usare aggettivi al posto dei numeri. Veloce, intuitivo, scalabile, moderno: sono parole che in fase di collaudo non si possono verificare e in fase di preventivo ognuno interpreta come vuole. Ogni volta che ne scrivi uno, sostituiscilo con una misura o con una prova.

Rimandare le decisioni difficili al fornitore. Se non hai deciso se la fatturazione resta nel sistema attuale, il preventivo conterrà un'ipotesi. Le ipotesi non prese diventano varianti in corso d'opera, e le varianti in corso d'opera costano più che decidere prima.

Quanto tempo serve

Per un gestionale di reparto in una PMI, la stesura richiede in genere da una a tre settimane: qualche ora di osservazione dei processi con chi li esegue, un paio di riunioni per le decisioni sul perimetro, e una giornata per scrivere. La parte lunga non è la scrittura ma le decisioni, ed è tempo che il progetto ti chiederà comunque, prima o durante.

Ora che hai il documento, il passo successivo è capire come verrà usato dall'altra parte: la struttura di un progetto in fasi e i tempi realistici sono descritti nella guida al processo di sviluppo e in quella sui tempi di realizzazione, entrambe collegate qui sotto. Se stai ancora valutando se ti serve un software su misura o una soluzione già pronta, quella decisione viene prima del capitolato e conviene prenderla con i numeri del tuo processo davanti.

Le indicazioni di questa guida riguardano il contenuto tecnico e organizzativo del documento. Per la parte contrattuale, cioè penali, proprietà del codice sorgente, garanzia e manutenzione, confrontati con un legale di fiducia prima della firma.