Asset
Mappare decisioni, incertezze e ownership
Una pratica per i primi 30 giorni: rendere visibili le decisioni già prese, quelle ancora aperte e chi ne ha realmente l'ownership, prima di trasformare ipotesi e aspettative in una target architecture.
Il primo rischio è trasformare ipotesi in vincoli
Nei primi giorni di un programma viene spesso chiesta una target architecture prima che mandato e decisioni siano realmente chiari. Il rischio non è soltanto disegnare male: è attribuire all'architettura scelte che nessuno ha davvero preso.
Mappare stato della decisione e ownership
- Elenca le decisioni che condizionano il lavoro.
- Per ciascuna, stabilisci se è realmente presa oppure ancora aperta.
- Raccogli la traccia che rende riconoscibile una decisione: scelta, contesto e conseguenze.
- Nomina chi può confermarla, modificarla o assumersene le conseguenze.
- Se scelta e ownership non sono coerenti, registra l'incertezza invece di trasformarla in constraint.
Riconoscere il debito decisionale
Una scelta trattata come definitiva ma priva di un'autorità che possa confermarla o cambiarla è debito decisionale. Un vendor indicato senza perimetro di integrazione, una data promessa senza owner o un confine dato per scontato non sono ancora constraint completi.