I programmi raramente falliscono alla fine. Falliscono alla seconda settimana — quando l’architettura è stata assunta invece che esaminata — e passano i mesi restanti a scoprirlo in modo costoso.
Tre schemi di fallimento che la discovery avrebbe intercettato
Una discovery architetturale time-boxed è la correzione: un esame breve e strutturato dei sistemi, dei vincoli e delle assunzioni da cui un programma dipende, eseguito prima che il team si allarghi. È lo sprint più economico che un programma possa eseguire, a una condizione — che sia contrattualmente vincolato a produrre decisioni, non documenti.
Gli schemi si ripetono da un’organizzazione all’altra:
- L’assunzione portante. Un programma si pianifica attorno a un’integrazione che si rivela solo batch, con rate limit, o contrattualmente chiusa. Il fatto era scopribile in un giorno; è emerso al quarto mese, incorporato in un design che assumeva il contrario.
- Il vincolo ereditato. La nuova capacità deve vivere in un patrimonio con realtà operative fisse — un database che non regge il carico, un confine di sicurezza che vieta il flusso dati previsto. Nessuno ha ispezionato il patrimonio; tutti hanno progettato la versione greenfield.
- La decisione mai presa. Due team sono andati avanti con due letture diverse dell’architettura, perché la decisione da cui entrambi dipendevano non è mai stata presa esplicitamente. Entrambi erano produttivi; il programma no.
Ogni schema ha la stessa forma: una domanda economica da rispondere presto e costosa da rispondere tardi.
Quando la discovery è necessaria — e quando è un rinvio
La discovery si guadagna il suo time-box quando almeno una di queste condizioni è vera: il programma dipende da sistemi che nessuno nel team ha mai aperto; un’assunzione tecnica, se sbagliata, invaliderebbe il piano; più opzioni architetturali sono davvero aperte e la scelta determina il budget; oppure i vincoli del patrimonio non sono documentati e le persone che li conoscono sono scarse.
La discovery è un rinvio — non diligenza — quando le domande hanno già una risposta, quando viene usata per posticipare una decisione che qualcuno non vuole prendere, o quando si propone una seconda discovery perché le risposte della prima non sono piaciute. Il test: nominate la domanda a cui questa discovery risponde. Se nessuno ci riesce, costruite.
Cosa ispezionare
Una discovery è un esame con una lista di obiettivi, non una ricognizione generale:
- I sistemi che il piano tocca — le loro interfacce reali, qualità dei dati, throughput e comportamento in caso di guasto, dal loro codice e dai loro operatori più che dalla loro documentazione.
- I vincoli che delimitano il design — confini di sicurezza, requisiti di compliance, capacità operativa, contratti esistenti, competenze del team.
- Le dipendenze tra decisioni — quali scelte sono reversibili, quali vincolano il programma, e in quale ordine vanno prese.
- L’assunzione critica — ogni programma ne ha una; il primo compito della discovery è nominarla e metterla alla prova, con uno spike se leggere non basta.
I risultati che contano
Una discovery è finita quando ha prodotto quattro cose: architecture decision record per le scelte fatte, con il ragionamento che le ha determinate; opzioni target con costi onesti — di solito due o tre, ognuna con i suoi rischi prezzati, invece di un’unica raccomandazione patinata; un registro dei rischi di ciò che si è trovato, ordinato per quanto costerebbe sbagliarsi; e l’assunzione critica validata o confutata, con evidenze.
Ciò che non conclude una discovery: una descrizione dello stato attuale, per quanto accurata. La mappa dell’esistente è un input alle decisioni, non il deliverable.
L’anti-pattern: l’analisi come risultato
La modalità di fallimento della discovery è nota — le settimane diventano mesi, e il risultato è un documento di novanta pagine che descrive tutto e non decide nulla. Succede per una ragione prevedibile: descrivere è sicuro, decidere è esposto. Un documento può essere ammirato; una decisione può essere sbagliata.
La correzione è strutturale, non motivazionale: ogni filone della discovery prende il nome dalla decisione che serve. "Valutare il panorama delle integrazioni" invita alla geologia. "Decidere se il flusso ordini può passare per l’ESB esistente" invita a una risposta.
Regole di time-boxing e checklist di uscita
Regole che tengono onesta la discovery: di norma delimitiamo la discovery a due-quattro settimane, estendendola solo dove la decisione stessa richiede più evidenze — mai per deriva; personale senior e in numero ridotto; un read-out a metà percorso con le risposte preliminari, che fa emergere presto i rinvii; e la riunione decisionale prenotata per l’ultimo giorno prima che la discovery cominci, così la scadenza ha un pubblico.
Checklist di uscita — la discovery è conclusa quando: l’assunzione critica ha evidenze in un senso o nell’altro · ogni decisione sul percorso critico ha un ADR oppure un owner e una data · le opzioni portano costi che uno sponsor può confrontare · il registro dei rischi non metterebbe in imbarazzo nessuno tra sei mesi · e il team che costruisce dopo sa dire, in una pagina, cosa costruisce per primo e perché.
Un programma che parte così passa il primo sprint a costruire la cosa giusta. L’alternativa passa il quarto mese a scoprire ciò che la settimana zero avrebbe potuto dirle.