In sintesi: I progetti software falliscono raramente per un problema di codice: le cause vere sono specifiche vaghe, aspettative non allineate, fornitori che spariscono e budget che esplodono perché il software si vede funzionare solo alla fine. Il rimedio è un metodo preciso: analisi e specifiche costruite insieme, una demo del processo prima di firmare e pacchetti a risultato garantito. Così il rischio si sposta prima dell’impegno di spesa, non dopo.
Hai firmato un contratto per un gestionale su misura, hai versato l’acconto, e per tre mesi il silenzio. Poi arriva la prima versione e non assomiglia a quello che avevi in testa. Il fornitore dice che «è quello che c’era scritto», tu sei convinto del contrario, e nel frattempo il budget è già a metà. Se questa scena ti fa venire i brividi, non sei paranoico: è la paura numero uno di chiunque commissioni software, e ha ottime ragioni per esistere.
Da anni sentiamo la stessa frase in prima call: «L’ultima volta è andata male». Vale la pena capire perché i progetti software falliscono davvero, perché quasi mai il motivo è quello che sembra. E soprattutto vale la pena sapere che esiste un metodo per ribaltare le probabilità a tuo favore, ben prima di mettere mano al portafoglio.
Perché i progetti software falliscono: le cause vere
Quando un progetto va a sbattere, la reazione istintiva è dare la colpa alla tecnologia o alla bravura del programmatore. Nella nostra esperienza è quasi sempre altrove. Gli studi di settore lo ripetono da decenni: la maggioranza dei fallimenti nasce a monte, nella fase in cui si decide cosa costruire, non in quella in cui lo si scrive. Le cause ricorrenti sono poche e sempre le stesse:
- Specifiche vaghe. Il cliente descrive il risultato a grandi linee, il fornitore riempie i buchi con le proprie ipotesi. Due immaginazioni diverse che si scoprono tali solo alla consegna.
- Aspettative non allineate. Nessuno ha messo per iscritto cosa vuol dire «fatto», quindi ognuno ha la sua idea di quando il lavoro è finito.
- Nessuna verifica intermedia. Il software si vede funzionare per la prima volta alla fine. A quel punto correggere costa dieci volte di più che all’inizio.
- Il fornitore che sparisce. Consegna, incassa e diventa irreperibile quando serve una modifica o arriva un bug.
- Il budget che esplode. Ogni imprevisto diventa un extra, e senza un perimetro chiaro gli extra non finiscono mai.
Nota una cosa: quattro cause su cinque non hanno niente a che vedere con il codice. Sono problemi di metodo e di comunicazione. Ed è una buona notizia, perché i problemi di metodo si risolvono con un metodo.
Specifiche vaghe: il fraintendimento che costa di più
Immagina di dire a un artigiano «fammi un tavolo» e di aspettarti un tavolo da otto persone in noce, mentre lui costruisce un tavolino da caffè. Ha fatto un tavolo, no? Con il software succede esattamente questo, ma il tavolino da caffè è costato tre mesi di lavoro e non lo puoi restituire.
Il punto è che scrivere buone specifiche non è un compito del cliente da solo. Tu conosci il tuo processo meglio di chiunque, ma spesso lo dai talmente per scontato che ometti proprio i dettagli che contano. Chi sviluppa software di mestiere sa quali domande fare per far emergere quei dettagli. Le specifiche vere nascono da un dialogo, non da un documento consegnato oltre il muro. È esattamente il ragionamento che approfondiamo quando spieghiamo come funziona il software su misura per le PMI: la fase di analisi è un lavoro professionale a sé, non un preambolo da sbrigare in fretta.
Il fornitore che sparisce e il budget che esplode
C’è una domanda che quasi nessuno fa prima di firmare, e dovrebbe essere la prima: «Se domani tu chiudi, io cosa mi tengo in mano?». Se la risposta non è chiara, il rischio è enorme. Un software di cui non possiedi il codice sorgente, di cui non hai la documentazione e di cui non puoi toccare il database è un software che non controlli. Il giorno in cui il fornitore alza le tariffe, rallenta le risposte o semplicemente sparisce, sei bloccato.
Il budget che esplode è il fratello gemello di questo problema. Senza un perimetro scritto — cosa è incluso, cosa è un extra, cosa succede se cambiano i requisiti in corsa — ogni richiesta diventa una trattativa. E in una trattativa in cui il software è già mezzo fatto e i tuoi soldi sono già mezzo spesi, la parte debole sei tu. Per questo insistiamo tanto sui pacchetti a risultato garantito: il perimetro e il prezzo si concordano prima, non dopo.
Il metodo per non farlo succedere
Noi lavoriamo demo-first, e non è uno slogan: è la conseguenza diretta di aver visto troppi progetti andare male per le ragioni di sopra. Il metodo poggia su tre pilastri.
Analisi e specifiche costruite insieme. Prima di scrivere una riga di codice ci sediamo sul tuo processo. Non ti chiediamo di consegnarci un capitolato: ti facciamo le domande giuste finché il flusso non è chiaro a entrambi e messo nero su bianco. Questo è il momento in cui i fraintendimenti muoiono, quando costa poco farli morire.
Demo prima della firma del grosso. Ti mostriamo un prototipo funzionante del processo che ti sta più a cuore prima che tu impegni il budget principale. Vedere il tuo scadenzario, il tuo verbale o la tua fattura muoversi sullo schermo vale più di cento pagine di specifiche. Se qualcosa non torna, lo scopri quando cambiarlo è ancora economico.
Risultato garantito e proprietà del tuo software. Perimetro e prezzo concordati prima, codice sorgente e documentazione che restano tuoi. Se il domani porta un altro fornitore, il lavoro non riparte da zero.
Un esempio concreto di dove questo metodo fa la differenza. Per un organismo che esegue verifiche sugli impianti elettrici abbiamo costruito GestioneCommesse, un’applicazione che copre tutto il flusso dal preventivo al verbale tecnico generato in automatico dal loro modello Word, fino allo scadenzario che segnala in anticipo gli impianti da riverificare. Se avessimo interpretato «gestione delle commesse» a modo nostro, avremmo consegnato un gestionale generico e inutile. Ha funzionato perché il verbale, lo scadenzario e i solleciti li abbiamo disegnati sul loro modo di lavorare, verificandolo con loro passo dopo passo. Lo stesso vale per il software di verbali di sicurezza cantiere che abbiamo realizzato per uno studio di ingegneria nostro cliente: un flusso con firma sul signature pad e PDF immutabile non si indovina a tavolino, si costruisce guardando il coordinatore compilare il verbale in cantiere.
Quando conviene pretendere il risultato garantito
Non tutti i progetti hanno lo stesso profilo di rischio, ed è giusto essere onesti. Se stai automatizzando un processo che conosci a menadito e il perimetro è chiaro, il risultato garantito è la strada naturale: sai cosa vuoi, noi ci prendiamo l’impegno di consegnarlo. Se invece stai esplorando un’idea ancora fluida, ha più senso partire con una fase di analisi breve e un prototipo, e definire il perimetro definitivo solo dopo. In entrambi i casi la regola d’oro non cambia: vedere qualcosa di funzionante prima di impegnare il budget grosso.
Sul fronte dei numeri, la trasparenza aiuta a togliere ansia. Per una PMI un progetto su misura si colloca in genere tra 5.000 e 30.000 euro, a seconda di quanti flussi copre, di quante integrazioni servono e di quanti utenti lo usano. La manutenzione annua vale di norma il 15-20% del costo iniziale e comprende correzioni, aggiornamenti di sicurezza e assistenza. Sono fasce oneste per orientarti, non un listino: ogni progetto fa storia a sé e le cifre esatte escono solo dall’analisi. Ma sapere l’ordine di grandezza prima di iniziare è già un antidoto al budget che esplode. Se vuoi approfondire, ne parliamo anche in molta letteratura di project management, dove la gestione del perimetro è indicata da anni come il fattore che separa i progetti riusciti dagli altri.
La verità scomoda (e liberatoria)
La verità è che i progetti software non falliscono per sfortuna né per magia nera della tecnologia. Falliscono quando si salta il lavoro noioso ma decisivo che viene prima del codice: capirsi, scriverlo, verificarlo per pezzi. È scomodo perché toglie l’alibi «è colpa del programmatore», ma è liberatorio perché significa che il fallimento si può prevenire. Non serve fortuna: serve metodo, e il coraggio di pretendere di vedere prima di pagare.
Se ti sei ritrovato in almeno una delle scene di questo articolo, parliamone. Prenota una call gratuita di 20 minuti: ci racconti il processo che ti sta più a cuore e ti diciamo con onestà come lo affronteremmo, prototipo alla mano. Scrivici qui e mettiamo le probabilità dalla tua parte.
Domande frequenti sul perché i progetti software falliscono
Nella maggior parte dei casi non è un problema tecnico ma di comunicazione: specifiche scritte in fretta, aspettative diverse tra cliente e fornitore e nessuna verifica intermedia. Quando il primo momento in cui si vede il software funzionante è la consegna finale, è troppo tardi per correggere il tiro senza costi enormi.
Chiedi di vedere qualcosa di concreto prima di firmare: uno schema dei flussi, un prototipo cliccabile o una demo del processo che ti sta più a cuore. Se il fornitore sa spiegarti con parole tue come funzionerà il tuo lavoro dentro il software, ha capito. Se risponde solo con termini tecnici e rimanda tutto alla consegna, è un segnale d’allarme.
Dipende da cosa hai messo nero su bianco. Pretendi per contratto la proprietà del codice sorgente, la documentazione e l’accesso diretto al database. Se hai questi tre elementi, un altro fornitore può riprendere il lavoro; se non li hai, resti ostaggio di chi ha scritto il software.
No, è il contrario. La fase di analisi e la demo iniziale hanno un costo, ma prevengono il rischio più caro di tutti: costruire per mesi la cosa sbagliata. Vedere un prototipo funzionante prima di impegnare il budget grosso è il modo più economico per evitare un fallimento.
Per una PMI un progetto su misura si colloca indicativamente tra 5.000 e 30.000 euro, a seconda del numero di flussi, integrazioni e utenti, con una manutenzione annua nell’ordine del 15-20% del costo iniziale. Le cifre esatte escono solo dall’analisi: la prima call di 20 minuti è gratuita e serve proprio a capire dove ti collochi.
