피드백 루프

카노 모델: 고객이 느끼는 방식으로 기능 요청 분류하기

5분 분량

카노 모델은 몇 명이 요청했는지가 아니라, 고객이 기능이 있을 때와 없을 때 어떻게 반응하는지를 기준으로 기능을 분류하는 방법이다. 1984년 노리아키 카노가 제안했으며 모든 기능을 당연 품질, 성능 품질, 매력 품질(감동 요소), 무관심 품질, 역 품질의 다섯 그룹 중 하나에 넣는다. 기능 요청이 쌓여 있는 팀에게 유용한 점은, 수십 표를 받은 요청이 만족도에는 아무것도 더하지 못하는 반면, 아무도 투표하지 않은 요청이 제품을 이야기하는 방식을 바꿀 수 있는 이유를 설명해준다는 것이다.

범주기능이 있을 때 고객 반응기능이 없을 때 고객 반응대표적인 요청
당연 품질아무 반응 없음, 있어야 하는 것으로 여긴다강한 불만비밀번호 재설정, 데이터 내보내기
성능 품질많을수록 만족이 커진다적을수록 만족이 떨어진다속도, 저장 공간, 사용 한도
매력 품질기쁨아무 반응 없음, 아무도 기대하지 않았다세심하게 만든 자동화
무관심 품질아무 반응 없음아무 반응 없음만지는 사람이 거의 없는 설정
역 품질짜증안도강제로 보여주는 투어나 추가 단계

카노 모델의 범주에는 무엇이 있는가

당연 품질 기능은 고객이 있다고 가정하는 기능이다. 아무도 칭찬하지 않지만 고장 나면 모두가 알아차린다. 성능 품질 기능은 더 빠른 리포트나 더 높은 한도처럼 많을수록 직선으로 좋아지는 기능이다. 매력 품질 기능은 예상 밖이라서 없어도 잃는 것이 없고, 있으면 진짜 열광을 얻는다. 무관심 품질 기능은 어느 쪽으로도 아무것도 움직이지 않고, 역 품질 기능은 오히려 없애면 일부 고객이 더 행복해진다.

범주는 특정 시점에 특정 고객 집단에 대해 기능이 갖는 속성이다. 그래서 같은 기능이 세그먼트에 따라 다른 그룹에 들어갈 수 있다.

카노 설문은 어떻게 진행하는가

기능마다 두 가지 질문을 한다. 기능적 질문은 제품에 그 기능이 있다면 어떻게 느낄지 묻는다. 역기능적 질문은 그 기능이 없다면 어떻게 느낄지 묻는다. 두 질문 모두 같은 다섯 가지 답을 쓴다. 마음에 든다, 당연하다, 아무래도 좋다, 참을 수 있다, 싫다.

표준 평가표로 두 답을 합쳐 응답자 한 명이 기능 하나를 어떻게 보는지 분류한다.

기능적 \ 역기능적마음에 든다당연하다아무래도 좋다참을 수 있다싫다
마음에 든다QAAAO
당연하다RIIIM
아무래도 좋다RIIIM
참을 수 있다RIIIM
싫다RRRRQ

M은 당연 품질, O는 성능(일차원) 품질, A는 매력 품질, I는 무관심 품질, R은 역 품질이고 Q는 스스로 모순되는 의심스러운 답이다. 기능별로 응답자 전체의 글자를 세어 가장 많은 것을 그 기능의 범주로 삼는다. 두 범주가 비슷하면 둘 다 보고한다. 40 대 38로 갈렸다면 한쪽 답이 이겼다는 뜻이 아니라 그 세그먼트의 의견이 갈린다는 뜻이기 때문이다.

어떤 기능 요청을 카노 설문에 넣어야 하는가

실제로 만드는 것을 진지하게 고려하지만 감으로는 순위를 매길 수 없는 요청만 넣는다. 기능 다섯 개에서 열다섯 개가 설문 길이로 무리가 없으며, 기능마다 고객이 목업 없이도 떠올릴 수 있는 한 문장 설명이 필요하다. 후보는 중복을 묶은 뒤 추적 중인 백로그에서 가져온다. 같은 것을 요청한 열 건은 설문에 기능 하나로 올라가야 하기 때문이다. 묶는 단계는 기능 요청 추적에서 다룬다.

버그 수정과 이미 계약으로 약속한 항목은 뺀다. 설문으로는 크래시를 고쳐야 하는지 알 수 없다.

누구에게 설문해야 하는가

이미 제품을 쓰는 사람을 중요한 세그먼트별로 나누어 설문한다. 전체 목록에 보낸 설문은 여러 다른 집단의 평균을 내기 쉬운데, 평균은 발견을 가려버린다. 무료와 유료 사용자, 신규 계정과 오래된 계정, 소규모 팀과 대규모 팀은 같은 기능을 서로 다른 범주에 넣는 경우가 많다. 세그먼트별 결과를 따로 두고, 다음 릴리스가 어느 세그먼트를 위한 것인지 정한다.

