8 min read

의사결정 프레임워크: 의사결정을 잘하기 위해 먼저 결정해야 할 것들

멘탈모델, 개념, 접근법, 원칙 시리즈의 글입니다.

일하며 배우고 써먹은 멘탈모델, 개념, 접근법, 원칙들
그동안 제가 일을 하면서 배우고 활용해 온 멘탈모델, 개념, 접근법, 원칙들을 정리하고 있습니다. 읽는 분들에게 도움이 됐으면 합니다. 현재까지 쓴 글들 의사결정 * 의사결정 프레임워크: 의사결정을 잘하기 위해 먼저 결정해야 할 것들 앞으로 쓸 글들 (후보) 의사결정 데이터가 없는데도 데이터 기반 의사결정에 집착하면, 제대로 결정할 수 없다. 충분한 데이터, 충분한 샘플

리더가 의사결정을 제대로 내리지 못하면 함께 일하는 사람들이 힘들어집니다. 빨리 의사결정해야 할 사안을 오랫동안 질질 끄는가 하면, 사안을 잘 알지 못하는 리더가 단독으로 결정을 해서 수준 낮은 의사결정을 하는 경우를 다들 몇 번씩은 경험하셨을 겁니다.

의사결정 프레임워크를 염두에 두고 있으면 그런 리더가 되지 않을 가능성이 높아집니다. 프레임워크라고 해서 어렵거나 거창한 것은 아니고, 상식적으로 생각할 수 있는 것들입니다.

의사결정 전에 결정할 6가지

의사결정을 잘하려면 미리 결정해야 할 것들이 있습니다. 앤디 그로브(Andy Grove)는 저서 "High Output Management"의 'Chapter 5. Decisions, Decisions'에서 의사결정을 위해서 매니저는 다음 여섯 가지 질문에 대한 답을 미리 내려야 한다고 말합니다.

  1. What decision needs to be made? (어떤 의사결정을 내려야 하나?)
    • 어떤 일을 진행하려면 결정해야 할 것들이 있습니다.
    • 무엇을 결정해야 하는지 정의해야 이어지는 질문들에 답을 할 수 있습니다.
    • 의외로 여기에 대한 답을 내리지 못하고 마구잡이로 일을 진행하는 경우도 많습니다.
  2. When does it have to be made? (언제까지 결정해야 하나?)
    • 의사결정에도 데드라인이 필요합니다.
  3. Who will decide? (누가 결정할 것인가?)
    • 의사결정권자가 누구인지 명확하게 정의합니다.
    • '다 함께 결정한다'라는 말은 책임을 회피하고 싶다는 말과 같습니다.
  4. Who will need to be consulted prior to making the decision? (의사결정을 내리기 전에 누구와 상의를 해야 하나?)
    • 사안에 대해 잘 모르는 리더가 독단적으로 결정하면 함께 일하는 사람들이 피곤해집니다.
    • 의사결정의 퀄리티를 높이기 위해 회사 내에서 사안을 잘 아는 구성원들과 먼저 상의해야 할 수 있습니다.
    • 의사결정의 영향을 크게 받는 구성원들의 피드백을 들어야 할 수도 있습니다.
  5. Who will ratify or veto the decision? (의사결정을 승인하거나 거부할 권한을 누가 가지고 있나?)
    • 이 사람은 3번에서 정의한 의사결정권자처럼 사안을 세세히 열심히 들여다보지는 않지만, 조직을 더 크게 책임지는 사람으로서 의사결정을 최종적으로 승인하거나 거부할 권한을 가집니다.
    • 예를 들어 3번의 '누가 결정할 것인가'에서 '이 사안의 의사결정권자는 프로덕트 리더이다'라고 정의하더라도, CEO가 최종적으로는 그 결정을 뒤엎을 수 있습니다.
    • 가능하면 권한 위임이 잘 이뤄져서 의사결정을 뒤엎는 일이 없으면 좋지만, 현실적으로는 필요한 역할입니다. 권한 위임이 '모든 결정을 당신 맘대로 하세요'라는 뜻은 아니기 때문입니다.
  6. Who will need to be informed of the decision? (의사결정이 내려진 뒤에 누가 전달 받아야 하나?)
    • 의사결정에 영향을 받는 사람들이 누구인지 정의하고, 그들에게 적시에 커뮤니케이션해야 합니다.

