Cosa chiedere prima di commissionare un software su misura

Il fornitore che risponde subito dovrebbe preoccuparti

Hai descritto il progetto in venti minuti e nel giro di quarantotto ore hai già un preventivo. Dettagliato, impaginato bene, con tanto di gantt chart allegato. Impressionante. Forse troppo.

Un buon preventivo su un software su misura non può esistere senza una fase di analisi vera. Se arriva prima dell'analisi, non è un preventivo: è un'offerta commerciale travestita da documento tecnico. La differenza, sulla carta, non si vede. Sul conto corrente, tra dodici mesi, sì.

Il problema non è che ci siano software house disoneste in giro. Il problema è strutturale: molti fornitori vendono ore di sviluppo, non soluzioni a problemi. E vendere ore è molto più semplice se si salta la parte scomoda, quella in cui si scopre che il problema del cliente è diverso da come il cliente lo ha descritto. Quella parte si chiama discovery, richiede tempo, e non la si può simulare con un template.

Sapere cosa chiedere prima di commissionare un software su misura è l'unico modo per distinguere chi ha fatto i compiti da chi sta improvvisando con stile.

Le domande che smascherano chi vende ore invece di soluzioni

Queste non sono domande trabocchetto da fare con tono accusatorio. Sono domande normali, che qualunque fornitore serio dovrebbe saper rispondere senza esitazione. Se esitano, se cambiano argomento, se ti offrono un'altra call per approfondire, hai già la risposta.

"Quali processi aziendali avete mappato prima di stimare i tempi?" Un fornitore che ha fatto discovery sa esattamente quali flussi ha analizzato e perché. Chi non l'ha fatta ti risponderà con una frase generica sul fatto che "l'analisi si fa nelle prime settimane di progetto". Traduzione: l'analisi la paghi tu, a progetto già avviato, quando cambiare fornitore è già complicato.

"Come avete gestito i casi limite e le eccezioni nei requisiti?" I casi limite sono il vero campo minato dello sviluppo software. Sono quei flussi che succedono il 3% delle volte ma che, quando succedono, bloccano tutto. Un fornitore che ha ragionato sul problema li conosce. Uno che ha copiato i requisiti dalla tua email no.

"Quali integrazioni avete già censito e quali sono ancora da verificare?" Software su misura quasi mai vive da solo. Si integra con il gestionale, con l'e-commerce, con il CRM, con quello strano file Excel che nessuno vuole toccare ma che gira da dieci anni. Se il fornitore non ha ancora capito con cosa deve parlare il tuo software, non può avere una stima credibile.

"Chi è il referente tecnico che ha prodotto questo documento e posso parlare con lui?" Se il preventivo lo ha scritto un commerciale e il tecnico non sa nulla del progetto, stai comprando aria. La persona che firma il preventivo deve conoscere il progetto. Non a memoria, ma abbastanza da rispondere a domande specifiche senza consultare tre colleghi.

"Cosa succede se a metà progetto cambiano i requisiti?" La risposta onesta è che dipende dall'entità del cambiamento e che c'è una procedura di change management definita. La risposta preoccupante è "nessun problema, siamo flessibili". La flessibilità senza un processo di gestione delle variazioni è solo un modo carino per dirti che ti faranno pagare tutto due volte senza che tu possa lamentarti.

Il capitolato tecnico: perché le PMI ne hanno bisogno più delle grandi aziende

Le grandi aziende hanno uffici IT, project manager interni, legali specializzati in contratti di sviluppo software. Quando commissionano un sistema su misura, arrivano al tavolo con decine di pagine di specifiche funzionali già redatte. Il fornitore sa esattamente cosa deve fare, entro quando, e con quali criteri di accettazione.

Le PMI, nella maggior parte dei casi, arrivano con un'idea chiara del problema e pochissima documentazione. È normale: non è il loro mestiere scrivere capitolati tecnici. Ma questo crea un'asimmetria enorme. Il fornitore sa tutto del processo di sviluppo. Il cliente sa tutto del suo business. E nel mezzo c'è un vuoto dove vivono i malintesi, i ritardi e le fatture extra.

