협력적 의사결정에서 빠질 수 있는 함정
과정에 집중해야 하는 이유
서버 개발자, 앱 개발자, UI 디자이너, UX 디자이너, PM 5명이 한 자리에 모였다. 제품 개발 막바지에 발생한 이슈를 확인하고, 배포 후 다음 스텝을 논의하기 위함이다. 그러던 중 디자이너 Jack이 의견을 냈다.
여기 이 부분 최신 데이터가 누락될 수도 있으니 이전 데이터로 변경해주면 좋지 않을까요?
이게 좋은 의견인지 아닌지 의견이 분분했다. 이전 데이터로 치환한다면 분명 어떤 사용자 입장에서는 더 좋은 UX를 경험하겠지만, 어떤 사용자는 일치하지 않는 정보를 확인하게 될 수도 있다. 쉽게 결론이 나지 않았다. 각자 자신의 입장에서 이렇게 하면 어떤 장점이 있는지 이야기했다. 그렇게 해당 사안에 대한 논의로 10분, 20분이 흘렀다. 그러자 갑자기 PM인 Juli가 한 명씩 지목해서 묻기 시작했다. "Alice는 어떻게 생각하세요?", "Jay는 어떻게 생각하세요?" 결론은 3:1로 "이전 데이터로 치환하지 말자"는 것이었고 나머지 한 명은 모르겠다고 했다. 이 회의의 문제점은 무엇일까?
반드시 지금 결정을 내려야 한다는 심리적 압박
먼저 현재 상황이 어떤 상황인지가 명확히 판단되어야 한다. "이전 데이터로 치환해주자"는 아이디어는 지금 당장 구현될 필요는 없었다. 일단 기록해두었다가 추이를 지켜보면서 이전 데이터로 치환해줄지를 생각해보면 된다. 그런데 미팅에 참여한 5명의 실무자는 해당 이슈를 지금 당장 결정 내려야 하는 것으로 취급했다. 당장 결정 내릴 필요가 없는 문제는 해당 문제에 대한 인사이트를 얻을 수 있을 때까지 결정을 미뤄도 된다.
아이디어 단계에서 바로 결정 단계로
누락된 데이터를 이전 데이터로 치환하여 사용성(UX)을 개선한다는 아이디어는 어쩌면 임팩트가 큰 기능일지도 모른다. 이렇게 사소하고 디테일한 사용자에 대한 배려가 제품의 성장으로 이어질 수 있다. 좋은 아이디어다. 그런데 여러 사항에 대한 고려 없이 아이디어가 나오자마자 반박, 논의, 결정으로 빛의 속도로 나아갔다. 아이디어 단계에서 중요한 것은 해당 아이디어가 실제 사용자들이 겪고 있는 문제인지, 다른 대안은 없는지, 기술적으로 실현 가능한지, 이 기능을 추가함으로 발생하는 다른 반대급부는 없는지 등등에 대한 조사이다. 이렇게 아이디어 단계에서 바로 결정 단계로 넘어가지 않으려면 회의의 목적과 어젠다가 명확히 정의되어야 한다. 아이디어 회의인지 의사결정 회의인지 회의 주최자가 상기시켜줄 수 있다. 또한 회의 참여자는 내가 회의에서 하고 있는 발언이 아이디어 차원의 발언인지 지금 당장 적용해야 한다고 주장하는 발언인지도 알고 있어야 한다. 일종의 메타인지이다.
심사숙고해야 할 상황에서 직관을 사용
인지심리학에 따르면 사람의 사고는 시스템 A와 시스템 B로 이루어져 있다. 시스템 A는 직관적이고 빠르다. 그래서 위급상황에서 빠르게 의사결정을 해야 할 때나 일상적인 업무를 처리할 때 좋다. 위급한 환자가 발생했을 때 119에 전화하거나, 마트에서 물건을 샀을 때 카드를 꺼내서 결제하는 것과 같은 일이다. 시스템 B는 심사숙고 시스템이다. 시스템 A가 처리할 수 없는 일은 시스템 B로 처리해야 한다. 회사의 장기적인 전략을 짜거나, 이세돌 같은 바둑 기사가 알파고를 상대로 묘수를 두기 위해 장고하는 것은 시스템 B를 활용해야 한다. 위에서 특정 기능을 넣을지 말지에 대한 판단은 분명 일정 부분 시스템 B의 개입이 필요한 판단이다. 그런데 위 사례에서는 해당 결정을 내리기까지 20분이 채 안 걸렸다.
즉각적이고 강력한 반대의견
Jack이 의견을 내자 바로 반대의견이 나왔다. 그래서 토론을 벌였다. 좋은 아이디어였지만 심사숙고와 근거는 아직 충분하지 않았다. 즉각적인 반대의견을 냈을 때 아이디어를 낸 사람과 반박하는 사람 모두 에너지를 과도하게 소모하게 된다. 그 모습을 지켜본 다른 구성원은 앞으로 아이디어를 내는 것에 주저하게 될지 모른다. 서로 자료가 충분하지 않은 상황에서 20분간 토론을 하는 바람에 소중한 회의 시간과 에너지가 낭비되었다. 해당 회의에서 우리가 확정해야 하는 내용은 자그마치 20가지가 넘었다. 그런데 하나의 안건에 대해 무려 20분을 소비한 것이다.
"모르겠다" 또는 "의견 없음"이 최고의 의견일 수 있는 이유
회의를 할 때 특정 사안에 대해 모든 사람이 통찰력과 의견을 갖고 있는 것이 아니다. 오히려 의견을 강요하면 딱딱한 분위기가 되어 버린다. 당장 가지고 있는 경험이나 정보가 부족하기 때문에 모르거나 의견이 없을 수 있다. 그럴 때는 리서치, PoC, 직접 해보기, 시뮬레이션 등을 이용해 새로운 정보를 확보하면 된다. 그래서 "지금은 알 수 없으니 이러이러한 방법으로 확인해보자"가 최고의 의견이 될 수 있다.
다수결이 적절하지 않은 상황에서 다수결을 적용
위 사례에서는 다수결이 적절하지 않은 상황에서 다수결의 방법을 따라 의견을 물었다. "다수결이 항상 완벽한 결과를 나타내는 것은 아니다"라는 원칙은 사실 누구나 알고 있다. 초등학생 때부터 배우는 내용이다. 그런데 사실 우리 본성에는 다수결이 내재되어 있다. 시스템 A에 입력되어 있는 것이다. 그래서 다수결이 적합하지 않은 상황에서도 종종 다수결로 문제를 해결하는 실수를 한다. 이제 여러분의 시스템 A에 한 가지를 더 추가하려고 노력해보자. "여러 사람의 의견을 취합하여 결정을 내리기 전에, 이 사안이 다수의 의견에 따르는 것이 적절한 상황인지를 점검한다." 실제로 위 사례에 나오는 의사결정은 다수결에 적합하지 않다. 고객의 사용성 개선을 위해서는 현재 고객이 어떤 문제를 갖고 있는지, 고객이 해당 문제를 얼마나 중요하게 생각하는지, 위에서 제시한 아이디어로 고객의 문제를 실제로 해결할 수 있는지를 알아야 하는데, 회의실에 있는 우리는 고객도 아니었고, 5명은 모든 고객의 특성을 대표하기에는 표본의 크기가 너무 작다.
위 사례에서 제품은 어떻게 되었을까? 결국 처음 결정과는 반대로 여러 데이터와 회사의 기존 제품에서 활용하고 있는 전략을 검토한 결과 "데이터를 치환하는 게 좋다"라는 최종적인 결정이 내려졌고 기능의 출시는 성공적이었다고 한다. 적절한 의사결정에 실패해도 괜찮다. 되돌릴 기회는 언제든지 있다.