요청을 쓴 사람들을 첫 대상으로 삼고 활성 사용자 무작위 표본을 더해, 설문이 목소리 큰 소수로만 채워지지 않게 한다. 요청을 쓰고 보내는 방법은 고객 피드백을 요청하는 방법에 있다.

카노 결과를 어떻게 우선순위로 바꾸는가

이 순서로 만든다. 당연 품질의 빈틈이 먼저고, 다음은 고객이 비교하는 대안에 뒤처진 성능 품질 기능이며, 릴리스마다 매력 품질 기능 한두 개를 넣고, 무관심 품질과 역 품질 기능은 맨 뒤로 미루거나 아예 하지 않는다. 이 순서는 각 범주가 만족도에 하는 일에서 나온다. 당연 품질의 빈틈을 메우면 떠날 이유가 하나 사라지고, 성능 품질 작업은 만족도를 꾸준히 올리며, 매력 품질 기능은 차별화가 생기는 곳이다.

카노 모델은 기능이 어떤 종류의 가치를 지니는지 알려주지만 비용은 알려주지 않는다. 계획에 올리기 전에 범주를 작업량 추정과 짝지어야 한다. RICE 점수 같은 점수 방식이 비용 쪽을 맡으며 둘은 함께 쓰면 잘 맞는다. 카노가 후보 목록을 고르고 RICE가 그 순서를 정한다. 더 넓은 결정은 기능 요청 우선순위를 정하는 방법에 있다.

기능은 시간이 지나면 범주를 옮겨 가는가

그렇다. 이것이 이 모델에서 가장 기억할 만한 점이다. 매력 품질 기능은 경쟁사가 따라 하고 고객이 익숙해지면서 성능 품질로, 이어서 당연 품질로 흘러간다. 2단계 인증은 한때 반가운 놀라움이었지만 지금은 업무용 소프트웨어에서 기대되는 기능이다. 설문 결과는 한 시점의 스냅숏이므로, 승부를 거는 범주는 1년 뒤나 경쟁사가 비슷한 것을 내놓을 때 다시 조사한다.

감동 요소를 내놓았다면 고객에게 알린다. 매력 품질 범주의 기능은 알게 된 사람에게만 기쁨을 주므로 공지도 기능의 일부다. 이 고리를 닫는 방법은 새 기능 발표를 쓰는 방법에서 다룬다.

카노 모델의 한계는 무엇인가

이 모델은 행동이 아니라 말로 밝힌 감정을 측정하므로, 사람들이 원한다고 말하는 것을 과대평가할 수 있다. 세그먼트마다 패턴이 보이려면 응답자가 충분해야 하고, 실무적으로는 수십 명이 하한인 경우가 많다. 또한 기능을 하나씩 평가할 뿐 기능끼리 어떻게 상호작용하는지는 말해주지 않는다. 결과는 로드맵 논의를 위한 강한 근거로 다루고, 사용 데이터와 매출 옆에 놓고 본다. 순위를 매긴 목록을 계획으로 바꾸는 방법은 제품 로드맵 만드는 법을 참고한다.

FAQ

카노 모델을 쉽게 말하면 무엇인가? 기능이 있을 때와 없을 때 고객이 어떻게 느끼는지에 따라 기능을 그룹으로 나누는 방법이다. 그룹은 당연, 성능, 매력, 무관심, 역 품질이며 각 그룹은 서로 다른 개발 우선순위를 가리킨다.

카노 설문에는 몇 명이 필요한가? 정해진 숫자는 없지만, 따로 읽고 싶은 세그먼트마다 뚜렷한 다수 범주가 보일 만큼의 응답이 필요하다. 세그먼트당 수십 명이 흔한 실무적 최소선이며, 응답이 더 적은데 결과가 갈렸다면 아직 결론이 나지 않은 것으로 읽는다.

카노 모델이 RICE보다 나은가? 둘은 다른 질문에 답한다. 카노는 기능이 고객에게 주는 가치의 종류를 분류하고, RICE는 도달 범위, 영향, 확신, 노력으로 작업의 순위를 매긴다. 많은 팀이 카노로 후보 목록을 만들고 점수 방식으로 순서를 정한다.

카노 분석은 얼마나 자주 반복해야 하는가? 안정된 제품은 해마다, 경쟁사가 비슷한 기능을 내놓으면 더 일찍 반복한다. 감동 요소는 시간이 지나면 기대 사항이 되므로, 오래된 결과는 더 이상 차별화되지 않는 기능을 가리킬 수 있다.


이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.

changeloop 관련 페이지: 개발자 문서, changelog 도구 비교

changeloop
루프를 닫는 changelog를 만드는 팀입니다. 사용자가 무언가를 요청하면 팀이 전달하고, 요청한 사람은 알게 됩니다.