기본 콘텐츠로 건너뛰기

카노 모델과 피쳐 크리프(Feature creep)

피쳐 크리프라는 말이 있다.

자세한 것은 위키피디아에게 물어보라.

Feature creep is the proliferation of features in a product such as computer software. Extra features go beyond the basic function of the product and so can ...


구글신에게 물어봐도 무슨 예기인지 아주 친절하게 알려주는 수많은 웹페이지를 볼 수 있다. 그만큼 아주 유명한 단어 중 하나이다.

결론적으로 말하면 피쳐 크리프란 개발 중 이런 저런 이유로 원래 계획과 상관 없이 덕지 덕지 붙게 되는 기능들을 말한다.

이러한 경우를 우리는 주변에서 아주 쉽게 경험할 수 있다.

그리고 그러한 경우 대부분 공통적으로 하는 말이 사용자를 위해서이다.

하지만 정작 개발과정에서 사용자의 의견이 반영되는 경우는 거의 없다.

테스터 뿐만 아니라 개발에 관련된 모든 사람들은 가장 최우선적으로 고려해야할 사람은 사용자이다.

하지만 개발 과정에서 사용자와 접촉할 수 있는 기회는 매우 제한적이다. 그리고 그러한 정보의 공유 역시 매우 제한적인 것이 현실이다.

마케팅 부서 또는 UX 관련 부서에서 진행 된 사용자 조사를 우리는 얼마나 신뢰할 수 있을까?

사용자로부터 데이터를 얻어내는 방법은 무수히 많은 방법들이 있다.

그중에서 이번에는 카노 모델이라는 것에 대해 소개해 보고자 한다.

카노 모델이라 하면

2009년 3월 31일 ... 카노 모델은 각종 소비자 조사 방법과 연구를 통해 얻어진 '소비자의 목소리'(Voice of Consumer)를 분석하는 틀로 이용된다. ...


을 참고해 보시기 바란다.

사실 카노 모델은 매우 유명한 모델 중 하나로 구글신에게 물어보시면 매우 많은 정보를 얻을 수 있다.

테스팅의 우선순위를 정하기 위한 리스크 분석 이전에 이러한 모델을 통하여 기능의 우선 순위를 먼저 정한다면 개발 뿐만 아니라 테스팅에 있어서 리소스의 낭비를 줄일 수 있다.

카노 모델에서는 기능을 필수 기능, 선형 기능 그리고 감동을 주는 기능으로 구분한다.

대부분의 경우 이러한 기능 구분을 기획자의 직관이나 어설픈 설문 조사 등으로 대체되는 경우가 많지만 중요한 것은 사용자로부터 직접 이러한 데이터를 받아내야 한다는 것이다.

솔직히 사용자가 만족하는 제품의 개발은 돈이 많이 들어간다..

필수 기능은 말 그래도 필수 적으로 필요한 기능들이다. 선형 기능은 다다익선인 기능들을 말한다. 즉 품질이 나아질 수록 고객 만족도도 증가하는 기능들이다. 감동을 주는 기능들은 있어도 그만 없어도 그만이라고 할 수 있다. 하지만 있다면 고객으로부터 돈을 더 받아 낼 수 있는 기능들이다. 감동을 주는 기능들은 고객이 직접 확인 하기 전까지는 그런 기능들이 자신에게 필요한지 확신을 하지 못하기 때문에 미지의 수요라고도 한다.

예를 들면, 최근 스마트폰이 각광을 받으면서 뜨거운 감자로 올라온 것이 일반 기능폰에 와이파이가 있는가? 없는가? 이다.

지금으로서는 와이파이는 감동을 주는 기능이다. 와이파이가 있다면 일부 얼리어답터나 누군가는 감동을 받고 손전화를 질러버릴 것이다. 하지만 얼마 지나지 않아 시장이 변한다면 와이파이는 선형 기능을 될 것이다. 와이파이가 있는 모델은 시장에서 더 많은 점유율을 차지할 것이다. 그렇게 시간이 지나고 나면 언젠가는 와이파이는 필수 기능이 될 것이고 와이파이가 없는 손전화는 도태될 것이다.

그럼 이러한 기능들을 사용자로부터 어떻게 얻어낼 수 있을까?

카노는 두가지 질문을 통해 결정하는 방법을 제안하였다.

