La maggior parte dei progetti software che finiscono male non lo fanno all'improvviso. I segnali c'erano già all'inizio, solo che nessuno li ha presi sul serio: all'inizio c'è entusiasmo, c'è voglia di partire, c'è la sensazione che "poi sistemiamo strada facendo". E invece quello che non sistemi all'inizio diventa strutturale.
Dopo un po', se lavori su questi progetti, inizi a riconoscerli subito. Si vede da come parte la conversazione, prima ancora di guardare il codice.
Quando il problema non è chiaro
Il primo segnale è semplice: manca chiarezza su cosa si stia cercando di risolvere, in modo concreto, non astratto. "Voglio automatizzare questo processo" è un'intenzione, non ancora una definizione. Tra le due cose c'è un abisso fatto di dettagli, eccezioni, vincoli.
Se il problema non è definito, ogni soluzione sarà interpretata. E ogni interpretazione diversa diventa un potenziale conflitto.
Quando tutto sembra semplice
Ci sono richieste che, raccontate a parole, sembrano banali.
"Basta prendere questi dati e tirar fuori queste informazioni."
Poi guardi meglio e scopri che i dati non sono strutturati, che le regole cambiano caso per caso, che quello che sembra una regola è in realtà un'eccezione ricorrente.
Il vero ostacolo è la stabilità: senza una definizione abbastanza precisa, il sistema non può essere stabile, indipendentemente dalla difficoltà tecnica. E un sistema instabile genera aspettative instabili.
Quando una demo diventa una promessa
Un prototipo serve a validare una cosa: che una direzione è percorribile. Non serve a garantire che tutto funzionerà sempre, in ogni condizione, con qualsiasi input. È la stessa confusione che porta a trattare l'MVP come un prodotto mal fatto.
Se una demo viene letta come una promessa implicita — "se qui funziona, funzionerà sempre" — il progetto è già fuori asse. La realtà coincide con l'insieme di tutti i casi che ancora non hai visto, ben oltre il caso demo.
Quando i limiti non vengono accettati
Ogni tecnologia ha limiti: alcuni tecnici, altri economici, altri semplicemente legati alla natura del problema. Se questi limiti vengono discussi, è normale; se vengono ignorati o trattati come dettagli secondari, no.
Un progetto funziona quando entrambe le parti accettano che esistono vincoli e lavorano dentro quei vincoli. Quando una delle due parti parte dal presupposto che i vincoli siano negoziabili, il progetto diventa una trattativa continua. E le trattative continue non producono buon software.
Quando il costo "non torna"
Un altro segnale è la reazione ai costi. Il fatto che sembrino alti è normale: il software, visto da fuori, sembra sempre più semplice di quello che è — un tema su cui ho già scritto in perché le stime di sviluppo sembrano sempre sbagliate. Il segnale arriva quando il costo viene percepito come "sbagliato" invece che come informazione nuova.
In quel momento la discussione, sotto i numeri, riguarda due realtà diverse di cosa sia il software. E se la realtà non è condivisa, il progetto non ha base su cui stare.
Un disallineamento di partenza
Questi segnali descrivono condizioni di partenza in cui il progetto non può funzionare, più che un "cliente difficile". È una distinzione importante: il giudizio sulle persone è secondario, quello che conta è capire quando il sistema che si sta creando non reggerà. E quando non regge, non c'è codice che tenga.
Fermarsi prima costa meno
Il momento più economico per fermare un progetto è prima di iniziarlo. Dopo hai tempo investito, aspettative create, posizioni irrigidite, decisioni prese che diventano difficili da ritrattare. A quel punto, anche quando è evidente che qualcosa non funziona, si continua lo stesso. Perché fermarsi sembra una perdita.
E invece la perdita è andare avanti. È lo stesso meccanismo che porta tante agenzie a mollare a metà progetto: il punto di rottura era già visibile mesi prima.
Riconoscere i segnali per quello che sono
Chi ha esperienza li riconosce quasi subito. Per esperienza accumulata, più che per bravura: li ha già visti. Il problema è che spesso vengono ignorati, minimizzati, razionalizzati.
"Poi si sistema."
"Partiamo e vediamo."
"Non sarà così complicato."
A volte va bene. Molto più spesso no. E quando no, la cosa più frustrante è che si poteva vedere prima: i segnali c'erano già. Bastava prenderli sul serio — e accettare che non tutti i progetti vanno iniziati.
Simone Giusti
Consulente software strategico
