Il progetto è stato approvato, lo sviluppo è partito, le prime demo sono andate bene. Poi, a un certo punto, arrivano frasi che chi lavora nel software conosce a memoria:
- «Pensavamo fosse compreso.»
- «Serve solo aggiungere un campo.»
- «Il gestionale dovrebbe già permetterlo.»
- «Ma il rilascio non era previsto per giugno?»
Da quel momento cliente e fornitore iniziano a guardare lo stesso progetto da due lati opposti. Per uscirne serve una domanda semplice: è aumentato il costo dello stesso lavoro o è cambiato il lavoro da fare? E ancora: la data indicata all’inizio era la fine dello sviluppo, l’inizio del collaudo o la messa in produzione?
Gli scostamenti hanno cause diverse. Alcune dipendono da richieste nuove, altre da vincoli tecnici scoperti strada facendo, altre da attese e decisioni rimandate. Alcune, diciamolo subito, dipendono da errori di chi sviluppa. Capire quale causa è in gioco è il primo passo per gestirla.
Il primo numero non è il preventivo definitivo
Nelle prime conversazioni si parla quasi sempre di cifre e di date. È giusto: un’azienda deve capire se un investimento è sostenibile prima di impegnarsi. Il problema nasce quando tre cose diverse vengono trattate come se fossero la stessa:
- l’ordine di grandezza, che serve a capire se il progetto sta in piedi e spesso è una forbice di costo e di tempo;
- la stima dopo l’analisi, che tiene conto di funzioni, vincoli, integrazioni e dipendenze conosciute;
- l’offerta contrattuale, che dice cosa viene fornito, a quali condizioni, cosa resta escluso e come si gestiscono le variazioni.
Nel nostro processo di sviluppo le teniamo separate di proposito: dal primo colloquio nasce una quotazione di massima, mentre preventivo e piano di lavoro dettagliati arrivano dopo l’analisi. Una cifra o una data comunicate prima dell’analisi non possono avere la precisione che ancora non hanno le informazioni.
Perché il costo cresce: le cinque cause principali
- Requisiti impliciti. Permessi, eccezioni, notifiche, report, comportamenti che per chi lavora in azienda sono ovvi e che proprio per questo nessuno ha scritto.
- Richieste nuove. Vedere il software in funzione fa capire meglio cosa serve davvero. È un apprendimento utile, ma cambia il perimetro del progetto.
- Dati e integrazioni. Archivi incompleti o incoerenti, API con limiti non documentati, sistemi esterni diversi da come erano stati descritti. Spesso lo si scopre solo quando si prova a collegarli.
- Lavoro rimasto fuori dal conto iniziale. Test, sicurezza, migrazione dei dati, documentazione, formazione, rilascio. Il software non è solo codice, e un confronto fatto solo sulle funzioni visibili lo dimentica.
- Errori del fornitore. Una stima troppo ottimistica, un’analisi superficiale, una scelta tecnica sbagliata, lavoro da rifare. Succede, e va riconosciuto.
Un punto fermo: non ogni costo in più dipende dal cliente e non ogni imprevisto è automaticamente da pagare. Distinguere le cause serve proprio a questo.
«È solo una piccola modifica»
Prendiamo un esempio inventato ma realistico: aggiungere un campo «sconto» a un ordine.
Sullo schermo è una casella in più. Dietro bisogna decidere chi può usarlo e con quali limiti, come cambiano imposte, totali e arrotondamenti, come arriva al gestionale, cosa succede a ordini già emessi, resi e report, e quali test servono per non rompere ciò che già funziona.
Quanto è piccola una modifica a vederla non dice quanto è complessa. Ne avevamo già parlato nell’articolo sul perché nel software custom una stima precisa è così difficile. Questo però non autorizza a usare l’incertezza come alibi: la complessità va spiegata e stimata prima di fare il lavoro, non scoperta in fattura.
Dalla timeline prevista al rilascio effettivo: dove si perde tempo
Il tempo si comporta in modo diverso dal costo. Due giorni di sviluppo non sono due giorni di calendario. Tra il lavoro e il rilascio ci sono attese, dipendenze, revisioni e verifiche.
Per prima cosa conviene chiarire di quale traguardo si parla: fine dello sviluppo, disponibilità per il collaudo e rilascio in produzione sono tre momenti diversi. Poi ci sono le cause più comuni, ciascuna con il suo rimedio.
- La data viene fissata prima dell’analisi. Meglio indicare una finestra, dichiarare le ipotesi su cui si basa e aggiornare il piano quando l’analisi è conclusa.
- Il perimetro cresce, la scadenza resta ferma. Ogni nuova richiesta va valutata anche in termini di tempo. Poi si decide cosa aggiungere, cosa sostituire e cosa rimandare.
- Mancano accessi, dati o decisioni. Ogni dipendenza deve avere un responsabile e una data. I blocchi vanno resi visibili, con le loro conseguenze.
- I feedback arrivano tardi o si contraddicono. Servono demo periodiche, un referente che possa decidere e tempi concordati per rispondere.
- Le integrazioni si verificano troppo tardi. I collegamenti più rischiosi vanno provati per primi, prima di costruirci intorno il resto.
- La disponibilità del team è sovrastimata. Si pianifica sulle persone davvero disponibili, compresi i revisori e chi lavora anche su altri progetti.
- Collaudo e rilascio vengono trattati come una formalità. Test, migrazione, formazione e preparazione dell’ambiente di produzione vanno nel piano fin dall’inizio.
Anche qui vale la stessa onestà di prima: una pianificazione sbagliata o difetti evitabili del fornitore possono causare ritardi quanto le dipendenze esterne.
Un ritardo aumenta sempre il costo?
No, e confondere le due cose crea molte tensioni. Ci sono quattro situazioni diverse:
- più lavoro: attività aggiuntive che possono richiedere di rivedere l’aspetto economico;
- più attesa: il progetto resta fermo, ma non per questo si accumula lavoro;
- più frammentazione: fermarsi e ripartire richiede tempo per riallinearsi e nuove verifiche;
- benefici rinviati: anche senza fatture in più, il cliente ottiene più tardi i risparmi, i ricavi o i miglioramenti che si aspettava.
Un giorno di ritardo non è automaticamente un costo in più. Cause, responsabilità e conseguenze vanno valutate secondo gli accordi presi.
Prezzo fisso o lavoro a consumo: il rischio non sparisce
Ogni modello contrattuale distribuisce il rischio in modo diverso, ma nessuno lo elimina.
- A corpo: un prezzo concordato per un perimetro definito. Funziona se il perimetro è davvero chiaro e se le variazioni vengono riconosciute e gestite a parte.
- Time & Material: si paga il lavoro svolto secondo gli accordi. Richiede rendicontazione e un controllo frequente di spesa e priorità.
- Budget massimo: utile solo se si decide prima cosa succede quando ci si avvicina al limite.
Il prezzo fisso non è impossibile. Un prezzo fisso su richieste vaghe, però, espone entrambe le parti a problemi. Lo stesso vale per le date: una scadenza è affidabile quanto sono chiari il lavoro, le dipendenze e le persone disponibili.
Come ridurre le sorprese
Non esiste un metodo che azzeri l’incertezza, ma esistono abitudini che la tengono sotto controllo:
- investire nell’analisi prima di sviluppare;
- scrivere cosa è incluso, cosa è escluso, le ipotesi e le dipendenze;
- definire criteri di accettazione verificabili;
- validare presto le integrazioni più rischiose;
- consegnare per incrementi e raccogliere feedback;
- stimare e approvare le variazioni prima di realizzarle;
- tenere aggiornati speso, lavoro residuo e previsione di chiusura;
- segnalare gli scostamenti quando emergono, non alla vigilia della consegna.
Per questo proponiamo di partire dall’analisi del prodotto: non è burocrazia in più, è il lavoro che rende costi e tempi più affidabili.
Quando il piano cambia, la domanda utile non è «riuscite comunque a fare tutto?», ma «cosa vogliamo proteggere?»:
- se la data è inderogabile, si riduce il perimetro all’essenziale;
- se il perimetro è inderogabile, si rivedono tempi e budget;
- se il budget è inderogabile, si ordinano le priorità e si decide dove fermarsi.
Aggiungere persone al progetto non accorcia automaticamente i tempi: inserirle e coordinarle richiede tempo. E tagliare i test non elimina il ritardo, lo sposta dopo il rilascio, dove i problemi costano di più.
E con l’AI? Costi più bassi e tempi più brevi?
È la domanda che ci fanno più spesso. La risposta onesta è: non proprio, o almeno non nel modo in cui viene raccontato.
L’AI cambia soprattutto il modo di lavorare prima dello sviluppo definitivo. Project Manager, Product Owner e Designer possono costruire insieme, e molto più in fretta, prototipi funzionanti: non solo schermate da guardare, ma flussi da provare con chi userà il software.
Questo rende concreto il metodo agile, che spesso resta una parola: si costruisce, si prova, si raccolgono i commenti e si corregge in cicli brevi, prima di impegnare il budget nello sviluppo vero e proprio.
Il vantaggio è imparare prima: capire se una funzione serve davvero, scoprire requisiti impliciti e passaggi mancanti, confrontare alternative, scartare le soluzioni che non funzionano e mettere tutti d’accordo su qualcosa di concreto. Tempi e costi della prototipazione si accorciano davvero.
Attenzione però a non confondere un prototipo che si può provare con un prodotto pronto da usare. Architettura, integrazioni, sicurezza, qualità dei dati, permessi, test, prestazioni, documentazione e rilascio restano lì. Anche il codice generato con l’AI va capito, verificato e mantenuto. Per questo non promettiamo che costi e tempi dell’intero progetto si riducano in proporzione: il prodotto finale richiede ancora il lavoro di sempre.
Cosa cambia allora? Si arriva allo sviluppo con meno ambiguità, priorità più chiare e soluzioni già messe alla prova. A parità di investimento, questo può voler dire un software più vicino a come lavora davvero l’azienda e meno lavoro da rifare. A una condizione: che i prototipi servano a prendere decisioni, non a rimandarle.
L’AI rende più veloce mettere alla prova un’idea. Non elimina il lavoro necessario per trasformarla in un prodotto affidabile. Il vantaggio non è per forza spendere meno per lo stesso software: è usare meglio il budget per costruirne uno migliore.
Non serve indovinare tutto, serve governare il percorso
Un progetto software custom non dovrebbe essere né un assegno in bianco né una scadenza che si sposta senza spiegazioni. Prima di iniziare non possiamo conoscere ogni dettaglio, ma possiamo dichiarare le ipotesi, verificare presto i rischi e concordare i cambiamenti prima che diventino spese o ritardi.
Anche con l’AI, la differenza non la fa solo la velocità con cui si scrive codice. La fa quanto presto si capisce cosa costruire e quanto bene lo si porta in produzione.
Hai un’idea di software e vuoi capire quale investimento richiede? Partiamo dall’analisi di obiettivi, processi e priorità, per costruire insieme un piano sostenibile di costi e tempi. Contattaci.
