Il progetto che è sempre quasi pronto

Chiedete a che punto siamo e la risposta è sempre quella, cioè che manca poco. Lo era anche tre mesi fa, e intanto il software non lo sta usando nessuno.

Succede più spesso di quanto si creda, e quasi mai perché chi sviluppa lavora male. Succede perché all'inizio nessuno ha scritto cosa vuol dire finito, e senza quella frase ogni settimana si può aggiungere una cosa che in quel momento sembra indispensabile.

Un prototipo non è un prodotto a metà

Un prototipo serve a rispondere a una domanda, per esempio se la gente lo userebbe davvero, e quando la risposta arriva ha finito il suo lavoro. Un prodotto invece deve reggere quando lo apre gente che non vi conosce, quando i dati diventano tanti e quando qualcosa si rompe di sabato pomeriggio. Sono due cose diverse, e la seconda non si ottiene aggiungendo pezzi alla prima.

È per questo che un progetto può sembrare vicinissimo alla fine per un anno: se quello che c'è è un prototipo, ogni pezzo che aggiungete lo allontana dal traguardo invece di avvicinarlo, perché il traguardo era da un'altra parte.

La domanda che separa le due cose

Quante persone lo useranno davvero, e cosa succede il giorno che sono il doppio? Se la risposta arriva con dei numeri il progetto è più avanti di quanto sembri, e se arriva con un «si vedrà» quello che state costruendo è ancora un prototipo, per quanto tempo ci abbiate messo.

Quella domanda la si fa all'inizio, quando costa mezza giornata di lavoro. Farla dopo costa quanto rifare.

Cosa ho visto succedere

Su una piattaforma di cui sono il responsabile tecnico sono arrivato quando lo sviluppo andava avanti da un anno e non era ancora uscito niente. La cosa scomoda da dire era che finirlo non conveniva, perché rimettere in ordine quello che c'era sarebbe costato più che ripartire con le idee chiare, e il tempo rimasto non bastava per tutte e due le strade.

In un anno di lavoro il valore non era nel codice, era nelle strade già provate e scartate.

Quello che si è salvato infatti non è stato quasi niente di quello che era stato scritto, ma le decisioni: in dodici mesi erano state valutate parecchie soluzioni e ne erano state scartate altrettante, e sapere già cosa non funzionava ha fatto risparmiare mesi. È la ragione per cui «ricominciare da capo» quasi mai vuol dire ricominciare da zero.

Prima della prima riga di codice ci è voluto un mese e mezzo di sola progettazione, cioè architettura, requisiti e struttura dei dati, e l'infrastruttura l'abbiamo dimensionata sul numero di persone che ci aspettavamo invece di aggiustarla di corsa dopo. Da sei mesi la piattaforma è in produzione e quella previsione tiene.

Se siete adesso in questa situazione

La prima cosa da chiedere non è quanto manca. È cosa succede se domani lo aprite a cento persone, e poi a mille: se ve lo sanno dire con dei numeri siete messi meglio di quanto pensiate, e se non ve lo sa dire nessuno il problema non è la velocità di chi sviluppa.

La seconda è farvi mettere per iscritto cosa vuol dire finito, anche solo in dieci righe. Non serve un documento da consulenti, serve una frase che fra sei mesi permetta a tutti e due di dire se ci siete arrivati oppure no.

E se la risposta onesta è che va rifatto, il momento meno caro per scoprirlo è sempre oggi.