6가지를 외우기 어렵다면 RACI (혹은 DACI)

앤디 그로브 선생님이 제시한 프레임워크는 유용하지만, 외우고 기억하기 어렵다는 단점이 있습니다. 태정태세문단세, 칼카나마가 괜히 있는 게 아니죠. 여섯 문장을 기억하기 어려우니 RACI만 기억합시다. RACI는 각각 Responsible, Accountable, Consulted, Informed를 뜻합니다.

  • Responsible
    • 위 프레임워크의 3번, '누가 결정할 것인가'에 해당하는 사람입니다.
    • 책임을 지고(responsible) 의사결정을 하는 사람입니다.
  • Accountable
    • 위 프레임워크의 5번, '의사결정을 승인하거나 거부할 권한을 누가 가지고 있나?'에 해당하는 사람입니다.
    • 의사결정에 대한 최종적인 책임(accountability)을 지는 사람이기 때문에, 결정을 최종적으로 승인하거나 거부할 권한을 가집니다.
  • Consulted
    • 위 프레임워크의 4번, '의사결정을 내리기 전에 누구와 상의를 해야 하나?'에 해당하는 사람(들)입니다.
  • Informed
    • 위 프레임워크의 6번, '의사결정이 내려진 뒤에 누가 전달 받아야 하나?'에 해당하는 사람(들)입니다.

Responsible과 Accountable의 개념이 어려워서인지, DACI라는 용어를 쓰기도 합니다. DACI는 각각 Driver, Approver, Contributors, Informed를 뜻합니다. (Driver가 Responsible, Approver가 Accountable입니다.)

중요한 건 자기규율(self-discipline)

모두 상식적으로 생각할 수 있는, 어렵지 않은 개념이죠. 다만 이 상식을 실천으로 옮기는 자기규율(self-discipline)을 유지하는 것은 어려운 일입니다. 어쩌면 리더에게 중요한 건 지식보다는 자기규율인지도 모르겠습니다.

안내: 프로덕트 조직과 개인을 위한 코칭

프로덕트 조직, 혹은 개인(제품 리더, PM, PO 등)을 대상으로 한 코칭을 제공하고 있습니다. 아래 이야기들이 내 얘기로 느껴지는 분들께 도움을 드립니다. 자세한 내용은 링크된 페이지를 참고해주세요.

  • 제품에서 해야 할 일들은 쏟아지는데, 어떤 기준으로 우선순위를 설정하면 좋을지 답을 내리지 못하고 있다. 명확한 방향성이 없이 그때 그때 급한 일을 쳐내는 식으로 일하고 있다.
  • 지표를 개선해야 하는데, 어떤 식으로 접근해야 할지 모르겠다. 어떤 지표를 봐야 좋을지 모르겠다.
  • 조직에 큰 영향을 끼칠 수 있는 의사결정을 해야 하는데, 하나를 택하면 포기해야 하는 것도 명확해서 쉽게 결정을 내리지 못하고 있다. 이로 인해 리더로서 자신감이 떨어진다.
  • 제품 조직과 다른 부서 간 의견 차이와 갈등이 있다. 다른 조직의 입김 때문에 제품 조직이 꼭 필요한 일을 제대로 수행하기 어렵다.
코칭 및 컨설팅 안내
개인 코칭: 프로덕트 리더 개인 코칭: 프로덕트 리더프로덕트 조직 리더들을 위한 코칭을 제공합니다.Thinker-Practitioner김민우 / Minwoo Kim 팀 코칭: 프로덕트 조직 코칭/컨설팅 프로덕트 조직 코칭/컨설팅프로덕트 조직을 위한 코칭, 컨설팅을 제공합니다.Thinker-Practitioner김민우 / Minwoo Kim About Me * 스타트업에서 프로덕트, 그로스(growth), 데이터 분석, 조직 운영 등의 일을 해 왔습니다. 구체적으로 어떤