기회 점수

우선순위를 매기는 틀은 대부분 후보 목록이 이미 있다고 전제합니다. 점수를 매길 대상이 표에 올라와 있어야 곱하고 나눌 수 있기 때문입니다. 그런데 그 후보가 쌓이는 제품 백로그를 열어 보면, 올라온 항목이 어디에서 왔는지는 대개 팀 안입니다. 영업이 계약을 놓치며 들은 말, 개발자가 쓰면서 불편했던 것, 대표가 경쟁 제품에서 본 기능입니다.

그래서 아무리 정교하게 점수를 매겨도 목록에 없는 것은 끝까지 만들어지지 않습니다. 분기 계획 회의에서 후보 스무 개를 놓고 사흘을 다툰 팀이, 정작 사용자가 매일 겪는 불편은 한 번도 입에 올리지 않는 일이 생깁니다. 아무도 그 불편을 몰라서가 아니라 그것을 목록에 올릴 자리가 없었기 때문입니다.

기회 점수는 목록을 만드는 쪽으로 질문을 한 칸 앞당깁니다. 무엇을 먼저 할지 묻기 전에 사용자에게 두 가지를 묻습니다. 이 일이 당신에게 얼마나 중요한가, 그리고 지금 그 일은 얼마나 잘 되고 있는가. 중요하다는 답과 잘 안 된다는 답이 겹치는 자리가 아직 아무도 손대지 않은 자리입니다.

사용자 설문으로 두 값을 모으고 정해진 식에 넣어 점수를 냅니다. 순서는 다섯 단계입니다.

1. 물어볼 항목을 결과 문장으로 적습니다. 기능 이름이 아니라 사용자가 이루려는 결과여야 합니다. "댓글 알림 기능" 이 아니라 "공유한 문서에 누가 무엇을 남겼는지 제때 안다" 입니다. 기능으로 물으면 사용자가 그 기능을 상상하는 방식에 따라 답이 갈립니다.
2. 물을 사람을 고릅니다. 실제로 그 일을 하는 사용자여야 하고, 수십 명 단위가 필요합니다. 다섯 명에게 물으면 평균이 사람 하나에 좌우됩니다.
3. 항목마다 두 번 묻습니다. 이 결과가 얼마나 중요한지를 1에서 10으로, 지금 그 결과가 얼마나 잘 되고 있는지를 다시 1에서 10으로 답하게 합니다.
4. 식에 넣습니다. 점수는 중요도에 중요도와 만족도의 차이를 더한 값이고, 차이가 음수면 0으로 놓습니다. 중요도 8.7에 만족도 4.2 인 항목은 8.7에 4.5를 더해 13.2 가 됩니다. 중요도 5.1에 만족도 6.8 인 항목은 차이가 음수라 5.1 에 그칩니다.
5. 점수 순으로 늘어놓고 위쪽 대여섯 개만 남깁니다. 이 목록은 무엇을 만들지가 아니라 어디를 풀지를 가리킵니다.

차이가 음수일 때 0으로 놓는 이유는 이미 충분히 잘 되는 일에 더 투자해도 사용자가 달라졌다고 느끼지 않기 때문입니다. 만족도가 중요도를 넘어선 항목은 오히려 과하게 만들어 둔 자리입니다.

마지막 단계에서 나온 목록은 그대로 개발 순서가 되지 않습니다. 각 자리에 대한 해법 후보를 여러 개 만든 다음, RICE처럼 도달 범위와 노력까지 보는 틀에 넣어 다시 줄을 세웁니다. 기회 점수는 어디를 팔지 정하고, 나머지 틀은 어떤 삽을 쓸지 정합니다.

이 방법은 사용자가 이미 충분히 있고 후보 목록 쪽이 빈약할 때 값을 합니다. 출시한 지 1년이 넘어 쓰는 사람은 늘었는데 다음 분기에 무엇을 할지 팀 안에서만 돌고 있다면 맞는 자리입니다. 반대로 아직 사용자가 없는 제품에서는 쓸 수 없습니다. 만족도를 물을 대상이 없기 때문입니다. 그때는 사용자 리서치로 몇 사람을 깊게 만나는 쪽이 맞습니다.

