RAPID, RACI, DACI, SPADE: Scegli uno, poi eseguilo realmente

La decisione che quattro persone pensavano di possedere

Il cambiamento di prezzo è stato inviato di martedì. Mercoledì, il VP delle Vendite ha chiesto perché non avesse firmato — pensava di possedere il prezzo. Il CFO presumeva di avere l'ultima parola; aveva approvato il modello. Il responsabile del prodotto aveva effettivamente preso la decisione, credendo fosse di sua competenza. E il CEO, leggendo di questo nel documento di tutti i dipendenti, era sotto l'impressione che decisioni come questa arrivassero a lui. Quattro persone, una decisione, quattro proprietari sinceri — e ora un dibattito sul rollback che è in realtà un dibattito sulla proprietà travestito da questione di prezzo.

Hai visto una versione di questo. È il fallimento di governance più comune nelle organizzazioni in crescita, e ha un ampio assortimento di rimedi: RAPID, RACI, DACI, SPADE — framework il cui contenuto intero è scrivere chi svolge quale ruolo prima che venga presa la decisione. Le lettere differiscono; l'intuizione è identica.

Il che punta al vero problema. I team spendono energia a scegliere tra i framework — post di confronto, dibattiti in workshop su se Consulted differisca da Input — e poi assegnano le lettere dopo la decisione, come documentazione. Assegnare i ruoli dopo è solo narrazione. Questo tutorial dedica una tabella alla scelta e il resto all'esecuzione: il flusso di lavoro applicato, che è identico indipendentemente dalle lettere che scegli. (Per la teoria e la storia dei framework, la nostra guida ai framework decisionali li copre insieme al resto degli strumenti — questo tutorial non lo ripete deliberatamente.)

I quattro framework in un'unica tabella

Esistono sei lavori in ogni decisione consequenziale. I framework li chiamano in modo diverso:

Scegli dai tuoi veri blocchi: veri detentori di veto → RAPID; intrico di esecuzione → RACI; cultura del process-runner → DACI; un team che salta la scrittura del perché → SPADE. Poi fermati. I passi 2 fino a 10 qui sotto non cambiano con la tua scelta — solo le lettere nel passo 3 cambiano. Quella frase è la più utile del tutorial: termina la ricerca del framework e inizia l'esecuzione, che è il comportamento che migliora effettivamente le decisioni.

Impostazione: ambito, poi ruoli, poi il caso

1. 1Nomina la decisione come una richiesta principale. "Passeremo a una tariffazione basata sull'uso per il livello Team nel primo trimestre." Il suo autore è, di fatto, il Raccomandatore/Conduttore — l'autorialità è visibile, quindi il R è registrato fin dal primo secondo. Checkpoint: la radice esiste; il suo autore è la persona che sta costruendo il caso.
2. 2Ambito di chi partecipa con livelli di visibilità. Imposta la visibilità della discussione — pubblica, a livello di inquilino, dipartimentale o privata — per corrispondere all'insieme di Input previsto. Una decisione a livello dipartimentale è consultabile da quel dipartimento per costruzione; non ti stai affidando a qualcuno che si ricordi di coinvolgere il Legale. Checkpoint: la visibilità corrisponde all'insieme di Input, non all'abitudine.
3. 3Registra l'assegnazione dei ruoli — prima del primo argomento. Come pro-figlio della radice: "Decisore: A. Raccomandatore: B. Concordare: C, D. Input: Eng, Legale. Informato: tutti." Datato, attribuibile e contestabile come qualsiasi altra cosa sull'albero. Questo ordinamento è il punto centrale dei framework sui diritti decisionali: i ruoli assegnati dopo il dibattito descrivono semplicemente ciò che è accaduto. Checkpoint: l'argomento di assegnazione precede ogni argomento di caso.
4. 4Costruisci il caso. Opzioni come nodi fratelli, ognuna con i propri pro e contro — la stessa struttura del tutorial sui decision records, inclusi le opzioni rifiutate di cui un lettore chiederà in seguito. Checkpoint: ogni alternativa reale ha un nodo.

Consultazione di cui puoi dimostrare che è avvenuta

"Sei stato consultato?" è la domanda su cui si basa ogni decisione contestata — e nella maggior parte delle organizzazioni la risposta onesta è un'alzata di spalle: c'è stata una riunione, c'è stato un thread, i ricordi differiscono. Il flusso di lavoro qui rende la consultazione una ricevuta, non un ricordo:

1. 1Ogni detentore di input apre una catena di domande e risposte sulla raccomandazione: la loro domanda, la risposta del raccomandatore, un seguito, una risposta — completa. La catena completata è la prova che la consultazione è avvenuta: chi ha chiesto, cosa è stato risposto, quando. Un detentore di input che non ha nulla da chiedere rifiuta esplicitamente. Checkpoint: ogni detentore di input ha ≥1 catena completata o un pass esplicito.
2. 2Un titolare di accordo che obietta apre una catena di Revisione: la loro valutazione, la risposta del Raccomandatore, il follow-up, la risposta. Diversi titolari di accordo significano diverse catene parallele, ciascuna risolta secondo i propri termini — nessun blocco irrisolto nascosto in una discussione di gruppo. Checkpoint: non esiste obiezione attiva al di fuori di una catena.
3. 3Due titolari di diritti in conflitto → Catena di compromesso. Uno propone la posizione intermedia all'altro, ufficialmente. Risolto o meno, il tentativo è documentato — il che trasforma "Legale e Finanza non hanno mai concordato" da un'accusa in uno scambio leggibile. Checkpoint: conflitti risolti o visibilmente attivi.

