RAPID, RACI, DACI, SPADE: 하나를 선택한 다음 실제로 실행하세요.

네 사람이 자신들이 소유하고 있다고 생각했던 결정

가격 변경이 화요일에 발송되었습니다. 수요일에 영업 부사장이 왜 서명을 하지 않았는지 물었습니다. 그녀는 가격을 담당하고 있다고 생각했습니다. CFO는 그가 최종 결정을 내릴 권한이 있다고 가정했습니다. 그는 모델을 승인했으니까요. 제품 책임자는 실제로 결정을 내렸고, 그것이 그녀의 결정이라고 믿었습니다. 그리고 CEO는 전체 회의 문서에서 이 내용을 읽고, 이런 결정이 자신에게 온다고 생각했습니다. 네 명의 사람, 하나의 결정, 네 명의 진정한 소유자 — 그리고 이제 가격 조정 복장을 한 소유권 논쟁이 벌어지고 있습니다.

당신은 이 버전을 본 적이 있습니다. 이는 성장하는 조직에서 가장 흔한 거버넌스 실패이며, 잘 정리된 해결책들이 있습니다: RAPID, RACI, DACI, SPADE — 이 프레임워크의 전체 내용은 결정이 내려지기 전에 누가 어떤 역할을 하는지 적어두는 것입니다. 글자들은 다르지만, 통찰력은 동일합니다.

실제 문제를 지적합니다. 팀은 프레임워크를 선택하는 데 에너지를 소비합니다 — Consulted가 Input과 다른지에 대한 비교 게시물, 워크숍 토론 등을 하며 — 그리고 나서 결정 후에 문서화로서 글자를 할당합니다. 역할을 나중에 할당하는 것은 단지 서술일 뿐입니다. 이 튜토리얼은 선택에 대한 한 표를 사용하고 나머지는 실행에 대한 것입니다: 적용된 워크플로우는 어떤 글자를 선택하든 동일합니다. (프레임워크의 이론과 역사에 대해서는, 우리의 결정 프레임워크 가이드가 나머지 도구 상자와 함께 다룹니다 — 이 튜토리얼은 의도적으로 이를 반복하지 않습니다.)

하나의 표에 있는 네 가지 프레임워크

어떤 중요한 결정에는 여섯 가지 직업이 존재합니다. 프레임워크는 그것들을 다르게 명명합니다:

진정한 차단자를 선택하세요: 실제 거부권 보유자 → RAPID; 실행 얽힘 → RACI; 프로세스 실행 문화 → DACI; 이유를 적지 않는 팀 → SPADE. 그 후 멈추세요. 아래의 2단계부터 10단계까지는 선택에 따라 변경되지 않습니다 — 오직 3단계의 글자만 변경됩니다. 그 문장은 튜토리얼에서 가장 유용한 문장입니다: 프레임워크 쇼핑을 끝내고 실행을 시작하게 하며, 이는 실제로 결정을 개선하는 행동입니다.

설정: 범위, 그 다음 역할, 그 다음 사례

1. 1결정을 근본 주장으로 명명하십시오. "우리는 1분기에 팀 계층에 대해 사용 기반 가격으로 전환할 것입니다." 그 저자는 실제로 추천자/주도자이며, 저작권이 명확하게 드러나므로 R은 처음부터 기록에 남아 있습니다. 체크포인트: 근본이 존재하며, 그 저자는 사례를 구축하는 사람입니다.
2. 2가시성 계층에 참여하는 범위. 논의의 가시성을 설정하세요 — 공개, 테넌트 전체, 부서 또는 비공개 — 의도된 입력 세트에 맞게. 부서 범위의 결정은 해당 부서에서 구성상 참조할 수 있습니다; 누군가가 법무팀을 포함시키는 것을 기억하기를 기대하지 않습니다. 체크포인트: 가시성이 입력 세트와 일치하며, 습관이 아닙니다.
3. 3역할 할당을 기록하십시오 — 첫 번째 주장 이전에. 루트의 프로 아이로서: "결정자: A. 추천자: B. 동의: C, D. 입력: Eng, Legal. 정보 제공: 모든 손." 날짜가 기재되고, 귀속 가능하며, 나무의 다른 모든 것처럼 도전할 수 있습니다. 이 순서는 의사결정 권한 프레임워크의 핵심입니다: 토론 후에 할당된 역할은 단지 발생한 일을 설명할 뿐입니다. 체크포인트: 할당 주장은 모든 사례 주장보다 앞서야 합니다.
4. 4사례를 구축하라. 각기 장단점이 있는 형제 노드로서의 옵션 — 결정 기록 튜토리얼과 동일한 구조로, 독자가 나중에 질문할 거부된 옵션도 포함된다. 체크포인트: 모든 실제 대안은 노드를 가진다.

