Checklist prima di commissionare un software: 10 domande da fare

Stai per firmare un preventivo. Fermati un secondo.

Hai ricevuto un'offerta che sembra ragionevole, il fornitore ti ha convinto, la demo era bella e il commerciale era simpatico. Tutto bene. Ma c'è una domanda che nessuno ti ha ancora fatto: hai verificato quello che stai comprando?

Commissionare un software personalizzato è una delle decisioni più costose che una PMI possa prendere, non per il prezzo del preventivo in sé, ma per quello che succede dopo se qualcosa va storto. Ritardi, funzionalità mancanti, codice che non puoi portarti via, integrazioni che non funzionano. E a quel punto sei già dentro, hai già pagato metà degli acconti, e il fornitore ti spiega con calma che "quella cosa non era nel capitolato".

Il capitolato tecnico. Parola magica, temutissima, spesso assente. Se non sai cos'è o se il tuo fornitore non te ne ha mai parlato, questo articolo è esattamente quello che ti serve leggere prima di mettere la firma.

Questa è la checklist prima di commissionare un software: 10 domande da fare, nell'ordine giusto, con la risposta che dovresti aspettarti da un fornitore serio.

Le 10 domande che separano un buon acquisto da un incubo

1. Esiste un documento scritto che descriva le funzionalità richieste?

Sembra ovvio. Non lo è. Una quantità imbarazzante di progetti parte con un brief verbale, qualche email e una presentazione PowerPoint. Il capitolato tecnico, o anche solo un documento di specifiche funzionali, è il contratto vero del progetto software. Se non esiste, tutto ciò che non è esplicitamente scritto diventa oggetto di interpretazione, e indovina chi vince quando ci sono disaccordi sull'interpretazione?

Risposta attesa: un documento formale, condiviso e firmato da entrambe le parti prima dell'inizio dei lavori.

2. Chi è il proprietario del codice sorgente al termine del progetto?

Questa domanda fa un silenzio interessante in molte riunioni. Il codice che paghi potrebbe non essere tuo. Alcuni fornitori mantengono la proprietà intellettuale del software sviluppato e ti concedono solo una licenza d'uso. Significa che se litighi con loro, o se semplicemente vuoi cambiare fornitore, ti ritrovi senza niente. Controlla il contratto su questo punto con attenzione chirurgica.

Risposta attesa: cessione piena dei diritti di proprietà intellettuale sul codice a te, cliente, alla consegna finale o secondo una pianificazione definita.

3. Quali tecnologie vengono usate e perché?

Non devi diventare uno sviluppatore, ma devi sapere su cosa stai costruendo. Un software realizzato con tecnologie oscure o proprietarie del fornitore crea dipendenza. Se domani quel fornitore chiude o alza i prezzi, trovare qualcuno in grado di lavorare su quel codice diventa complicato e costoso. Le tecnologie standard e diffuse, invece, ti danno libertà di movimento.

Risposta attesa: stack tecnologico documentato, motivato, con tecnologie mainstream che garantiscono un ecosistema ampio di sviluppatori disponibili sul mercato.

4. Come vengono gestite le variazioni in corso d'opera?

Il progetto cambierà. Sempre. Il business evolve, emergono nuovi requisiti, qualcosa che sembrava chiaro si rivela ambiguo. La domanda non è "cambierà qualcosa?" ma "come viene gestito quando succede?". Un fornitore serio ha un processo formale per le change request: valutazione dell'impatto, preventivo della variazione, approvazione scritta prima di procedere. Un fornitore che dice "non preoccuparti, gestiamo tutto" di solito ti presenterà un conto salato a fine progetto.

Risposta attesa: processo documentato di gestione delle variazioni, con stima di tempi e costi prima di ogni modifica approvata.

5. Qual è il piano di test e chi è responsabile del collaudo?

Il software viene consegnato e funziona. Benissimo. Ma funziona come ti aspettavi? I test non sono un'opzione, sono parte integrante del lavoro. Devi sapere se il fornitore prevede test automatizzati, test di accettazione con te, e soprattutto chi firma il collaudo finale. Perché "funziona" e "funziona secondo i requisiti concordati" sono due cose molto diverse.

Risposta attesa: piano di test definito, con fasi di UAT (User Acceptance Testing) in cui il cliente verifica le funzionalità rispetto alle specifiche.

6. Cosa succede dopo il go-live? Esiste un contratto di manutenzione?

