Quale framework di project management usare con l’AI nel 2026
Ho confrontato i framework veri e ho scelto Waterfall, quello che tutti danno per morto. Per un’AI è il migliore, perché la obbliga a una cosa sola: la spec scritta prima. Il template è nel deep dive.
Mercoledì mattina, caffè ancora caldo, apro una sessione nuova di Claude. Una di quelle senza memoria, che non sanno niente di ieri. Gli faccio leggere il vault e gli chiedo la cosa più semplice del mondo: cosa dovrei fare adesso. Lui apre la struttura delle cartelle, la legge tutta, e mi risponde con un riassunto ordinatissimo di dove vivono le cose. Bello. Ma il vero problema è arrivato dopo, il giorno in cui l’ho lasciato fare sul serio. Gli ho passato un lavoro con due righe di brief, e lui è partito velocissimo nella direzione sbagliata. Ha costruito una cosa intera, fatta bene, che non era quella che volevo. Non aveva capito male. Aveva indovinato, perché non gli avevo detto abbastanza.
Lunedì ho scritto che si parte dal sistema, non dal tool, e ho mostrato un sistema che gestisce un compito alla volta. Un progetto però non è un compito. È venti cose in fila, con un ordine, e con un punto preciso prima del quale non dovresti nemmeno iniziare a costruire. Quel giorno ho capito che alla mia AI mancava proprio quello: non un altro posto dove archiviare, ma un metodo che la obbligasse a sapere tutto prima di muovere un dito. Di framework di project management ne esistono nove o dieci, e quello che fa esattamente questa cosa è il più vecchio e il più disprezzato di tutti. Waterfall.
In sintesi: un framework di project management dice all’AI come avanza il lavoro, cosa fare, in che ordine, a che punto sei. Ho confrontato i framework veri e ho scelto Waterfall, quello che le aziende moderne hanno abbandonato. Per un’AI è il migliore per la stessa ragione per cui gli umani lo odiano: ti obbliga a scrivere tutta la specifica prima di costruire. Un umano improvvisa e aggiusta mentre va, un agente senza spec riempie i buchi indovinando. Waterfall toglie l’indovinare.
Perché l’archivio perfetto non ti dice cosa fare adesso
Il vault che ho costruito in questi mesi è un archivista bravissimo. Cattura tutto, ogni nota, ogni decisione, ogni numero, e lo ritrovi quando lo cerchi. L’ho raccontato nei post sulla memoria: i file che danno a Claude un cervello, e poi il vault che da archivio del passato è diventato un sistema che ti avvisa prima. Ma c’è un buco che nessuna di quelle cose chiude. L’archivio sa dov’è ogni cosa. Non sa cosa va fatto adesso, in che ordine, e soprattutto non sa quando hai abbastanza informazioni per iniziare a costruire senza tirare a indovinare.
È la differenza tra una libreria e un cantiere. La libreria tiene i libri in ordine. Il cantiere non improvvisa: prima il progetto disegnato fino all’ultima misura, poi le fondamenta, poi i muri, poi il tetto. Nessuno tira su il tetto prima dei muri, e nessuno inizia a costruire mentre l’architetto sta ancora decidendo dov’è la porta. Un’AI a cui dai solo l’archivio e un brief vago si comporta da operaio entusiasta che parte a murare senza il disegno: va veloce, e va veloce verso il posto sbagliato. Quello che le mancava era il disegno completo prima del cantiere, e in project management quel modo di lavorare ha un nome, Waterfall, costruito proprio così, a fasi che non si scavalcano.
Il punto è che quel modo di lavorare, per le squadre di umani, è diventato una parolaccia. Troppo rigido, dicono, troppo lento, congeli tutto all’inizio e non puoi più cambiare. Hanno ragione, per gli umani. Quello che quasi nessuno ha notato è che quando dall’altra parte del cantiere non c’è una persona ma un agente, quella rigidità cambia di segno.
Il confronto, e perché ho scelto il framework che tutti evitano
Li ho messi in fila tutti, con una domanda in testa: quale di questi un’AI riesce a portare avanti senza tirare a indovinare. Di solito Waterfall è il primo che si scarta, perché è il più rigido. Io sono arrivato dalla parte opposta, e ti spiego il ragionamento.
Gli agili prima di tutto, perché sono i famosi. Scrum, Kanban, le loro varianti. Sono costruiti su un’idea bellissima e profondamente umana: non puoi sapere tutto all’inizio, quindi parti, provi, aggiusti mentre vai. Funziona benissimo con le persone, che hanno il buon senso di fermarsi quando sentono che stanno sbagliando. Un agente quel buon senso non ce l’ha. Se gli dici parti e aggiusti, lui parte e aggiusta in autonomia, cioè continua a indovinare a ogni passo. Più libertà gli lasci, più spazio gli dai per allontanarsi da quello che volevi. Gli agili danno per scontato un umano che corregge in continuazione, e quell’umano in una squadra di agenti non c’è a ogni minuto. SAFe poi è roba per decine di team, come comprare un camion per andare a prendere il pane.
I predittivi pesanti, PRINCE2 e PMBoK, sono carichi di ruoli e governance da grande organizzazione, un consiglio di progetto, sette figure, certificazioni. Un fondatore con un piccolo team non riesce a popolarli, e non aggiungono niente che mi serva.
Resta Waterfall, scarnificato fino all’osso. E all’osso Waterfall è una sola idea potente: decidi tutto prima di costruire, scrivilo, poi costruisci in ordine, poi verifica che quello che hai costruito sia esattamente quello che avevi deciso. Per una persona su un progetto che cambia è una camicia di forza. Per un agente è la ringhiera che gli impedisce di indovinare. Stessa identica rigidità, verdetto opposto, e l’unica cosa cambiata è chi tiene in mano la cazzuola. Non è una mia fissazione da contrarian: nel 2025 e nel 2026 è esploso lo spec-driven development, l’idea di scrivere la specifica completa in un file e farla trattare all’agente come l’unica fonte di verità. È Waterfall che rientra dalla porta principale, solo che adesso lo chiamano con un nome che fa più tech.
Una cosa la dico subito, perché altrimenti suonerebbe come la solita ricetta che funziona sempre. Waterfall ha un difetto vero, e resta anche con un’AI: se scrivi una spec gigante per un progetto di sei mesi, rischi di costruire benissimo la cosa sbagliata per sei mesi. Il trucco non è abbandonare Waterfall, è tenerlo corto. Una cascata piccola per ogni pezzo consegnabile, non una sola cascata lunga per tutto l’anno. La spec scritta prima è l’oro. Il segreto è non farla mai più lunga di quello che riesci a verificare in fondo.
Come ho insegnato Waterfall alla mia AI, fase per fase
La parte bella è che non serve niente di tecnico. Insegnare Waterfall a un’AI vuol dire scriverle cinque fasi in un file, e dirle che non può scavalcarle. Te le smonto una a una. Il template completo, pronto da copiare, lo trovi nel deep dive in fondo.
Fase uno, la spec. Prima che l’agente tocchi qualsiasi cosa, si scrive cosa deve fare il lavoro: l’obiettivo, i vincoli, cosa è dentro e cosa è fuori, e soprattutto i criteri con cui dirò che è venuto bene. Questa è la fase che conta più di tutte le altre messe insieme. Venti minuti spesi qui valgono ore risparmiate dopo. È noiosa, ed è esattamente per questo che quasi tutti la saltano e poi si lamentano che l’AI fa cose a caso.
Fase due, il design. L’agente non costruisce ancora. Mi propone come lo farà: la struttura, i passi, le scelte. Io leggo e approvo, oppure correggo. Questo è il primo cancello, e il cancello è mio. È il punto in cui blocco un errore quando costa una frase, invece di scoprirlo alla fine quando costa un pomeriggio.
Fase tre, lo sviluppo. Solo adesso l’agente costruisce, e costruisce seguendo la spec, non la sua fantasia del momento. Se mentre lavora si accorge che manca qualcosa, non lo inventa: si ferma e me lo chiede. Questa è la differenza tra un agente che esegue e un agente che parte per la tangente.
Fase quattro, il test. Finito di costruire, l’agente verifica il risultato contro i criteri di accettazione scritti nella spec. Non contro un generico sembra a posto, contro la lista precisa che abbiamo deciso all’inizio. Se un criterio non è soddisfatto, la cosa non è finita, torna indietro.
Fase cinque, il rilascio. La consegna vera: output prodotto, file aggiornato, riga nel log che dice cosa è cambiato. Questa è la mia definizione di fatto, ed è scritta, perché una sessione senza memoria non sa quando può davvero chiudere se non glielo dici nero su bianco.
Cinque fasi, e tra una e l’altra un cancello dove decido io. Se ci pensi, è il modo in cui già lavoro nel mio gestionale: l’agente prepara una bozza, io la leggo e approvo, e solo dopo viene eseguita. Bozza, approvazione, esecuzione. Era Waterfall senza che lo chiamassi così. L’ho aperto nel post sui sei file che danno memoria a Claude: lì c’è dove vivono le cose, qui c’è l’ordine con cui si fanno.
Il caso, tre business e zero lavori rifatti
Lo provo sul caso più scomodo che ho, il mio. Mando avanti tre mondi insieme: un’agenzia, un hub AI, un personal brand. Prima passavo all’AI le cose di fretta, con un brief di due righe, e mi fidavo della sua velocità. Andava veloce, e metà delle volte mi consegnava qualcosa che dovevo rifare, perché aveva riempito da sola i buchi che le avevo lasciato. Il tempo che risparmiavo non scrivendo la spec lo ributtavo via, raddoppiato, a sistemare il risultato.
Adesso ogni lavoro che conta parte da una spec, anche corta, e da un cancello dove approvo il design prima che costruisca. Il prima e dopo che misuro non è la velocità di esecuzione, lì l’AI era già fulminea. È il rifacimento. Quei venti minuti che prima saltavo, scritti all’inizio, mi hanno tolto le ore che buttavo a rifare cose partite storte. La spec non rallenta l’agente. Gli impedisce di correre veloce nel posto sbagliato, che è l’unico tipo di velocità che non ti serve.
I quattro errori che ho fatto, così te li risparmi
Il primo, il più comune: far partire l’agente senza spec completa, per fretta. È seducente perché l’AI è veloce e ti viene voglia di vedere subito qualcosa. Quel qualcosa è quasi sempre da rifare. La velocità senza la spec è solo un modo più rapido di sbagliare.
Il secondo: una spec senza criteri di accettazione. Se non scrivi come farai a dire che è venuto bene, l’agente non ha un metro, e testa contro sembra a posto. Sembra a posto è la frase che precede sempre un lavoro da rifare. I criteri sono la parte che la maggior parte delle persone salta, ed è quella che separa un test vero da una pacca sulla spalla.
Il terzo: saltare il cancello tra il design e la costruzione. La tentazione è dire vai e lasciarlo correre fino alla fine. Così però scopri l’errore di impostazione quando ha già costruito tutto, e correggerlo costa dieci volte tanto. Il cancello esiste per spendere la correzione quando è ancora una frase.
Il quarto, il più subdolo: la cascata troppo lunga. Scrivi una spec enorme per un progetto di mesi, l’agente costruisce per settimane, e quando arrivi in fondo hai fatto benissimo la cosa sbagliata. La risposta non è tornare all’improvvisazione, è accorciare la cascata: una spec piccola per ogni pezzo che riesci a verificare in tempi brevi, e poi la prossima.
Sotto trovi il deep dive completo: il file della spec pronto da copiare, con obiettivo, vincoli, criteri di accettazione e fuori-scope già impostati, e il blocco di istruzioni da incollare nel file di governance perché la tua AI rispetti le cinque fasi e si fermi ai cancelli invece di correre fino in fondo. È il setup che gira sui miei tre mondi. Per leggerlo serve essere maikers paganti (cinque euro al mese o cinquanta l’anno) o AI mAIker.
Deep dive, il setup Waterfall pronto da copiare
Qui sotto c’è tutto quello che ti serve per non costruire niente da zero. Sono i due file che fanno girare i miei lavori, ripuliti dai riferimenti personali: la spec da compilare prima di ogni cosa, e il blocco di regole che insegna all’AI a lavorare a fasi e a fermarsi ai cancelli. Copi, incolli, riempi la spec, e parte.