증명할 수 있는 상담

"당신은 상담을 받았나요?"는 모든 논란이 있는 결정이 결국 의존하는 질문입니다 — 그리고 대부분의 조직에서 솔직한 대답은 어깨를 으쓱하는 것입니다: 회의가 있었고, 스레드가 있었고, 기억이 다릅니다. 여기서의 작업 흐름은 상담을 영수증으로 만들고, 회상이 아닙니다:

1. 1각 Input-holder는 추천에 대한 Q&A 체인을 엽니다: 그들의 질문, 추천자의 답변, 후속 질문, 답변 — 완료. 완료된 체인은 상담이 이루어졌다는 증거입니다: 누가 질문했는지, 무엇이 답변되었는지, 언제. 질문할 것이 없는 Input-holder는 명시적으로 거절합니다. 체크포인트: 모든 Input-holder는 ≥1개의 완료된 체인 또는 명시적인 패스를 가지고 있어야 합니다.
2. 2이의를 제기하는 동의 보유자는 검토 체인을 엽니다: 그들의 평가, 추천자의 응답, 후속 조치, 응답. 여러 동의 보유자는 각각의 조건에 따라 해결되는 여러 개의 병렬 체인을 의미합니다 — 그룹 스레드에 숨겨진 해결되지 않은 블록이 없습니다. 체크포인트: 체인 외부에 살아있는 이의는 존재하지 않습니다.
3. 3갈등 중인 두 합의 보유자 → 타협 체인. 한 사람이 다른 사람에게 중간 입장을 제안하며 기록에 남깁니다. 해결되었든 아니든, 시도는 문서화되어 "법무와 재무는 결코 합의하지 않았다"는 주장을 읽을 수 있는 교환으로 전환합니다. 체크포인트: 갈등은 해결되었거나 눈에 띄게 진행 중입니다.

방을 선택하지 않기로 결정하고 그 이유를 적기

전화 통화 전에 모든 사람이 옵션을 평가합니다 — 각각에 레이블이 붙은 평가. 이것이 무엇인지 읽어보세요: 방의 입장을 나타내는 증거, 투표가 아님. 정족수도 없고, 기준도 없으며, 동점도 없습니다; 이 프레임워크의 전체 전제는 이름이 있는 사람이 결정한다는 것입니다.

그런 다음 결정자가 선택한 옵션 아래에서 그들이 작성한 주장을 결정합니다. 그리고 여기 워크플로우가 생성하는 가장 가치 있는 문장이 있습니다: 평가와 반대되는 결정이 내려지면, 그 설명은 결정자의 노드에서 이루어집니다. "회의는 옵션 B 쪽으로 기울었지만, 저는 A를 선택합니다. 왜냐하면 기업 갱신 위험이 배급의 선호보다 크기 때문입니다." — 이 한 문장은 반대하고 헌신하는 리더십과 법령에 의한 결정의 차이를 구분하며, 지속 가능한 결정의 본질입니다. 이를 작성하지 않는 결정자는 프레임워크를 운영하는 것이 아니라, 그것을 착용하고 있는 것입니다.

• ✓체크포인트: 통화 전에 캡처된 배포; 방과 모순될 때 필수적으로 이유와 함께 결정자가 자신의 주장을 기록한 것으로 간주됩니다.

