Giugno 2024. Un cliente e-commerce chiama in preda al panico alle 22: il suo sito doveva essere consegnato prima del Black Friday, il restyling grafico è ancora alla quarta revisione e il developer front-end è in ferie fino al 2 dicembre. Il piano di progetto originale? Due colonne Excel costruite in un'ora durante il kick-off. In pratica: niente.
Ogni project manager di agenzia ha vissuto almeno una volta questa scena. Eppure continuiamo a trattare il retroplanning come una formalità amministrativa invece che come la colonna vertebrale del progetto. Errore fatale.
Perché la maggior parte dei planning non serve a nulla
La maggior parte dei planning in agenzia condivide lo stesso difetto: vengono costruiti da sinistra a destra, dall'inizio del progetto verso la deadline, impilando compiti in modo ottimistico. È esattamente il contrario di quello che bisognerebbe fare. Un vero retroplanning parte dalla data di consegna e risale nel tempo. Si fissa la deadline contrattuale non negoziabile, poi si sottraggono i tempi di collaudo, correzione e validazione. Poi le fasi di produzione. Quello che rimane è la vera data di inizio. Spesso questa data è già passata quando si fa l'esercizio con onestà.
"Abbiamo iniziato a costruire i nostri planning a ritroso 18 mesi fa. Il tasso di consegne puntuali è passato dal 41% al 78%. Solo cambiando il verso di lettura del piano." - Responsabile produzione, agenzia digitale 12 persone, Lione
I 4 errori classici e come correggerli
Primo errore: non integrare i tempi di validazione del cliente. I cicli di approvazione rappresentano in media dal 30 al 40% della durata totale di un progetto web. Li dimentichiamo sistematicamente. Secondo errore: l'allocazione teorica di FTE. Scrivi "sviluppo front-end: 5 giorni", ma quel developer è al 60% su un altro progetto. I 5 giorni diventano 12 giorni di calendario.
Terzo errore: zero buffer. Aggiungere il 15-20% di margine di sicurezza su ogni fase principale non è barare, è realismo. Quarto errore, quello che mi fa più arrabbiare: il retroplanning non viene mai aggiornato dopo il kick-off. Un piano che non viene aggiornato ogni settimana è un documento morto.
Metodo in 5 passi per costruire un retroplanning solido
Passo 1: fissare la data ancora. Il go-live contrattuale, non negoziabile. Tutto parte da lì. Passo 2: suddividere in macro-milestone, non in compiti granulari. Prima le grandi fasi: inquadramento, design, produzione, collaudo, consegna. Ogni milestone ha la propria deadline calcolata a ritroso dalla consegna.
Passo 3: mappare le dipendenze. Il SEO tecnico non può iniziare prima che l'architettura sia validata. Materializzare queste dipendenze in Notion, Asana o Clynt evita i disastri dell'ultimo minuto. Passo 4: assegnare le risorse in giorni di calendario reali. Passo 5: condividere e formalizzare. Un cliente che ha approvato il piano dall'inizio non può sostenere che la scadenza era "irrealistica" tre settimane prima della consegna.
Retroplanning e metodi Agile: contraddizione o complementarità?
Persiste il mito che il retroplanning sia antiquato e incompatibile con Scrum o Kanban. È una confusione. Il retroplanning fissa le milestone contrattuali macro. Gli sprint Agile organizzano la produzione all'interno di queste milestone. Coesistono perfettamente. In un cliente retail nel 2023, il team tech lavorava con sprint di due settimane, ma il retroplanning macro con beta e go-live era visibile in modo permanente su Slack. Zero sorprese per il cliente.
Cosa fare quando il planning salta
Succede sempre. La domanda non è evitarlo al 100%, ma rilevarlo presto. Appena si identifica un ritardo di più di 3 giorni su una milestone intermedia, ci sono tre opzioni: ridurre lo scope a MVP, aggiungere risorse se il margine di budget lo consente, o rinegoziare la deadline con il cliente presentando i fatti. La peggiore opzione: sperare di recuperare il ritardo in uno sprint finale. Non funziona mai.
FAQ
Qual è la differenza tra un retroplanning e un classico diagramma di Gantt?
Il Gantt classico si costruisce da sinistra a destra. Il retroplanning parte dalla data di consegna e risale nel tempo per calcolare le milestone. Questa inversione costringe a confrontarsi con i veri tempi sin dalla progettazione, eliminando l'ottimismo ingenuo dei planning tradizionali.
Come gestire i ritardi imprevedibili nelle validazioni del cliente in un retroplanning?
Integra finestre di validazione contrattuali nel retroplanning: ad esempio, il cliente ha 5 giorni lavorativi per approvare ogni deliverable. Se la validazione supera questo termine, la data di consegna finale si sposta automaticamente dello stesso numero di giorni. Formalizza questo principio nel contratto o almeno nell'ordine di acquisto.
Quante milestone intermedie dovrebbe avere un progetto di redesign di un sito web?
Per un redesign standard da 2 a 4 mesi, pianifica da 5 a 7 milestone: kick-off, validazione architettura e wireframe, approvazione identità visiva, collaudo interno, accettazione cliente, correzioni finali, go-live. Con meno di 5 milestone il tracking è troppo grossolano per individuare i ritardi in tempo.
Il retroplanning completo va condiviso con il cliente?
Non necessariamente. Condividi la versione macro delle milestone per allineare le aspettative e fissare le date di validazione. La versione operativa dettagliata con l'allocazione delle risorse interne rimane solitamente interna. Il cliente non ha bisogno di sapere che Jean-Baptiste è al 60% sul suo progetto e al 40% su un altro.