첫번째 질문은 해당 기능이 존재하여 기분이 어떻겠는가? 이고 두번째 질문은 없다면 어떤 기분이겠는가?를 묻는 것이다.

그리고 각각의 질문에 1부터 5까지 점수를 매기도록 한다.

1점은 만족한다
2점은 그럴거라고 예상했다.
3점은 잘 모르겠다.
4점은 그렇더라도 쓸 수는 있다.
5점은 그렇게 되면 불만이다

라는 식으로 정의를 내린다.

이렇게 되면 사용자가 내릴 수 있는 답변의 수는 25가지가 된다.

그렇다면 각각의 답변에 따라 기능을 결정할 수 있는 표를 생각해 보자.

   없다면    
   만족예상
중립
감내
불만족
 존재한다면 만족
 재검토
감동감동감동
선형
  예상 역기능무관심무관심
무관심
필수
  중립 역기능무관심무관심무관심필수
  감내 역기능무관심무관심
무관심
필수
  불만족 역기능역기능
역기능
역기능
재검토

예를 들어 당신이 지금 일종의 퍼즐 게임을 만든다고 가정해 보자.

만약 난이도에 대한 기능에 대해 카노 모델을 통해 사용자 조사를 위해 설문지를 돌린다면

난이도라고 커다란 질문을 던진다면 사용자로부터 정확한 답변을 얻기 힘들 수 있다.

사용자에게 전달할 질문은 적당한 숫자여야 하지만(너무 많으면 설문 응답이 저조해진다.) 너무 적은 질문은 기능의 단위를 너무 커지게 해서 나중에 분석에 어려움이 있다.

난이도를 상, 중, 하로 구분해서 질문을 만들어 보자.

컴퓨터와 낮은 난이도 게임을 할 수 있다면?
컴퓨터와 난은 난이도 게임을 할 수 없다면?

이런 식으로 하나의 기능에 세트로 된 질문지를 작성하면 된다.

위와 같은 질문에 만약 사용자가

낮은 난이도 게임을 할 수 있다는 것에 예상을
낮은 난이도 게임을 할 수 없다는 것에 불만족을 선택한다면

낮은 난이도 게임은 필수 기능이 되는 것이다.

그런데 수많은 사용자(대략 30~40명 정도면 적당하다고 볼 수 있다. 하지만 고객이 누구냐에 따라서 설문 응답자는 적절하게 조절하면 된다. 설문 응답자 수보다 중요한 것은 고객을 누구로 정의하냐는 문제이다.)에게 응답을 받게 되면 같은 기능에 대해 2가지 응답이 나올 수도 있다.

예를 들어 높은 난이도 게임에 대해 무관심과 필수 기능 2가지가 나올 수도 있다. 이런 경우는 어떻게 해석할 수 있을까? 각각의 답변군에 대해 다시 한번 분석해 본다면 사용자 부류에 따라 구분되기도 한다.

즉, 데이터를 수집하는 것보다 해석하는 것에 좀 더 주의를 기울여야 하고 그보다는 사전에 설문에 대하 사용자 부류의 선정에 더 신중해야 한다.

무관심은 말 그대로 사용자가 그다지 관심이 없는 기능들이다. 피쳐 크리프를 통해 추가된 기능들은 대부분 무관심으로 분류되는 경향이 크다.

역기능이나 재검토가 사용자 의견으로 나오는 경우는 드물지만 그런 의견이 나온다면 역기능은 없애버려야 할 기능이고 재검토는 기능에 대해 사용자가 잘못 이해하고 있는 경우가 크기 때문에 기능을 다시 정의 내릴 필요가 있다.

카노 모델은 단순하고 간편하지만 사용자로부터 아주 의미 있는 데이터를 추출해 낼 수 있는 좋은 방법 중 하나이다. 하지만 간편하고 쉽다고 하더라도 사용자에 대한 이해와 정의가 부족하다면 이러한 데이터의 신뢰도는 급격히 떨어지게 된다.

사용자 조사는 사실 어떤 방법을 사용하더라도 신뢰도를 100% 얻는다는 것은 불가능하다. 그렇기 때문에 단 0.001%의 신뢰도라도 향상시킬 수 있도록 끊임없는 노력이 필요하다.

테스터 역시 회사의 직원이 아닌 사용자가 되기 위한 노력을 게을리 하지 말아야 한다. 테스터가 사용자의 눈을 잃어버리는 순간 그 테스터는 더 이상 테스터가 아니다.

