Metodo
Dal problema al prodotto: il metodo.
Cinque fasi, di cui una è un loop. Un modo di lavorare che ho affinato in oltre vent'anni di architetture enterprise e che oggi applico ai prodotti digitali che costruisco o affianco, dal primo foglietto di carta fino al go-live in produzione.
Quando serve
Mi chiamano per tre motivi diversi, e in tutti e tre il punto di partenza è lo stesso: c'è un'idea, un team, o un prodotto già costruito, e non si sa come portarlo al livello successivo senza spendere il doppio del necessario.
Il primo caso è il founder con un'idea e un budget che non sa da dove partire. Ha paura di scrivere la riga di codice sbagliata, di bruciare sei mesi su una direzione che non porta da nessuna parte. Il metodo è la risposta a "da dove comincio?".
Il secondo caso è il team che sta già costruendo ma senza una disciplina condivisa. Ogni settimana si ricomincia, le stesse cose si rifanno, la qualità non migliora. Il metodo è la risposta a "ci serve un processo che regga".
Il terzo caso è chi ha un PoC che funziona in demo e non regge quando lo si mette davanti a utenti veri. Il metodo è la risposta a "come lo industrializziamo senza buttare via tutto".
Le tre situazioni hanno la stessa risposta: cinque fasi, di cui una è un loop. Le prime tre sono sequenziali. Le ultime due si ripetono finché il prodotto non è pronto per andare in produzione.
Le cinque fasi
Il diagramma seguente mostra l'ordine delle fasi. Le prime tre sono lineari: si fanno una volta sola, in sequenza, e da ciascuna esce un artefatto concreto. Le ultime due formano invece un loop iterativo: si ripetono per N sprint, e si esce dal loop quando tutte le specifiche scritte nella fase 3 sono state accettate dal cliente.
1. Discovery
Capire il problema vero prima di scrivere codice. Interviste con cinque-otto persone tra utenti e stakeholder, ipotesi scritta in una pagina, validazione o falsificazione esplicita. Esce: il problema da risolvere, non la soluzione da costruire. Se dopo questa fase non c'è una frase condivisa sul problema, le fasi successive costruiscono sulla sabbia.
2. PoC navigabile
Un mockup interattivo in Figma o HTML che mostra il flusso critico, senza backend reale. Lo guardano il cliente, gli utenti, il team. Esce: la conferma che il flusso risolve il problema, o una lista di correzioni da fare prima di andare avanti. Una volta validato, il PoC ha esaurito il suo compito. Non è la base del prodotto: serve a risparmiare i costi di un refactor quando le ipotesi della fase 1 si rivelano sbagliate. La costruzione vera comincia nella fase 3, sulle specifiche scritte con cognizione di cosa funziona e cosa no.
3. Specifiche con SDD
Le specifiche si scrivono come documenti versionati, non come ticket sparsi. L'approccio si chiama Spec-Driven Development: ogni specifica ha un input, un output, criteri di accettazione misurabili e, quando serve, una condizione di uscita esplicita. Per i criteri uso la notazione EARS, che costringe a scrivere affermazioni che un agente AI può trasformare in test senza dover interpretare l'intento. Esce: una lista di specifiche pronte per essere implementate, con i criteri che dicono quando una è "fatta".
4. Implementazione
Costruzione del software, una specifica alla volta, in sprint. I coding agent fanno la maggior parte del lavoro meccanico, ma la pipeline di delivery è umana: IaC, CI/CD, test sui punti che contano, ambiente riproducibile a ogni commit. Il codice deve poter essere deployato a ogni fine sprint, anche se non lo si deploya davvero in produzione. Esce: software che gira, monitorato, con le specifiche coperte o in copertura.
5. Review con cliente e Golive
Ogni sprint finisce con una demo al cliente. Il cliente accetta le specifiche completate, o chiede modifiche che rientrano nella fase 4. Quando tutte le specifiche sono accettate, si fa il deploy in produzione: monitoraggio attivo per le prime due settimane, handover al team di manutenzione, fine del coinvolgimento.
Dentro al loop: la struttura di uno sprint
Il loop iterativo è il cuore del metodo. Ogni giro produce una specifica in più coperta e un passo avanti verso il Golive. La struttura interna di ogni giro è sempre la stessa: pianifico la specifica, la implemento, faccio la demo al cliente, decido se è accettata o se serve un altro giro.
Il numero di sprint è variabile in base al progetto. Un MVP semplice può chiudersi in tre sprint, un prodotto enterprise può richiederne dieci. La durata degli sprint è fissata all'inizio e non si cambia a metà.
Cosa distingue questo metodo
Tre scelte che fanno la differenza rispetto a un approccio generico "validiamo e poi costruiamo".
La prima è che le specifiche si scrivono prima del codice, in documenti versionati, non in ticket. È la parte che sembra rallentare e invece accelera: quando un agente AI o un junior entra nel progetto, sa cosa deve costruire e sa quando ha finito.
La seconda è che il loop non è "build-measure-learn" in astratto, ma un loop di accettazione: il cliente accetta una specifica alla volta, e ogni accettazione è un mattone. Non si costruisce in anticipo e poi si spera che vada bene.
La terza è la disciplina del Golive: il metodo finisce davvero al deploy. Niente "quasi finito", niente "lo mettiamo in produzione la prossima settimana". Si esce dal loop quando le specifiche sono accettate, e si esce.
Quando questo metodo non è adatto
Il metodo è generico abbastanza da coprire la maggior parte dei prodotti digitali, ma non è per tutto. Tre casi in cui non lo uso.
Il primo è quando il cliente non riesce a garantire review frequenti. Il metodo richiede almeno una review a settimana con chi può decidere cosa è accettato e cosa no. Se il decision maker è in ferie, in tournée, o semplicemente non disponibile, il loop si ferma. C'è anche un rischio opposto, ben documentato: se i coding agent producono troppi PR in attesa di review, chi fa la review diventa il collo di bottiglia. La soluzione è la stessa in entrambi i casi: ridurre la frequenza di review a una ogni due settimane e accorciare la coda di PR.
Il secondo è quando non si sa ancora chi sono gli utenti. Se il cliente non ha un'idea precisa di a chi sta costruendo il prodotto, la fase 1 (Discovery) si allunga indefinitamente e le fasi successive non hanno un terreno su cui poggiare. Meglio fare prima un workshop di problem framing, anche di uno o due giorni, e poi rientrare nel metodo con il terreno pulito.
Il terzo è quando il cliente vuole solo un parere tecnico, non un prodotto. Se la richiesta è "guarda la mia architettura e dimmi cosa non va", oppure "aiutami a scegliere se AWS o Azure", il metodo è overkill. Per quello c'è l'Assessment AI, che è un servizio a sé.
Parliamone
Se hai un prodotto digitale da costruire e pensi che questo metodo possa fare al caso tuo, scrivimi. Due righe su cosa hai in mano e cosa ti serve, e capiamo insieme se il primo passo è un Discovery o un PoC.