Software su misura in 12 settimane: cosa è realistico — e cosa no
Dodici settimane bastano per mettere in produzione un sistema vero: un portale clienti, un’app mobile, un agente AI che lavora dentro le vostre operazioni. Non bastano per tutto — e i fornitori che dicono sì a tutto in 12 settimane sono quelli che poi mancano la data. La differenza tra un piano credibile di 12 settimane e una frase da venditore si riduce a tre cose: cosa viene tagliato prima che il build cominci, ogni quanto vedete software funzionante e cosa succede se la data slitta.
Perché la velocità fallisce: è il perimetro, non la tastiera
I progetti software raramente esplodono perché gli ingegneri scrivono codice troppo lentamente. I ricercatori di Oxford che hanno studiato 1.471 progetti IT hanno rilevato uno sforamento medio dei costi del 27%, con un progetto su sei oltre il budget del 200% — e l’indagine del PMI su 5.402 professionisti ha rilevato che il 52% dei progetti subisce scope creep, sprecando circa 10 centesimi di ogni dollaro di progetto. Il pattern dietro entrambi i numeri è lo stesso: un perimetro mai davvero fissato, più feedback che arriva con mesi di ritardo, quando non serve più. Qualsiasi promessa onesta di velocità deve attaccare quelle due cause — tutto il resto è marketing.
Cosa sostiene davvero la ricerca sulla delivery
L’evidenza più forte a favore della consegna rapida riguarda la dimensione dei lotti. Il programma di ricerca DORA rileva che lavorare in piccoli lotti predice sia la performance di delivery del software sia quella organizzativa: funzionalità tagliate in giorni anziché settimane, modifiche deployabili in fretta, cicli di feedback abbastanza corti da uccidere le cattive idee prima che consumino il budget. Una demo settimanale di software funzionante su dati reali è l’applicazione pratica di quell’evidenza — è insieme un rapporto di avanzamento, un meccanismo di controllo del perimetro e un sistema di allerta precoce. Dodici settimane con demo settimanali sono dodici occasioni per correggere la rotta; dodici settimane con una rivelazione finale sono una sola.
L’anatomia di un piano onesto di 12 settimane
Un piano credibile è specifico sulle proprie settimane. Il nostro: le settimane uno e due sono uno sprint di scoping a pagamento — mappare il processo, ottenere accesso a sistemi e dati, fissare perimetro, metriche di successo e piano di test, chiudendo con un documento di architettura, un prezzo fisso e un go/no-go. La terza settimana consegna un walking skeleton: la fetta funzionante più sottile, end to end, sui vostri dati reali. Dalla quarta all’ottava gira il loop di build, con una demo ogni settimana. La nona e la decima sono hardening, documentazione e runbook. L’undicesima e la dodicesima fanno girare il sistema in shadow mode, poi live, poi handover. A qualsiasi fornitore che promette velocità, chiedete il suo equivalente di questo paragrafo.
Cosa le 12 settimane escludono
L’onestà sui limiti fa parte della promessa. In 12 settimane non ci stanno una piattaforma tuttofare per ogni reparto, la sostituzione completa di un ERP cablato a una dozzina di sistemi legacy, la ricerca a tempo indeterminato o un agente AI i cui dati richiedono prima mesi di pulizia — quella pulizia è una fase uno a sé. La disciplina che rende reali le 12 settimane è tagliare fino al primo workflow che porta valore misurabile, portarlo in produzione ed estendere da un sistema live. Un sistema ristretto e live alla dodicesima settimana batte uno ampio fermo al 60% per un anno — perché quello live genera ricavi, feedback e fiducia, mentre quello ampio genera riunioni di avanzamento.
Cosa lo rende possibile
Quattro ingredienti, tutti noiosi. Un perimetro firmato da entrambe le parti prima che il build cominci, così la quinta settimana non si spende a rinegoziare la seconda. Un unico decisore dalla vostra parte che risponde alle domande in ore, non in cicli di comitato. Un team senior che costruisce end to end, senza passaggi di mano tra fornitori. E disciplina di produzione dalla prima settimana — deploy continuo dal terzo giorno, in piccoli lotti, così che “andare in produzione” alla dodicesima settimana sia un non-evento invece di un salto nel vuoto. Niente di tutto questo è eroico; tutto è raro, ed è per questo che la promessa suona più audace di quanto sia.
La domanda che separa una promessa da un piano
Chiedete al fornitore: cosa succede se mancate la data? Un’operazione onesta ha una risposta contrattuale — la nostra è che continuiamo a costruire senza costi finché il sistema non è live sul perimetro firmato. Poi chiedete di vedere il piano settimana per settimana e la cadenza delle demo prima di firmare qualsiasi cosa. Un fornitore che non sa mostrarvi per iscritto il deliverable della terza settimana vi sta chiedendo di finanziare il suo ottimismo. Un fornitore che sa farlo — e che vincola la data nel contratto — ha già fatto il lavoro di pensiero che rende realistiche dodici settimane.
Un agente AI può davvero essere pronto per la produzione in 12 settimane?
Un workflow di agente ben perimetrato — con le sue integrazioni, i gate di approvazione, la suite di eval e il monitoraggio — sì. Un assistente per tutta l’azienda, no. L’agente ristretto va live e si guadagna l’estensione; quello ampio resta una demo. Il perimetro è tutta la partita.
E se il mio progetto ha davvero bisogno di più di 12 settimane?
Allora lo sprint di scoping lo dice alla seconda settimana, e decidete con in mano un documento di architettura e un piano a fasi — avendo rischiato due settimane, non un trimestre. I build più grandi vengono consegnati a fasi, ciascuna con il proprio traguardo live, invece che come un’unica lunga promessa.
Cosa vi serve da noi per mantenere realistiche le 12 settimane?
Tre cose: un decisore con nome e cognome che risponda alle domande di perimetro entro un giorno, accesso ai sistemi e ai dati rilevanti nella prima settimana e la presenza alla demo settimanale. I progetti mancano le date per risposte lente molto più spesso che per ingegneria difficile.