회의의 방법
문제정의 - 브레인스토밍 - 우선순위 - 의사결정
예전에 일 처음 할 땐 막연히 긴 회의는 안 좋은 것이고 길게 이야기하는 것은 최대한 지양해야 한다고 인식하고 있었다. 전적으로 군 장교시절 경험했던 "답은 정해져 있지만 쓸데없이 긴"회의들을 수도 없이 경험했기도 하고, 이런 형식의 회의들을 희화화하고 조롱하는 콘텐츠들이 난무하던 시절에 스타트업계로 왔기 때문이 아닐까 싶다.
하지만 천편일률적으로 나쁘다고 평가하긴 이르다는 사실을 괜찮은 조직들에서 일을 해보며, 성공경험을 쌓은 사람들의 책들을 읽으며 알게 되었다. 3시간 4시간 동안 쉬는 시간까지 가져가며 회의를 해야햐는 경우도 있고, 슬랙으로 툭툭 몇 마디 던져가며 끝낼 회의도 있는 것이다.
오늘 소개할 것은 내가 이상적으로 생각하는 회의는 어떤 것인지다.
회의
모름지기 회의란 어떤 문제를 해결하기 위해 치열하게 고민하고 종단에는 합리적인 의사결정을 내리는 대화의 형식을 말한다. 여기서 키워드들을 꼽아보자면 "문제", "고민", "합리적인", "의사결정" 정도가 되겠다. 나는 이 네 가지 키워드를 일련의 과정으로 설명해보고자 한다.
1. "문제" - 문제 정의 과정
문제 정의, 비단 회의뿐만이 아니라 어떤 문제를 해결한다고 하면 단연 가장 먼저 해야 할 작업이다. 마치 식사를 하기 전에 식기를 세팅하듯, 빨래를 하기 전에 빨랫감을 넣듯 말이다. 우리가 풀어야 할 문제가 무엇인지 알고 모르고는 회의 혹은 앞으로 며칠, 몇 달을 진행할지도 모르는 이 업무에 대한 방향을 정한다.
우리가 풀고자 하는 문제가 무엇인지. 그것은 진짜 문제가 맞는지, 5 whys와 같은 방법론을 통해 이 문제가 진짜 문제가 맞는가에 대한 논의를 가진다. 너무 추상화된 문제라면 날카롭게 구체화하고, 우리의 문제가 아니라면 과감히 덜어낸다.
이 과정이 잘 이루어지면 개발자가 코드 한 줄도 안 짜고 문제를 해결할 수도 있고, 돈 한 푼도 안 들이고 거대한 이벤트를 개최할 수도 있다. 무엇보다도 귀한 시간을 내어 모인 회의체가 올바른 공동의 목표를 세울 수 있게 된다.
2. "고민" - 브레인스토밍 과정
우리가 해결해야 할 문제가 명확해졌다는 것은, 그 문제를 해결하기 위해 치열하게 고민해야 할 때라는 뜻이다. 팀이 가진 모든 역량을 투입해서 공동의 목표에 기여하는 것을 군 용어로 총력전이라고 부른다. 말 그대로 이 시간은 모든 걸 쏟아부어서라도 어떻게 하면 이 문제를 해결할 수 있을까를 고민하는 시간이다.
상상력도 좋다. 돈이 터무니없이 들어도 좋다. 일단 문제를 해결할 수 있다면 이야기해 본다. 브레인스토밍이란 생각에 제한을 두는 순간 브레인스토밍이 아니기 때문이다. 여기서 나온 결과물들은 어차피 우선순위에 의해 필터 된다. 그러니 시간낭비나 남들이 나를 안 좋게 볼 것 등을 고려하지 말고 이야기한다.
그렇게 유효한 문제 해결 방법들이 모였다면 다음 페이즈로 넘어갈 수 있다.
3. "합리적인" - 우선순위 부여 과정
이제 어떤 방식으로 이 문제를 풀지 결정할 때다. 위에서 거창하게 총력전을 언급하긴 했지만, 우리는 모든 걸 쏟아부을 순 없다. 그건 보통 도박이라는 용어로 따로 분류한다. 그러므로 리소스는 높은 확률을 가진 곳에 제한적으로 투자할 수밖에 없다. 리소스라 함은 영업일 기준으로 나가는 월세나 인건비, 서버비만을 말하는 건 아니다. 팀원들의 사기도 포함되고 회사에 대한 신뢰, 동기부여도 포함된다. 더 많은 무형의 가치들이 순간순간의 의사결정에 결정된다.
우선순위를 정하는 방법에는 여러 가지 기준과 방법론이 있을 수 있지만, 나는 투입된 리소스 대비 임팩트를 기준으로 삼는다. 리소스는 위에서 설명한 바와 같고, 임팩트는 회사가 얻을 매출, 고객수, 트래픽 등이나 고객이 얻을 사용자 경험, 프로덕트 생산자들이 얻을 생산성 등을 말한다.
여러분이라면 메가임팩트를 가져올 대단한 프로젝트여도 20명짜리 회사에서 개발자 5명에 디자이너 2명, PO, PM 각 1명이 1년 동안 몰입해야 하는 프로젝트라면 쉽사리 투입할 수 있겠는가? 그래서 최대한 적은 인원으로, 적은 기간 동안 큰 임팩트를 낼 수 있는지를 고민한다.
4. "의사결정" - 의사결정 과정
회의가 끝나면 그 결과로 의사결정이 이루어져야 한다. 보통 액션 플랜을 세운다라고도 부른다. 말만 하고 끝나는 회의에 어떤 의미가 있는가? 만약 너무나도 추상화된 문제를 풀거나 의사소통에 문제가 있어 이야기만 하다가 끝났다면 의사결정을 하기 힘들 수 있다. 그런 경우엔 회의체의 크기나 구성인원이 잘못되었을 확률이 있으므로 문제정의부터 다시해야한다.
이전 단계까지에서 구성인원 간 의견에 합치를 이뤘다면 아래와 같은 것들을 결정하게 될 것이다.
- 어떤 액션을 할지 정하기
- 이 회의 이후 어떤 채널에서, 어떤 문서로 소통할지 정하기
- 목표치 숫자로 정하기
- 마일스톤 정하기
- 담당자 할당하기
-...
*피드백 - 문제정의로 돌아가기
위의 도표를 보면, 이후 과정들을 진행하다가 뭔가 이상하다 싶으면 문제정의로 돌아가도록 되어있다. 나는 이 부분이 핵심이라고 생각한다. 보통 뭔가 이상하다면 문제가 잘못 정의되거나, 너무 추상화되어 있거나 범위가 너무 넓거나 좁다. 회의체의 중심엔 공동의 목표인 문제가 있어야 하는데 이것이 너무 허술하면 그 이후 과정들이 매끄럽게 진행되지 못한다.
뭔가 이상하다 싶으면 문제정의로 돌아가는 선택지를 떠올리자.
예시
모 커뮤니티 서비스 담당자인 가상의 인물 A의 사례로 설명해 보자. 이 커뮤니티의 문제는 사람들이 눈팅만 하고 간다는 것. 커뮤니티에 대한 참여가 필요한 시점이었고, 가장 쉬운 인터렉션인 게시글의 좋아요 버튼을 많이 눌러주길 바랐다.
회의를 소집하고, A가 생각하는 문제에 대해 정의한다. 아래와 같은 이야기들이 나오며 진짜 문제에 가까워진다. 문제가 정의될 수 있을 것이다. 뭐 어디까지나 예시니까 터무니없는 이야기일 수 있다.
*판단 근거로 데이터가 충분히 있다고 가정하자. 고객의 마우스 움직임 1px까지 추적할 수 있는 세상이니까.
"커뮤니티 상세에서 인터렉션이 적어 전반적인 활성화율이 낮다."
-> "좋아요 버튼 클릭률이 다른 인터렉션에 비해 낮다"
-> "좋아요 버튼 근처에 마우스가 올라갔음에도 누르지 않는 비율이 높다."
-> "좋아요 버튼이 눈에 띄지 않았기 때문이다"
문제 : "좋아요 버튼이 눈에 띄지 않아서 고객이 누르지 않는다."
문제가 정의되었으니 빠르게 브레인스토밍을 시작한다. 여러 가지 의견이 나왔다.
1. 모바일 사용자가 40%인데, 모바일용 게시글 상세화면은 밑으로 스크롤을 쭉 내려야만 좋아요가 나와요. 좋아요 버튼을 우측 하단 Floating으로 바꿀까요?
2. 좋아요를 누르면 1000개마다 1명씩 500포인트를 지급하는 이벤트를 여는 건 어때요?
3. 기갈나는 애니메이션을 좋아요 버튼을 누를 때 나오도록 바꿔볼까요?
4. 버튼 자체를 인식하기 쉽게 하기 위해 좋아요 버튼에 툴팁을 추가해요.
5. 공지글로 좋아요 버튼 좀 눌러달라고 호소를 해볼까요..?
A는 이들 중 현실성이 없는 의견들을 논리적으로 말하고 5번을 소거, 개발 리소스가 큰 2번 또한 제했다. 나머지는 해봄직한 괜찮은 의견들이라 탈락시키지 않았다. 이다음은 우선순위를 정해야 한다. 1번은 코드 2줄이면 끝난다. 디자인 리소스도 안 든다. 3, 4번은 둘 다 기획, 다자인 리소스가 필요하지만 임팩트를 고민해봄직 하기 때문에 1번을 우선 해보고 효과가 크지 않거나 리소스가 남으면 3,4번을 추가로 하기로 우선순위를 부여했다.
이제 의사결정만 남았다. A는 다음과 같이 의사결정을 내렸다.
1. 좋아요 버튼을 Floating Button 형태로 변환한다.
2. 오늘 퇴근 전까지 A/B 테스트 형태로 개발을 완료하고 내일 오전 배포 후 3일간 데이터 변화를 지켜본다.
3. 유의미한 상승(5% 이상) 이 없다면 롤백한다.
4. 투입되는 리소스는 1명의 FE개발자와 1 영업일의 기간.
5. 관련 논의는 "슬랙 스레드a"에서 이어가고, A가 "위키 문서a"에 진행 경과와 데이터를 취합한다.
좋은 예시일진 모르겠다. 하지만 의사소통 과정에서 다들 끄덕였다면, 시스템은 꽤나 합리적이라고 생각한다.
마치며
많은 사람들이 회의를 싫어한다. 또 회의야?라는 말을 꽤나 자주 듣는다. 나도 자주 하던 말이다. 주간, 월간, 분기, 반기, 연간이라는 이름과 수시로 잡히는 이벤트들에 전,중,후 보고자료를 만들고 회의에 들어가면 항상 높은사람 말 몇마디에 내가 염두해둔 의사결정들이 아스라진다. 진이 빠지고 그나마 남았던 동기부여가 줄어든다.
나는 회의가 그런 활동이 되선 안된다고 생각한다. 어느정도 시스템을 가지고 있고, 합리적으로 진행되어야 한다. 해결해야 할 문제라는 전술했듯이 이렇게 맥빠지는 회의가 계속되면 조직 구성원의 사기와 팀웍은 물론 조직이 불합리하다고 여기는 사람들도 생긴다.
그저 회의를 잘 활용하는 회사와 그렇지 못한 조직이 있을 뿐이지 회의는 놀라운 문제해결 능력을 가지고 있음을 나는 의심하지 않는다.
