목차4개 항목
협업에서 갈등은 대개 결정 자체보다 결정 과정이 불분명할 때 생긴다. 무언가를 정해야 할 때 아래 6가지를 먼저 합의해 두면, 누가 왜 그렇게 정했는지에 대한 혼선이 크게 줄어든다.
6가지 질문
| # | 정할 것 | 질문 |
|---|---|---|
| 1 | 안건 | 정확히 어떤 결정을 내려야 하는가? |
| 2 | 기한 | 언제까지 결정해야 하는가? |
| 3 | 결정권자 | 누가 최종적으로 결정하는가? |
| 4 | 상의 대상 | 결정 전에 누구의 의견을 들어야 하는가? |
| 5 | 승인·거부권자 | 결정을 승인하거나 뒤집을 수 있는 사람은 누구인가? |
| 6 | 공유 대상 | 결정 후 누구에게 결과를 전달해야 하는가? |
활용 팁
- 3~6번은 흔히 쓰이는 RACI(Responsible·Accountable·Consulted·Informed) 역할 구분과 같은 발상이다. 회의록이나 이슈 템플릿에 칸으로 만들어 두면 습관이 된다.
- 기한이 없는 결정은 대체로 미뤄진다. 2번을 빠뜨리지 않는다.
- 6번을 놓치면 "왜 나만 몰랐냐"는 불만이 생긴다. 결정만큼 공유도 일의 일부다.
결정권자를 합의로 위임한다
이 절은 테오(teo)의 「스프린트, 협업을 위한 장치 그리고 마인드」(2024.02)와 「테오의 스프린트 15기」(2023.07) 회고를 요약·재구성했다.
3번(결정권자)이 비어 있는 팀이 흔하다. 특히 수평적인 팀은 모두가 결정권자라고 생각해서 실패한다. 완전한 합의를 고집하면 다수결로 소수의 불만을 남기거나, 아무도 책임지지 않으려 폭탄 돌리기를 하거나, 가장 고집 센 사람의 뜻대로 가고 나중에 그 사람을 원망한다.
- 결정을 합의하지 말고 결정권자를 합의로 뽑는다. 수평적이라는 것은 결정권이 나뉜 것이 아니라 위임 과정이 수평적이라는 뜻이다.
- 결정권자는 권한이 아니라 역할이다. 분야마다 달라도 된다. 진행(MC), 기술 스택과 태스크(PL), UX 같은 식으로 나누면 한 사람에게 권력이 몰리지 않는다.
- 결정권자는 모두의 의견을 듣고 혼자 정하고, 모두는 그 결정을 따른다. 의견이 갈리면 당사자끼리 설전하지 말고 각자 결정권자에게 어필한다. 결정권자가 완충재가 된다.
- 결정 전에 의견을 다 펼쳐 둔다. 각자 생각을 끝까지 설명할 기회를 주고, 투표 전에 선택과 이유를 먼저 적게 하고 발언 순서는 무작위로 정하면 대세에 휩쓸리지 않는다. 분석은 모두가, 결정은 한 사람이 한다.
치열한 결정은 오히려 빨리
선택이 팽팽하다는 것은 A와 B의 차이가 작다는 뜻이다. 대개 취향 차이이거나 둘 다 해 보고 판단할 수 있다. 이런 결정은 신중함보다 빠르고 강하게 정하는 편이 낫다. 반대로 되돌릴 수 없는 결정이라면 신중해야 하고, 다수결로 넘기지 말고 결정권자가 책임지고 정한다.
관련 노트: 제품 중심 개발자, 회의 잘하는 법, 협업을 잘하는 개발자