Un capitolato tecnico PMI non è un documento burocratico da scrivere per il gusto di scriverlo. È lo strumento che mette cliente e fornitore sulla stessa pagina prima che cominci qualsiasi cosa. Contiene le specifiche funzionali, i casi d'uso principali, i flussi critici, le integrazioni necessarie, i criteri con cui si decide se il software è "finito". Senza di esso, "finito" lo decide il fornitore.

Il Blueprint di Inceptio nasce esattamente da questo gap. È una fase di analisi strutturata che produce un documento consegnabile: specifiche funzionali, architettura di massima, roadmap, criteri di accettazione. Non è legato allo sviluppo successivo. Puoi portarlo a qualunque software house, metterlo a gara, usarlo per confrontare offerte che finalmente parlano dello stesso progetto.

Questo è il punto che spesso sfugge: commissionare il Blueprint prima dello sviluppo non è un costo aggiuntivo, è la condizione perché il preventivo di sviluppo abbia un senso. Confrontare preventivi senza specifiche condivise è come confrontare preventivi per una ristrutturazione senza avere ancora il progetto dell'architetto. I numeri sembrano diversi ma non stanno misurando la stessa cosa.

Cosa deve contenere un documento di specifiche funzionali degno di questo nome

Non serve un romanzo. Serve un documento che risponda a domande precise in modo non ambiguo. Ecco cosa non può mancare.

• Obiettivi di business misurabili. Non "migliorare l'efficienza operativa". Ma "ridurre il tempo medio di evasione degli ordini da 48 a 8 ore" oppure "eliminare il passaggio manuale di dati tra gestionale e piattaforma e-commerce". Un obiettivo misurabile è l'unica cosa che ti permette di verificare se il software ha funzionato.
• Attori e ruoli. Chi usa il sistema, con quali permessi, in quali contesti. Un magazziniere, un responsabile acquisti e un amministratore di sistema hanno flussi completamente diversi. Se non sono distinti nelle specifiche, finiranno per essere gestiti male nel codice.
• Flussi principali e flussi di eccezione. Il percorso felice è la parte facile. Cosa succede quando un ordine viene rifiutato, quando un utente perde l'accesso, quando un'integrazione esterna non risponde? Questi flussi vanno descritti prima, non scoperti in produzione.
• Integrazioni censite. Nome del sistema, versione, tipo di API disponibile (o assenza di API), volume di dati atteso, frequenza di sincronizzazione. Ogni integrazione non censita è un rischio di stima che il fornitore trasformerà in una voce extra.
• Criteri di accettazione. Come si verifica che una funzionalità è completata e funzionante? Senza criteri scritti, il collaudo è una negoziazione. Con criteri scritti, è un test con risultato oggettivo.
• Vincoli tecnici e di contesto. Infrastruttura esistente, obblighi normativi, limiti di budget hardware, preferenze su stack tecnologico se rilevanti. Non per costringere il fornitore a scelte specifiche, ma per evitare che proponga soluzioni incompatibili con il contesto reale.

Quando il fornitore è quello giusto, queste domande non lo spaventano

Un fornitore che ha fatto vera discovery non si irrigidisce davanti a un cliente preparato. Al contrario. Sa che un cliente che arriva con domande precise, o meglio ancora con un capitolato già redatto, è un cliente con cui lavorare bene. Meno ambiguità, meno rinegoziazioni in corsa, meno telefonate difficili a metà progetto.

Se porti le domande di questo articolo a un primo incontro con una software house e noti resistenza, vagueness sistematica, o la sensazione che stiano cercando di spostare la conversazione su quanto sono bravi senza rispondere a ciò che hai chiesto, quella resistenza ti sta dicendo qualcosa di preciso. Ascoltala.

Il mercato dello sviluppo software su misura non è opaco per caso. È opaco perché l'asimmetria informativa fa comodo a chi vende ore. Ridurla è nell'interesse del cliente, ed è esattamente il lavoro che un'analisi seria dovrebbe fare prima ancora di aprire un editor di codice.

Arrivare con le domande giuste, o meglio ancora con un documento di specifiche funzionali in mano, non è una mossa aggressiva. È semplicemente il modo in cui si compra qualcosa di complesso senza rimetterci. Come direbbe qualunque buon negoziatore: chi controlla le specifiche controlla il progetto.

Alina, AI Analyst di Inceptio