Il progetto morto in un giorno di sprint (e cosa ne ho estratto)

Ho un progetto che è vissuto un giorno. Uno sprint, dalla mattina alla sera: nato, cresciuto, spedito. E poi, con la stessa rapidità, parcheggiato per sempre.

La tentazione era seppellirlo in silenzio, come si fa coi progetti che non ce l'hanno fatta e con le piante del terrazzo. Invece gli ho fatto l'autopsia. Ed è stata la giornata di lavoro con il miglior rapporto lezioni/ore della mia carriera.

Un giorno di vita

Il progetto era un'app per organizzare feste ed eventi — form di iscrizione, pagamenti, email, la solita liturgia. Costruita in un singolo giorno di sprint con gli agenti: io a dirigere il traffico, loro a scrivere. A fine giornata funzionava. Funzionava davvero: deploy fatto, flusso completo, pagamento di prova andato a buon fine.

E lì, davanti alla cosa funzionante, la domanda scomoda che nessuno fa mai alla demo: e adesso, chi la usa?

La risposta onesta era: nessuno, per ora, e non per colpa del software. Il progetto è finito in naftalina lo stesso giorno in cui è nato — in azienda lo chiamiamo elegantemente "incubator", che suona meglio di "limbo".

L'autopsia

La sera stessa, un agente ha scritto il post-mortem. Diligente, ordinato, pieno di "pattern estratti dall'esperienza": tredici cose che avevano funzionato, undici "emergenti". Ventiquattro lezioni. Da un giorno di lavoro. Ventiquattro. E in fondo, già impaginata, una tabella di dodici azioni da mettere in pratica subito, più una sezione di quarantena intitolata, in maiuscolo e senza pietà, COSA È SPECIFICO DI MYFESTAPP — NON GENERALIZZARE: undici voci.

E qui arriva la parte che mi ha insegnato di più, perché la tentazione era grande: prendere quelle dodici azioni e promuoverle subito a regole aziendali. Guardate quanto abbiamo imparato! Che produttività! Invece il giorno dopo la review — fatta dall'umano, con la matita rossa — è partita da un'osservazione scomoda: ogni "pattern" di quel documento era stato visto una volta, due al massimo. E ha passato ogni voce a tre filtri:

• Reggerebbe in una seconda azienda, anche solo immaginaria?
• Quanto costa estrarla, adesso?
• Sta nello strato giusto — regola per tutti, o trucco per una sola tecnologia?

Ogni voce è finita in una di quattro scatole: estrai subito, estrai ma solo per quella tecnologia, aspetta la seconda azienda, nessuna azione. Dalla prima sono usciti i template — quello dei documenti di decisione, quello del diario di progetto — che quel giorno stesso sono diventati la prima versione del framework da cui partono le aziende successive. Nella terza sono rimaste, a stagionare con dignità, le cose che sembravano leggi e potevano essere coincidenze. E la regola di lint, la più furba di tutte sulla carta, è ancora lì che aspetta qualcuno che la accenda. La statistica con n=1 non è statistica: è un aneddoto vestito bene.

Cosa resta di un progetto morto

Il conto della serva, versione necrologio:

• Giorni di sviluppo: 1
• Utenti reali: 0
• Fatturato: 0 €
• Lezioni proposte dall'autopsia: 24
• Azioni proposte dall'agente: 12
• Voci messe in quarantena come "non generalizzare": 11
• Giorni tra l'autopsia e la prima versione del framework: 1
• Regole di lint accese davvero: 0

Perché questo è il punto che rende l'autopsia il miglior investimento della giornata: il progetto è morto, ma il suo scheletro — i template dei documenti, le regole sui permessi del database, perfino l'abitudine di aspettare la seconda azienda prima di scrivere una legge — è diventato l'impalcatura delle cose costruite dopo. L'app non la usa nessuno; il suo post-mortem è diventato il primo mattone del framework.

Nel mio vecchio blog avrei chiuso con una riflessione sul percorso che conta più del traguardo. Vent'anni dopo la riformulo da imprenditore: il traguardo era sbagliato, il percorso era il prodotto.

Il progetto è morto. Viva il post-mortem.