우리 나라는 많은 경우 테스터의 기술이나 능력을 중요시 하는 경우가 많다. 그런것도 중요하지만 더 중요한 것은 테스터가 사용자의 입장을 얼마나 잘 대변해 주는가이다.

사용자와 접촉하고 사용자를 이해하고 사용자를 위한 노력을 게을리 하지 않는 테스터가 많아졌으면 하는 바램이다.

댓글

  1. trackback from: 카노 모델과 MMORPG
    카노 모델(Kano Model) 에서는 제품의 특성을 아래와 같이 3 가지로 나눈다.

    당연한 품질요소(Must-Be Quality Element) - 없으면 제품의 가치가 없는 것. 자동차의 핸들, 바퀴

    일차원적 품질요소(One-Dimensional Quality Element) - 충족되면 좋고, 없으면 불만이 생기는 품질 요소. 자동차의 연비, 승차감, 에어백

    매력적 품질요소(Attractive Quality Element) - 없어도...

    답글삭제

댓글 쓰기

이 블로그의 인기 게시물

테스트 케이스와 체크리스트의 차이가 뭐여?

테스트 실무에서 가장 혼돈되어 사용되는 용어 중 하나가 테스트 케이스와 체크리스트입니다. 많은 경우 체크리스트를 테스트 케이스로 사용하는 경우가 많습니다. 실제로 인터넷 커뮤니티나 블로그, ISO, IEEE, ISTQB 등등을 검색해보시면 테스트 케이스와 체크리스트에 대한 구분이 다 제각각입니다. 각각에 대한 정의가 다 제각각입니다. 사정이 이러하다보니 많은 사람들이 테스트 케이스와 체크리스트를 잘 구분하지 못하고 혼동해서 사용하는 경우가 많습니다. 물과 기름처럼 테스트 케이스와 체크리스트를 정확하게 구분할 수는 없겠지만.. ISTQB를 기준으로 말씀드리면 설계 기법을 통해 도출된 것은 테스트 케이스 그렇지 않은 것은 체크리스트라고 생각하시면 쉽습니다. 예를 들면 아래는 결정 테이블 테스팅 기법을 통해 도출된 테스트 케이스의 예제입니다. 실제 테스트 케이스는 위보다 복잡하겠지만 어쨌든 얘기하고 싶은 것은 위와 같이 설계 기법을 통해서 도출된 것은 테스트 케이스라고 합니다. 그런데 딱 보시면 아시겠지만 실제 테스트에서는 저 정도로는 테스트 커버리지를 충분히 만족했다고 얘기하기 힘듭니다. 그렇습니다. 어떤 분들은 테스트 케이스가 전가의 보도, 은 총알 쯤으로 생각하시는데.. 테스트 케이스는 일종의 마지노 선이라고 보시면 됩니다. 최소한 제품을 테스트 할때 이정도는 해줘야 한다는 최후의 방어선 정도라고 보시면 됩니다. 전쟁에서 최후의 방어선은 물러설 수 없는 마지막 보루입니다. 하지만 최후의 방어선만 지킨다고 전쟁에서 승리할 수는 없습니다. 프랑스는 마지노 요새만 믿고 있다가 독일에게 깔끔하게 발렸던 과거가 있지요. 전쟁에서 승리하려면 앞으로 나가야하고 치밀한 전략과 전술이 뒷받침 되어야 합니다. 더 높은 커버리지를 도달하고, 충분히 좋은 테스트가 수행되려면 테스트 케이스는 기본이 되어야 하고 거기에 더해서 체크리스트가 따라와 줘야 합니다. 이러한 체크리스트는 팀의 경험과 과거 프로젝트의 데이

비츠 스튜디오 버즈 플러스(투명) 사용 후기