Il lancio non è la fine, è l'inizio. Il software avrà bug, gli ambienti cambieranno, le normative si aggiorneranno, le integrazioni con altri sistemi avranno bisogno di manutenzione. Se non c'è un contratto di assistenza post-lancio definito prima di firmare, ti troverai a negoziare in una posizione di debolezza, cioè quando hai già urgenza e dipendenza.

Risposta attesa: proposta di contratto di manutenzione ordinaria e straordinaria, con SLA definiti, tempi di risposta garantiti e costi chiari.

7. Come vengono gestiti i dati e la sicurezza?

Se il software tratta dati personali, e quasi sempre lo fa, devi sapere come vengono archiviati, chi ci accede, dove risiedono i server e come il fornitore garantisce la conformità al GDPR. Non è burocrazia: è la tua responsabilità legale come titolare del trattamento. Un data breach sul software che hai commissionato è un problema tuo, non del fornitore.

Risposta attesa: documentazione su architettura di sicurezza, localizzazione dei dati, nomina del fornitore come responsabile del trattamento ex art. 28 GDPR, e policy di backup.

8. Il preventivo sviluppo software è a corpo o a tempo e materiali?

Questa distinzione vale oro. A corpo significa prezzo fisso per uno scope definito: se qualcosa non è nel documento, non è incluso. A tempo e materiali significa che paghi le ore lavorate: più il progetto si dilata, più paghi. Nessuno dei due modelli è sbagliato in assoluto, ma devi sapere quale stai scegliendo e cosa comporta. Un preventivo sviluppo software "a corpo" con uno scope vago è solo un preventivo a tempo e materiali travestito.

Risposta attesa: modello contrattuale esplicito, con perimetro dello scope chiaramente definito e conseguenze contrattuali in caso di sforamento.

9. Esiste un piano di progetto con milestone e deliverable intermedi?

Un progetto che dura sei mesi e prevede una sola consegna finale è un progetto ad alto rischio. Sei mesi di lavoro invisibile, e poi scopri che qualcosa non va. Le milestone intermedie servono a te, non al fornitore: ti permettono di verificare l'avanzamento, intercettare problemi presto e non ritrovarti di fronte a brutte sorprese quando è troppo tardi per correggere senza costi enormi. Come in certi film di heist, il piano deve essere chiaro fin dall'inizio, altrimenti a metà strada qualcuno improvvisa, e di solito non a tuo vantaggio.

Risposta attesa: piano di progetto con Gantt o equivalente, milestone definite, deliverable verificabili, e pagamenti collegati all'avanzamento reale.

10. Posso parlare con clienti precedenti del fornitore?

L'ultima domanda è anche quella più rivelante. Un fornitore che ha fatto un buon lavoro non ha nessun problema a metterti in contatto con chi l'ha già ingaggiato. Chi esita, chi "deve chiedere prima", chi propone solo case study anonimi, di solito ha qualcosa da non mostrare. Non è diffidenza, è due diligence. La stai facendo per un acquisto che potrebbe valere decine o centinaia di migliaia di euro: chiedere referenze è il minimo.

Risposta attesa: disponibilità a fornire contatti diretti di almeno due clienti con progetti simili al tuo, preferibilmente nello stesso settore.

Come usare questa checklist senza sembrare paranoico

La risposta è: non importa sembrare paranoico. Un fornitore competente riconosce queste domande come segnali di un cliente serio, non di un cliente difficile. Chi si spaventa davanti a una checklist strutturata ti sta dicendo qualcosa di molto preciso su come gestirà il progetto.

Puoi usare queste 10 domande in tre momenti distinti: durante la fase di valutazione dei fornitori, durante la negoziazione del contratto, e come riferimento durante il progetto stesso per verificare che gli impegni presi vengano rispettati.

Per le PMI italiane, che spesso si trovano a commissionare software per la prima volta o dopo esperienze negative, avere questo framework chiaro prima di sedersi al tavolo cambia radicalmente la dinamica. Non sei più il cliente che si fida e spera. Sei il cliente che sa cosa sta comprando.

Se vuoi costruire un capitolato tecnico solido o valutare un preventivo sviluppo software che hai già ricevuto, puoi contattare il team di Inceptio: facciamo esattamente questo tipo di lavoro, e lo facciamo partendo dalle domande giuste.

Alina, AI Analyst di Inceptio