올바른 질문의 어려움
제품 성공의 기준
누가 그랬다.
제대로 된 답을 얻고 싶으면, 올바른 질문을 해야 한다고.
올바른 질문에 대한, 아래 영상을 보자. 리처드 파인만 교수와의 대담이다. (7분 34초 소요)
나는 이 영상을 좋아한다. 부족한 질문에도 미소를 지으며 다정하고 예의바르게 설명해주는 그의 모습에서 편안함을 느끼기 때문이다. 게다가, 알기 쉽게 이야기하는 뛰어난 지적 능력도 감탄스럽다. 저렇게 되고 싶고, 배우고 싶다.
나는 위 영상을 볼 때마다 질문의 중요성을 다시 한번 깨닫는다.
아니, 제대로 된 질문이 얼마나 어려운 일인지 깨닫고, 덜컥 겁부터 난다.
질문은 정말정말 어려운 것이다.
제품을 운영하면서, 측정해야 할 지표들은 여러가지가 있지만, 그 중 팀의 생산성을 확인하기 위해 측정하는 기준에 대해 항상 고민이 많다.
왜냐면, 지표란 궁금한 것을 살펴보기 위한 척도이고, 궁금한 것을 알기 위해선 제대로 질문해야 하기 때문이다. 파인만 교수의 말처럼 내가 뭘 모르는지 정확히 파악하고, 무엇을 알고 싶은지 깊은 고민을 해야, 그제서야, 올바른 질문이 나온다. 잘못된 측정 기준을 가지고 허구헌날 팀을 들여다 보아봤자, 엉망인 결론에 다다를 것은 명백하다. 질문을 잘못해서 엉뚱한 지표를 받아놓고, '우리 팀은 성과가 안나오네', '진척률이 미비하네' , '생산성이 떨어지네', '일 안하고 노는거 아냐' 같은 X소리를 하는 리더들이 많다는 걸 우리는 잘 알고 있다.
예를 들어보자. '일정 기간에 처리한 티켓 수'를 핵심 지표로 들여다보면, 결국 티켓을 많이 처리한 팀원이 일을 잘 하는 사람이 된다. 속도만 빠른 팀원이 인정받게 된다. 팀내 공유? 팀원 도움? 그런거 없다. 주야장천 개인 티켓만 쳐내는 기계가 높은 보너스를 받고 승리한다. 그렇게 스프린트 몇 개를 타면, 팀원들 모두 완료 티켓 수를 높이려고 혈안이 된다. 이상한 분위기가 정착한다. 잘못된 문화가 만들어지는 것이다.
하지만 어디 제품이 그렇게만 운영되는가? 며칠에 걸쳐 고민해야 진정한 해결 방법에 도달할 수도 있고, 의외의 곳에서(문의 응대 등) 복병을 만나 팀에 남모르게 헌신하고 있는 팀원이 있을 수도 있다. 속도와 티켓수를 측정 기준 삼아 생산성을 들여다보면 안되는 이유다.
속도와 양을 가지고 성공을 측정하다보면, 약삭빠른 팀원이 나타나게 된다. 빨리 완료할 수 있는 작은 범위의 문제만 처리하려고 하는 것이다. 그래야 처리 티켓수를 늘릴 수 있고 좋은 평가를 받을 수 있으니 말이다. 그렇게 팀 분위기가 고착되면, 어려운 문제, 깊은 고민이 필요한 문제에 덤벼드는 사람은 사라지게 된다. 긴급하고 위태로운 작업은 아무도 손대려 하지 않는다. 쉽고 간단한 티켓을 선점한 후, 그냥 빨리/많이 처리하는 문화가 정착되고, 그런 문화에서 역량 성장은 기대할 수 없다.
나는 NBA를 종종 본다. 많은 선수 중, 르브론 제임스라는 사람이 있다. 적지 않은 나이임에도 불구하고 여전히 현역으로 뛰어난 성과를 내고 있는 그를 인정한다. 아마 엄청난 개인적인 노력을 하고 있을 것이다. 하지만 나는 그의 팬은 아니다. 그의 플레이나, 행동이 오로지 '스탯'만을 위한 것처럼 보이기 때문이다. 여기서 내가 쓴 '스탯'은 statistics(통계) 를 뜻한다. 본인의 기록 과 우승 경력 등을 쌓기 위한 플레이와 감독에 대한 월권, 팀 옮기기 등은 그닥 좋게 보이지 않았다. 마이클 조던이 보여준 농구에 대한 낭만과 끔찍할 정도의 열정과는 정반대의 길을 걷는 것처럼 느껴진다.
위에 이야기 한, 티켓 처리 수만을 노리고 행동하는 팀원은 결국 르브론과 같이 본인 스탯만 챙기는 셈이다. 그럴듯한 평판과 완료율을 가지고 높은 보너스와 고과를 챙겨가기 위한 얕은 태도. 골치아프고 어려운 문제에 뛰어들기 싫어 슬슬 피하는 그런 사람들이 늘어나면, 결국 선량하고 헌신적인 팀원들이 피해를 입게 된다.
그렇다면 우리는 무슨 질문을 해야 하는가
(어떤 측정 지표를 살펴봐야 하는가)
그러기 위해서는,
우리 팀, 우리 제품의 ‘성공의 기준’이 무엇인지부터 이야기를 나눠야 한다. 공감대를 가져야 한다. 우리는 무엇을 하는 팀이며, 어떤 일을 해냈을 때 목적을 이루어 낸 것인지 팀원들간에 공감대가 반드시 형성되어야 한다. 우리는 무엇을 이뤄내면 '성공'했다고 말할 수 있는 제품인가? 내 도메인은 무엇을 위해 구동하고 있는가? 그래야 촛점을 하나로 모아 팀웤을 형성하고, 모두 하나의 공통된 목표를 향해 서로 도우며 차근차근 걸어갈 수 있다.
지표말고 꿈 이야기를 하자.
티켓 처리 갯수는 우리의 꿈이 아니잖는가.
완료율이나 처리갯수 같은 얕은 지표는 꿈을 이루는 길이 적절한지 상황을 파악하는 용도에 그쳐야 한다. 꿈으로 가는 길에 장애물이 없는지 판단하는 용도 정도로 사용하면 적당하다. 스프린트가 끝나고 간단히 공유하는 정도로 충분하다. 티켓 수가 적다고 질책할 필요는 없다. 그 몇개의 티켓으로 정말 깊은 고민을 하고 있을지 어찌 아는가? 그가 방안의 코끼리를 치워줄 지 누가 아는가? 우리 팀은 멈추지 않는 컨베이어 벨트 앞에서 똑같은 제품을 계속 찍어내는 제조공장이 아니다. 필요하다면 컨베이어 벨트를 세우고, 그 옆 의자에 앉아 한 시간이고 두 시간이고 고민해야, 더 좋은 제품이 나온다. 그래야 제품의 퀄리티가 향상된다. (별 것 아닌 작업으로 질질 끌고 있는, 누가 봐도 태업하고 있는 C급 엔지니어에 대해서는 논하고 싶지 않다. 브런치 스토리지는 그렇게 낭비되어선 안된다.)
엉뚱한 측정 지표를 테이블에 올려놓고 아무리 질책해 봤자, ‘꿈’ 근처에도 갈 수 없다.
진짜 꿈을 꾸는 사람들은 지표와 상관없이 고민하고 헌신하고 있을 것이다.
제품을 운영하는 사람이라면, 당신이 추적하고 있는 지표에 대해 끊임없이 고민해야 한다. 팀이 당신의 지표로 인해 엉뚱한 방향으로 목표의식을 갖게 되는 것은 아닌지 걱정해야 한다. 측정하는 것들의 진정한 가치에 대한 평가를 '객관적으로' 주변으로부터 받아야 한다. 아마 제품의 특성과 서비스의 목적에 따라 각기 다른 지표를 들여다봐야 할 것이다.
또한, 본인의 제품에 대해 끊임없이 공부하여 이해도를 스스로 높여야 한다. 스스로 아는게 없으면 저 위 동영상처럼 추상적이고 모호한 질문만 던지게 된다. 그래서 우리는 상대방의 질문으로 그의 수준을 어렴풋하게 파악할 수 있는 것이다. 아는만큼 세련된 질문을 한다. 세련된 사람은 모르는 것을 솔직하게 인정한다.
PM이든 개발자든 반드시 자신의 도메인을 가져야 하는 이유다. 이런저런 제품을 전전하며 얕은 일만 처리하다보면, 깊은 고민을 할 기회는 사라진다. 아는게 없으니, 제대로 물어볼 수 없다. '전문가'라고 불릴 수 있도록 본인 제품에 대해서 구석구석 알아야 한다. '자기가 뭘 모르는지 아는 것'도 능력이다.
올바른 것을 질문해야 한다. 그래야 원하는 답을 얻는다.
제대로 된 측정 지표를 지켜보고 있었는지, 한 번 더 생각해봐야겠다.
우리팀의 르브론은 누구인가?
우리제품의 성공 기준은 무엇인가?
내가 모르는 것은 무엇인가.
