팀 프로토콜을 정의하는 법

팀 프로토콜이란 무엇인가

팀을 하나의 부품이라고 생각해 보자. 그러면 팀 프로토콜은 그 부품의 사용 설명서, 그러니까 입력 명세에 해당한다.

• 무엇을 입력으로 받는가
• 어떤 형식으로 받는가
• 무엇은 받지 않는가
• 입력이 어긋나면 어떻게 처리하는가

이 네 가지를 팀이 스스로 적어 둔 문서가 팀 프로토콜이다. 길 필요는 없다. 받는 쪽 사람이 직접 쓰고, 한 번 써서 덮어 두는 게 아니라 계속 고쳐 가는 살아 있는 문서면 된다.

미리 적어 두면, 목소리 큰 사람이 못 이긴다

4편에서, 명세가 없으면 결국 목소리 큰 사람 말대로 흘러간다고 적었다. 제대로 아는 사람이 아니라, 회의실에서 제일 자신 있게 단언하는 사람이 받는 쪽 모양을 멋대로 정해 버리는 풍경이다.

프로토콜은 바로 이걸 막는다. 입력 명세가 미리 적혀 있으면 목소리만으로는 안 통한다. 누가 아무리 큰 소리로 우겨도, 받는 쪽이 "우리는 입력을 이렇게 받습니다"라고 적힌 문서를 펼치면 그걸로 끝이다.

미리 적어 둔다는 건 결국, 목소리 큰 쪽이 아니라 제대로 아는 쪽이 이기도록 판을 깔아 두는 일이다.

네 가지 질문

팀이 자기 프로토콜을 쓸 때 던질 질문은 네 가지면 충분하다.

1. 무엇을 받는가 — 어떤 입력이 들어와야 우리 팀이 비로소 움직일 수 있는가
2. 어떤 형식으로 받는가 — 필드, 예시, 그리고 필수와 선택의 구분
3. 무엇은 받지 않는가 — 받지 않을 것들의 목록. 이게 없으면 결국 다 받게 된다
4. 어긋날 때 누가 정하는가 — 입력이 모호하거나 다른 팀과 부딪칠 때, 1차 결정 권한이 누구에게 있는가

이 네 가지만 적혀 있어도 받는 쪽 모양은 웬만큼 잡힌다. 나머지 세부는 일하면서 하나씩 덧붙으면 된다.

출력이 아니라 입력이 먼저다

여기서 흔히 하는 실수가 하나 있다. 팀이 "우리는 무엇을 만든다"만 적는다는 것이다. R&R 문서, 팀 소개, OKR — 죄다 출력 쪽 이야기다.

그런데 협업이 막히는 자리는 만드는 쪽이 아니라 받는 쪽이다. 무엇을 만드는지 아무리 잘 설명해도, 다른 팀이 그걸 어떻게 받아 가야 하는지는 거기서 알 수 없다. 입력 명세가 없는 팀은 결국, 일을 받을 때마다 매번 처음부터 다시 묻는 팀이 된다.

그래서 입력을 적어 두는 일이 출력을 설명하는 일보다 값지다. 협업은 바로 그 자리에서 시작되니까.

작게 시작한다

완벽한 프로토콜을 처음부터 만들 수는 없다. 그걸 목표로 삼으면 영영 시작도 못 한다.

그러니 작게 시작한다. 한 팀의, 한 입력부터.

가장 자주 받는 입력 하나를 골라, 앞의 네 질문에 대한 답을 한 페이지에 적는다. 그리고 다른 팀에 공유한다. 그 한 페이지가 실제 협업 자리에서 인용되기 시작하면, 그때 다음 입력을 적는다. 프로토콜은 책상에서 한 번에 완성되는 게 아니라, 매번 진짜 협업이 일어나는 자리에서 조금씩 자란다.

그렇게 해야 문서가 죽지 않고 살아 있다.

누가 적는가

한 가지만큼은 양보하지 않는 게 좋다. 받는 쪽 사람이 직접 적어야 한다는 것.

외부 컨설턴트도, 옆 팀 리더도, 디렉터도 대신 적어 줄 수 없다. 바깥에서 짐작으로 적어 준 명세는, 받는 쪽이 끝내 "내 것이 아니다"라고 느끼고 따르지 않는다.

그리고 받는 쪽 사람이 적기를 꺼리거나 적지 못한다면 — 그것부터가 큰 신호다. 자기 입력이 무엇인지 모르고 있거나, 그걸 정할 권한이 자기에게 있다고 믿지 않는다는 뜻이니까. 둘 다 협업을 시작하기 전에 먼저 풀어야 할 문제다.

다음 편에서는 같은 생각을 자산 인벤토리에 적용해 본다. 무엇을 가지고 있는지도, 결국 직접 적어 봐야 안다.