I progetti software non falliscono alla fine. Falliscono all’inizio

C’è un’idea comoda e sbagliata sul perché i progetti software falliscono: che il disastro arrivi alla fine, quando il codice non gira, i tempi saltano e il budget è finito. In realtà quel finale è solo il momento in cui il conto diventa visibile. Il fallimento è già successo, mesi prima, il primo giorno — nel modo in cui il progetto è partito. E la cosa buona è che i segnali si vedono subito, se sai cosa ascoltare. Ce ne sono tre in particolare, tre frasi che, quando le sentiamo pronunciare a un tavolo, ci fanno drizzare le antenne.

Frase-spia 1: «Poi lo vediamo strada facendo»

Sembra pragmatica, quasi saggia. Partiamo, poi aggiustiamo. In un progetto software, invece, è la crepa da cui entra tutto.

Tradotto: «non abbiamo ancora deciso qual è l’obiettivo». Non c’è un traguardo scritto, quindi ogni riunione lo sposta di un metro, e nessuno se ne accorge perché tanto «lo vediamo strada facendo».

Il costo reale del rinvio: senza un obiettivo fermo, ogni settimana si aggiunge un pezzo «già che ci siamo». È il classico scope che si gonfia. A fine progetto ti ritrovi con il doppio delle funzioni, metà delle quali nessuno userà, tempi raddoppiati e la sensazione che manchi ancora qualcosa. Definire l’obiettivo il primo giorno costa un’ora di fatica; rinviarlo costa settimane di sviluppo buttato.

Frase-spia 2: «Il budget? Vediamo, dipende»

Detta con leggerezza, come se parlarne subito fosse volgare. Ma i vincoli non spariscono se non li nomini: si limitano ad arrivare più tardi, e più cari.

Tradotto: «non abbiamo messo a fuoco i vincoli — quanto possiamo spendere, entro quando ci serve, cosa dobbiamo per forza rispettare». Budget, scadenze e paletti tecnici restano nella nebbia.

Il costo reale del rinvio: si progetta senza sapere dentro quale recinto si sta giocando. Poi, a lavori avviati, arriva il «ah, ma questo doveva essere pronto per la fiera» oppure «ma tanto non potevamo superare quella cifra». E lì tocca tagliare di corsa, rifare scelte fatte bene ma per i paletti sbagliati. I vincoli detti all’inizio sono una guida; scoperti a metà strada sono una demolizione.

Un progetto software non fallisce per una riga di codice scritta male. Fallisce per una domanda che nessuno ha avuto il coraggio di fare al primo incontro.

Frase-spia 3: «Ci serve tutto, ed è tutto prioritario»

È la più insidiosa, perché suona come ambizione. In pratica è l’opposto: è l’assenza di una scelta.

Tradotto: «non abbiamo deciso le priorità». Se tutto è urgente, niente lo è davvero, e la decisione su cosa fare prima finisce per prenderla il caso — o lo sviluppatore, che non dovrebbe.

Il costo reale del rinvio: le energie si spalmano su venti cose in parallelo e non se ne chiude bene nessuna. Arriva la data di lancio e non c’è un pezzo davvero pronto, solo tanti pezzi al settanta per cento. Decidere le priorità all’inizio significa avere qualcosa che funziona presto; rinviare la scelta significa avere tanto, tardi, e a metà.

Le abbiamo viste succedere tante volte, queste tre, ed è lo stesso motivo per cui iniziamo ogni progetto ascoltando una «giornata storta» invece che un elenco di funzioni: perché il problema vero non è mai quello dichiarato al primo giro.

Cosa fare invece: le poche decisioni da prendere prima di iniziare

La parte costruttiva è più semplice di quanto sembri. Non servono documenti da cento pagine né riunioni infinite. Servono tre decisioni, prese sul serio, prima di scrivere la prima riga. Sono le stesse tre che, mancando, fanno fallire i progetti software.

• L’obiettivo, in una frase. Non «vogliamo un gestionale», ma «vogliamo dimezzare il tempo che il commerciale perde a fare i preventivi». Se non riesci a dirlo in una riga, non è ancora un obiettivo: è un desiderio. E un desiderio non si può progettare.
• I vincoli, messi sul tavolo. Quanto possiamo spendere, entro quando ci serve, cosa dobbiamo per forza rispettare (un gestionale che già c’è, una normativa, un fornitore). Detti prima, sono il perimetro dentro cui si costruisce bene. Detti dopo, sono la ruspa.
• Le priorità, con il coraggio di tagliare. Cosa deve esserci assolutamente al primo lancio e cosa può aspettare la seconda versione. La domanda che sblocca tutto è: «se dovessimo partire fra un mese con una cosa sola, quale?». La risposta è la tua priorità.

Tre risposte oneste a queste tre domande valgono più di qualsiasi capitolato tecnico. Sono anche la ragione per cui, prima di parlare di tecnologia, dedichiamo tempo all’analisi del progetto e alla definizione degli obiettivi insieme al cliente: è lì, in quel primo tavolo, che un progetto si salva o si condanna. Vale per una software house a Verona come per qualsiasi fornitore serio.

Se stai per far partire qualcosa e ti accorgi che una di quelle tre frasi te la stai dicendo da solo, fermati un attimo. Non è un dettaglio da sistemare dopo. È il progetto che ti sta parlando all’inizio — quando ascoltarlo costa ancora poco. Se poi vuoi vedere quali altri passi falsi si fanno proprio in questa fase, li abbiamo raccolti tra i 5 errori che le PMI fanno quando scelgono un software.