사용자에게 만족도를 묻는다는 점에서 카노 모델과 겹쳐 보이지만, 카노가 기능 하나를 두고 반응을 묻는다면 이쪽은 결과가 잘 되고 있는지를 묻습니다.

표본이 작으면 순위가 뒤집힙니다. 서른 명 아래에서는 항목 사이 점수 차이가 0.5 정도로 벌어져도 그게 진짜 차이인지 우연인지 가릴 수 없습니다. 답한 사람이 실제 사용자 구성과 다르게 치우쳐도 마찬가지입니다. 열성 사용자 서른 명에게만 물으면 이제 막 들어온 사람이 겪는 불편은 점수에 잡히지 않습니다.

한계는 셋입니다.

1. 비용을 보지 않습니다. 점수가 가장 높은 자리가 반년짜리 작업일 수 있고, 식 어디에도 그 사실이 들어갈 칸이 없습니다.
2. 풀 수 있는 문제인지 말해 주지 않습니다. 만족도가 낮은 이유가 제품 밖에 있을 때도 점수는 똑같이 높게 나옵니다.
3. 결과 문장이 곧 상한입니다. 사용자가 생각해 본 적 없는 결과는 항목에 없고, 항목에 없으면 점수도 없습니다. 목록을 넓히려고 쓰는 방법이지만 그 목록 역시 누군가 미리 적어 둔 문장 안에서만 넓어집니다.

"이건 기회 점수가 13인데 저건 5예요. 이번 분기는 위쪽부터 봅시다."

사용자가 중요하다고 답했는데 지금 잘 안 되고 있는 자리를 먼저 다루자는 제안입니다.

"만족도가 높게 나온 항목은 이번에 빼죠. 더 만들어도 티가 안 나요."

이미 충분한 곳에 자원을 더 넣지 말자는 뜻입니다.

"설문 응답이 28명이라 순위는 참고만 하겠습니다."

표본이 작아 점수 차이를 믿을 수 없다는 유보입니다.

페이지덱에서는 지현이 분기 계획을 짜기 3주 전에 이 설문을 돌립니다. 결과 문장 열두 개를 만들어 활성 사용자 약 400명에게 보내고, 돌아온 답으로 점수를 계산해 위쪽 다섯 자리를 뽑습니다. 그다음 회의에서는 그 다섯 자리를 벽에 붙여 놓고 각 자리마다 해법을 서너 개씩 만듭니다.

이 순서를 지키면 회의 성격이 달라집니다. 각자 만들고 싶은 기능을 들고 와 겨루는 대신, 같은 문제 앞에서 서로 다른 해법을 내놓게 됩니다. 태오가 낸 해법이 지현이 낸 것보다 싸게 먹히면 그 자리에서 정리됩니다.

점수가 높은 항목을 그대로 만들면 된다고 읽는 경우가 많습니다. 숫자가 순서대로 나와 있으니 그게 할 일 목록처럼 보입니다. 하지만 점수는 결과에 붙은 값이지 해법에 붙은 값이 아닙니다. 점수 13인 자리를 푸는 방법은 보통 네댓 가지이고 드는 시간은 하루부터 반년까지 갈립니다. 점수 순서를 개발 순서로 옮기면 결국 가장 비싼 해법을 골라 놓고 왜 계획이 밀렸는지 설명하게 됩니다.

만족도가 낮으면 기능이 부족한 것이라고 읽는 오해도 잦습니다. 만족도는 그 결과가 잘 안 된다는 감각일 뿐이라 원인을 가리지 않습니다. 기능이 아예 없어서일 수도 있지만, 있는데 어디 있는지 못 찾아서이거나 느려서일 때도 같은 점수가 나옵니다. 원인을 확인하지 않고 새 기능을 만들면 메뉴만 하나 늘고 점수는 다음 분기에도 그대로 나옵니다.