제 내자분은 아직도 유선 이어폰을 쓰고 있습니다. 그게 좋다고 하시더라구요. 작년에 혹시나 해서 앤커 사운드코어 라이프Q35를 구매해서 조공해봤지만 결국은 안쓰시더라구요. 그래서 작년 추운 겨울에 제가 귀마게 용으로 잘 사용해왔는데.. 여름이 되니.. 와.. 이건 너무 덥고 무거워서 못쓰겠더라구요. 아이폰도 사고 애플 워치도 샀으니.. 다음은 에어팟인데.... 노이즈 캔슬링이 된다는 에어팟 프로 2는 ... 네... 너무 비싸더라구요... 이건 내자분께 얘기해봐야 결제가 될리가 없어서... 고민하고 있던차에.. 네.. 저는 봐버리고 말았습니다. 비츠 스튜디오 버즈 플러스의 그 영롱한 투명 버전의 자태를... 급 뽐뿌가 왔지만.. 여전히 20만원의 고가더라구요... 초기 출시 시기에 이벤트로 16만원 정도 했던거 같은데.. 그정도 가격이면 선 결제 후 보고 하면 될거 같은데.. 20만원은 너무 너무 비싸서 침만 삼키던 차에.. 당근에 15만원에 올라온 물건을 덥석 물었습니다. 애플 뮤직 6개월 프로모션 코드도 사용하지 않은 따끈따끈한 제품이라서 그냥 질렀습니다. 이상하게 인터넷이 실제 리뷰 게시물을 찾기 힘들어서.. 고민을 잠깐 했지만.. 그 투명하고 영롱한 자태에 그만... 어쨌든 구매하고 한달 정도 사용해본 후기를 간단하게 남겨봅니다. 1. 노이즈 캔슬링은 기대한 것과는 좀 다르고 앤커 사운드코어 라이프Q35 정도 되는 것 같습니다. 노이즈 캔슬링은 활성화하면 이게 소리를 막아준다기보다는 주변의 작은 소음만 제거해준다고 생각하시면 됩니다. 그러니까 옆에서 소근 거리는 소리나 선풍기 바람 소리 같은 작은 소리들이 사라지고 음악 같은 내가 듣고자 하는 소리가 굉장히 뚜렸해지만 지하철 안내 방송 같은 조금 큰 소리는 그냥 들립니다. 그래서 주변음 허용 모드를 켜보면 너무 시끄러워서 안쓰게 되더라구요. 전 에어팟 프로 2를 사용해 본적이 없어서 비교할 수는 없지만.. 아주 못쓸 정도의 성능은 아니라고 생각됩니다. 2. 저는 귓구멍이 너무 작아서 XS 사이즈의 이어팁

탐색적 테스팅의 역사

이 글은 James Bach 의 ' Exploratory Testing 3.0 '을 번역한 글입니다. 이번 글은 의미를 전달하는데 무리가 없는 선에서 대부분 의역으로 번역되었습니다. 때문에 잘못 번역된 부분은 댓글로 남겨주시면 수정하도록 하겠습니다.(읽어보시면 시제나 문체가 시시각각으로 변합니다. 감안해서 읽어주시면 고맙겠습니다.) 이 글은 James Bach의 허락을 얻은 후 번역한 글로 다른 곳에 퍼가실때는 반드시 원 출처와 본 블로그를 같이 언급해주시기 바랍니다. ----- [저자 주: 다른 글에서 이미 탐색적 테스팅을 이제는 테스팅으로 불러야 한다는 것을 얘기했다. 사실 Michael은 2009년에 테스트에 대해 얘기했었고, James는 테스터에 대해 얘기했던 것을 2010년에 블로그에 작성했다. Aaron Hodder는 2011년에 직접적으로 언급했고 Paul Gerrard 역시 그러했다.우리는 모든 테스팅은 탐색적이라는 것을 깊이 이해하고 가르쳤지만(여기에 James가 작년에 한 학생과 대화를 나눈 예가 있다.), "탐색적 테스팅"이라는 용어를 더이상 사용하지 않을 준비가 되어 있지 않다. 지금도 우리는 탐색적 테스팅이라는 용어를 사용하지 말아야 한다고 주장하지는 않는다. 다만 테스팅이 탐색을 어느 정도 포함한 스크립트 테스팅을 의미하는 것이 아니라 테스팅이 곧 탐색적 테스팅이라는 것이다.] By James Bach and Michael Bolton 태초에 테스팅이 있었다. 아무도 탐색과 스크립트 테스팅을 구별하지 못했다. Jerry Weinberg는 1961년 Computer Programming Fundamentals에서 테스팅의 형식화(formalizing)에 주의를 표명하고 테스팅은 본질적으로 탐색이라고 설명했다. 그는 책에서 "프로그래머의 의도에 대한 많은 정보 없이 프로그램과 프로그래머의 의도가 얼마나 일치하는지 기계적으로 검사하는 것은 어렵다. 만약 검사를 위해 컴퓨터에 간단