Mappare decisioni, incertezze e ownership

Contenuto

Mappare decisioni, incertezze e ownership

Nei primi 30 giorni il programma ti chiede spesso un disegno. Il rischio, però, non è disegnare male: è trasformare in vincoli decisioni che nessuno ha davvero preso. Prima di costruire una target architecture, elenca le decisioni che pesano sul lavoro. Per ciascuna, prova a rispondere a due domande. La prima riguarda lo stato della decisione: è già stata presa oppure è ancora aperta? Una decisione è davvero presa quando esistono almeno una scelta riconoscibile, un contesto in cui è stata assunta e una traccia sufficiente per capire che cosa vincola il lavoro. Se esiste soltanto una direzione, un'aspettativa o una preferenza, trattala ancora come aperta. La seconda domanda riguarda l'ownership: chi ha l'autorità per confermare quella scelta, cambiarla o assumersene le conseguenze? Le due dimensioni non coincidono. Una decisione può essere stata comunicata al board e avere comunque un'ownership poco chiara. Allo stesso modo, può esserci un owner anche quando la scelta è ancora aperta. Questa mappa è uno degli output più utili dei primi 30 giorni. Non sostituisce il mandato: rende visibili i suoi confini. Se una scelta viene trattata come definitiva ma nessuno sembra avere l'autorità per confermarla o modificarla, non è semplicemente un vincolo: è debito decisionale. Se è stato indicato un vendor ma il perimetro di integrazione non è stato definito, non hai ancora un constraint completo. Hai un'ipotesi che deve diventare esplicita. Disegnare prima di aver chiarito decisioni e ownership rischia di attribuire all'architettura scelte che l'architetto non aveva il mandato di prendere.