Scrivi una decisione che potrai rivedere

Conserva il ragionamento

Una riunione decisionale produce una scelta. Un documento decisionale conserva perché quella scelta fosse sensata.

Senza il ragionamento, un team successivo può scambiare un vincolo temporaneo per un principio permanente. Può anche ripetere una valutazione già completata dall’organizzazione.

AWS descrive gli architectural decision record come un modo per documentare decisioni e contesto. La stessa struttura concisa può aiutare con un modello operativo per lo sviluppo AI. Mantieni il documento abbastanza breve da essere letto dai responsabili.

Confronta alternative realistiche

Un’azienda fittizia deve mantenere la propria applicazione dei contratti. Considera tre opzioni:

Usa lo stesso ambito applicativo, periodo, ipotesi sui dati e aspettative del servizio. Evita di confrontare un servizio acquistato maturo con il solo costo del prototipo di un sistema interno.

Può essere appropriata anche una combinazione. Una piattaforma esistente può fornire ambienti e deployment mentre una software factory coordina lo sviluppo. Spiega interfaccia e responsabilità invece di forzare una scelta artificiale di tutto o niente.

Scrivi sei parti

1. Contesto. Indica il problema e le conseguenze di lasciarlo invariato.
2. Requisiti. Elenca le condizioni che un’opzione deve soddisfare.
3. Alternative. Registra le opzioni concrete e i principali compromessi.
4. Prove. Collega valutazioni, ipotesi di costo e domande irrisolte.
5. Decisione. Indica opzione scelta, ambito, responsabile e limiti accettati.
6. Revisione. Definisci la data o l’evento osservabile che richiede una nuova valutazione.

Distingui ciò che hai osservato da ciò che prevedi. «La valutazione ha completato questa modifica di manutenzione» è un’osservazione. «Il servizio dimezzerà il costo annuo di manutenzione» è una previsione che richiede prove e ipotesi esplicite.

Includi l’obiezione più forte

Per l’applicazione dei contratti, un servizio acquistato può ridurre il lavoro di integrazione ma creare dipendenza da un fornitore esterno. Registra l’obiezione e l’esercitazione di esportazione che ne affronta una parte. Non rimuovere l’obiezione perché il team preferisce l’opzione.

Indica quali elementi irrisolti bloccano l’attivazione. Assegna gli altri a responsabili con date. Una decisione di procedere non trasforma una domanda senza risposta su un controllo in un risultato verificato.

Rivedi il documento quando cambiano requisiti o prove. Aggiungi una nuova decisione quando cambia la scelta e conserva il ragionamento precedente. Prosegui con gli scenari pratici di Taiga per applicare questi principi ai flussi del prodotto.