별도의 이메일 없이 알림

마지막 편지, 가장 저렴한 단계: 결정의 가시성을 넓히기 한 번 이루어진 후. 정보 제공자는 논의를 열고 결과뿐만 아니라 토론 — 옵션, 상담 체인, 결정자의 이유를 읽습니다. "가격이 왜 변했나요?"는 결코 별도의 이메일 스레드를 필요로 하지 않으며, 그 이유는 기록 자체입니다. 이렇게 하면 정보 제공은 동의의 시작이기도 합니다: 사람들은 그 이유를 검토할 수 있는 결정을 약속합니다.

• ✓체크포인트: 정보 제공 집합에 대한 가시성이 확대되었습니다; 발표는 기록을 요약하는 대신 연결합니다.

정직한 한계

• ✗결정 역할 필드가 없습니다. 이 서신들은 기록된 관례로, 날짜가 기재되어 있고 귀속이 가능하지만, 제품은 이를 할당하거나 확인하지 않습니다. RBAC 역할은 권한 수준이지, 결정을 내릴 권리가 아닙니다.
• ✗평가는 가중치가 있는 투표가 아닙니다. 한 사람당 하나의 값과 레이블, 정족수 없음, 기준 없음, 동점 해소 없음. 결정자는 동점 해소자입니다.
• ✗가시성 범위 읽기, 의무 아님. 부서 범위는 법무가 볼 수 있음을 의미합니다 — 완료된 Q&A 체인, 가시성 설정이 아니라, 그들이 참여했다는 증거입니다.
• ✗체인은 네 번 돌고 나서 완성됩니다 — 그리고 완성 ≠ 동의. 그럼에도 불구하고 행동하는 반대하는 동의 보유자는 변하지 않은 것으로 기록됩니다.
• ✗이 모든 것이 내키지 않는 결정자를 고치는 것은 아니다. 구조는 결정되지 않은 결정을 더 빨리 드러낸다 — 호출이 있어야 할 빈 노드가 매우 눈에 띈다 — 하지만 호출을 할 수는 없다.

실용적인 수업

• ✓킥오프 미팅에서 역할 주장을 작성하세요, 누군가 장점을 논의하기 전에 실시간으로. 지금 30초 대기하는 것과 수요일 이후의 고고학적 분석.
• ✓동의 목록을 극단적으로 짧게 유지하세요. 모든 동의 보유자는 해결해야 할 체인을 가진 잠재적인 차단자입니다; 대부분의 "승인자"는 실제로 입력입니다. RAPID의 규율은 이를 소리 내어 말하는 것입니다.
• ✓거부된 상담도 기록입니다. 명시적으로 통과한 입력 보유자는 나중에 제외를 주장할 수 없습니다 — 그들과 자신을 보호하기 위해 통과를 보이게 하세요.
• ✓과제를 재사용하세요. 반복되는 결정 유형(가격 책정, 채용 밴드, 공급업체 선택)은 동일한 문자를 유지합니다 — 역할 인수를 템플릿으로 붙여넣고 이름을 업데이트하세요.

수요일, 다시 방문하다

가격 변경을 워크플로우를 통해 다시 실행하세요. 영업 부사장은 동의 보유자입니다 — 그녀의 이의는 완료된 검토 체인으로, 두 번 답변되었고, 그녀는 약속했습니다. CFO는 입력자입니다 — 그의 상담은 영수증입니다. 제품 리드는 논쟁 전에 작성된 날짜가 있는 주장을 통해 결정자이며, 방의 경향에 반하는 그녀의 근거는 모두가 읽을 수 있는 한 단락입니다. CEO는 통보받은 상태입니다 — 모든 직원 문서가 나무를 연결합니다. 같은 결정, 아마도 같은 결과. 하지만 수요일에는 다시 논의할 것이 없습니다, 왜냐하면 그 싸움을 촉발하는 유일한 질문 — 누가 이것을 결정할 권리가 있었는가? — 는 아무도 논쟁하기 전에 답변되었기 때문입니다.