Decidendo contro la stanza e annotando il motivo

Prima della chiamata, tutti valutano le opzioni — una valutazione etichettata per ciascuna. Leggi questo per quello che è: evidenza di dove si trovava la stanza, non un voto. Non c'è un quorum, nessuna soglia, nessun spareggio; l'intera premessa del framework è che un essere umano nominato decide.

Poi il Decider decide — come un argomento, redatto da loro, sotto l'opzione scelta, esponendo il ragionamento. Ecco la frase più preziosa che il flusso di lavoro produce: se la chiamata va contro le valutazioni, è nel nodo del Decider che questo viene spiegato. "La stanza tendeva verso l'opzione B; scelgo A perché il rischio di rinnovo dell'impresa supera la preferenza della distribuzione" — una frase che separa la leadership del disaccordo e impegno dalla decisione per decreto, e la cosa esatta di cui è fatta una decisione durevole. Un Decider che non lo scrive non sta gestendo un framework; lo sta indossando.

• ✓Checkpoint: distribuzione catturata prima della chiamata; decisione registrata come l'argomento del Decisore, con motivazione — obbligatoria quando contraddice la stanza.

Informare senza un'email separata

Ultima lettera, passo più economico: ampliare la visibilità della decisione una volta presa. Il gruppo Informato apre la discussione e legge non solo il risultato ma anche il dibattito — le opzioni, le catene di consultazione, il perché del Decisore. "Perché è cambiato il prezzo?" non ha mai bisogno di un proprio thread email, perché la risposta è il record stesso. Fatto in questo modo, informare è anche l'inizio di buy-in: le persone si impegnano in decisioni il cui ragionamento possono esaminare.

• ✓Checkpoint: visibilità ampliata al set Informed; l'annuncio collega il record invece di parafrasarlo.

Limitazioni oneste

• ✗Non esiste un campo per il ruolo decisionale. Le lettere sono una convenzione registrata — datata e attribuibile, ma il prodotto non le assegna né le verifica. Un ruolo RBAC è un livello di autorizzazione, mai un diritto decisionale.
• ✗Le valutazioni non sono voti ponderati. Un valore e un'etichetta per persona, nessun quorum, nessuna soglia, nessun spareggio. Il Decider è lo spareggio.
• ✗Le letture degli ambiti di visibilità, non obbligo. L'ambito del dipartimento significa che il Legale può vederlo — la catena di domande e risposte completata, non l'impostazione di visibilità, è la prova che hanno partecipato.
• ✗Una catena è quattro giri, poi completa — e completo ≠ concordato. Il titolare del consenso dissenziente che si impegna comunque è documentato come ascoltato, non convertito.
• ✗Nessuna di queste cose risolve un Decisore riluttante. La struttura espone una decisione non presa più rapidamente — il nodo vuoto in cui dovrebbe esserci la chiamata è molto visibile — ma non può effettuare la chiamata.

Lezioni pratiche

• ✓Scrivi l'argomento del ruolo nella riunione di avvio, dal vivo, prima che qualcuno discuta i meriti. Trenta secondi adesso contro l'archeologia del mercoledì dopo.
• ✓Mantieni la lista degli Accordi brutalmente corta. Ogni titolare di Accordo è un potenziale blocco con una catena da risolvere; la maggior parte degli "approvatori" è in realtà Input. La disciplina di RAPID è dirlo ad alta voce.
• ✓La consultazione rifiutata è un record anch'essa. Un titolare di input che passa esplicitamente non può successivamente rivendicare l'esclusione — proteggili e proteggi te stesso rendendo visibile il pass.
• ✓Riutilizza l'assegnazione. I tipi di decisione ricorrenti (prezzi, assunzione di bande, selezione dei fornitori) mantengono le stesse lettere — incolla l'argomento del ruolo come modello e aggiorna i nomi.

Mercoledì, rivisitato

Rifai la modifica dei prezzi attraverso il flusso di lavoro. Il VP delle Vendite è un Agree-holder — la sua obiezione è una catena di Revisione completata, risolta due volte, e si è impegnata. Il CFO è Input — la sua consultazione è una ricevuta. Il responsabile del prodotto è il Decisore tramite un argomento datato scritto prima del dibattito, e la sua motivazione per andare contro l'orientamento della sala è un paragrafo che tutti possono leggere. Il CEO è Informato — il documento di tutti i membri collega l'albero. Stessa decisione, possibilmente stesso risultato. Ma mercoledì non c'è nulla da rielaborare, perché l'unica domanda che alimenta sempre quelle lotte — chi aveva il diritto di decidere questo? — è stata risposta prima che qualcuno argomentasse.