현업의 프로덕트, 프로그램 매니저, 오너에게 업무 중 가장 어려운 부분이 무엇이냐고 물으면 늘 압도적으로 많이 차지하는 대답은 ‘실제 시장 피드백이 부족한 상태에서 로드맵에 따른 백로그의 우선순위를 지정’하는 것이라고 합니다. PM생활 15년 차인 저 역시 이 대답의 예외가 되지는 않습니다. 이 대답은 ‘PM/PO에게는 시장과 고객을 위해 옳은 제품/서비스를 만들고 있다는 확신이 늘 필요하다’로 해석될 수 있습니다.
제품 백로그는 제품에 필요한 것으로 수집된 모든 항목의 리스트입니다. 이 리스트에 없으면 제품에 절대 반영될 수 없다고 할 만큼 모든 요청사항을 모아 놓은 것입니다. 좋은 제품과 서비스를 만들기 위해서는 그 모음 안에서 가장 큰 가치를 제공하거나, 가장 합리적으로 보이는 작업을 먼저 완료할 수 있도록 우선순위를 매겨야 합니다.
백로그에서 작업의 우선순위를 정하는 것은 PM/PO의 가장 중요한 업무책임 중의 하나입니다. 일반적으로 프로덕트 팀은 특정 제품을 만들어내는 시간에 비해 훨씬 더 많은 아이디어를 가지고 있으므로 우선순위를 정해야 합니다. 이것을 수행하는 가장 단순하면서 명료한 원칙은 "첫 번째로 중요한 일을 가장 먼저 하는 것(doing the first thing first)"입니다. 업무 프로세스의 관점에서 말하면 "항목 그룹을 평가하고 중요도 또는 긴급도 순서로 순위를 매긴다"는 것을 의미합니다. 이 일을 어렵게 만드는 것은 리소스(비용, 인원, 시간)의 부족과 같은 일반적인 상황이 아니라, 모두 변수로 고려해야 할 각 잠재적 옵션에 대한 불확실성입니다.
아이디어 리스트를 어떻게 우선순위화 할지에 대한 미팅과 토론은 그 결정에 대한 영향력과 성공 가능성의 극대화라는 목적 때문에 늘 치열하게 이루어집니다. 그 치열함 덕에 많은 IT기업이 우선순위를 정하기 위한 여러 가지 우선순위 지정 기법(Prioritization Techniques)을 사용합니다. 글을 읽는 여러분들도 우선순위 지정을 하는 데 있어서 약간 혼란스럽기도 하고 어떻게 활용하는지 잘 이해가 안 되는 같은 고민을 하고 계시다면, 이글에서 소개하는 가장 보편적이고 널리 사용되는 네 가지 방법을 익혀보면 어떨까 합니다. 모든 기법을 상세하게 설명하기보다는 개략적인 특징과 장단점, 사용하는 경우를 살펴보고 다른 기법과 비교하여 설명을 하려고 합니다.
MoSCoW (모스코우)
작고 복잡하지 않은 프로덕트/서비스를 위한 가장 간단한 접근 방법이라고 할 수 있습니다.
특징
MoSCoW는 애자일 프로덕트 관리방법에서 중요한 것과 그렇지 않은 것을 구별하고 이해하기 위해 일반적으로 사용되는 방법입니다. 이 기술은 PM/PO가 작업 중인 내용과 그 이유를 관계자(관리자, 리더십팀, 고객) 에게 전달하는 데 유용합니다. MoSCoW라는 이름은 다음의 네 가지 우선순위(모음 ‘o’를 뺸 M, S. C, W) 범주의 약어입니다.
Must have: 이 기능(features)을 빼고 제품 딜리버리/서비스 론칭을 생각할 수 없는 것들입니다. 여기에는 법적, 보안 문제 또는 비즈니스 이유 등 여러 가지가 있을 수 있습니다. 만약 이 기능이 사용자들에게 약속되어 있거나 제품의 킬러 피쳐(killer feature)로 정의했다면 이것은 제품/서비스의 생사여탈권을 갖고 있다고 생각하십시오. 어떤 것이 '머스트 해브'가 될 만한 자격이 있는지 알아내는 가장 쉬운 방법은 그것을 포함하지 않는 최악의 시나리오와 최선의 경우를 생각해보면 조금 쉽게 이해할 수 있습니다. 만약 여러분이 그것 없이는 프로덕트/서비스의 성공을 상상할 수 없다면, 그것은 ‘머스트 해브’ 필수품입니다.
Should have: 높은 우선순위를 지니는 기능이 분명하지만, 그것이 없어도 프로덕트에 재앙이 닥칠 운명까지는 아닐 때 사용합니다.
Could have: 많이 이야기하는 ‘나이스 투 해브(Nice to have)’에 해당할 수 있습니다. 만약 여러분이 충분한 자원을 가지고 있다면, '할 수 있었을' 것들이지만, 성공을 위해 꼭 필요한 것은 아닐 때 이 순위를 사용합니다. Could have와 Should have 사이가 어느 순간 매우 헷갈리는 경우가 있습니다. 이런 경우, 어디에 속하는지 파악하려면 각 요구 사항(requirements)이 사용자 경험에 어떤 영향을 미칠지 생각해 보십시오. 영향이 적을수록 우선순위를 낮출 수 있습니다.
Won’t have: 많은 PM/PO들이 "다음 버전에 포함시키도록 신중하게 검토하겠습니다"라고 말하는 것을 들어 보셨을 겁니다. 'Won't have'라고 말할 때, '이 요구 사항은 생각할 가치도 없어서 절대 포함되지 않을 것이다'를 의미하는 것이 아니라, '이번 버전에는 포함되지 않을 것이다’를 의미합니다. 주로 개발 자원(시간, 비용, 인원)의 부족과 같은 이유 때문일 수 있는데, 여러분과 여러분의 이해 관계자(리더십, 사용자)들이 이번 릴리즈(출시)에서 이 기능은 포함되지 않을 것이라는 사실에 동의하는데 도움이 되며, 이는 PM/PO로서 기대치를 관리하는 데 큰 도움이 됩니다.
장점
MoSCoW 방법은 깊은 이해나 복잡한 계산이 필요하지 않습니다. 팀 전체가 빠르고 쉽게 적응할 수 있는 우선순위 지정 기법입니다. 리더십팀, 고객과의 간의 상호 이해관계도 쉽게 이끌어 낼 수 있고, 투명하게 진행할 수 있습니다.
MoSCoW 방법은 필수 항목 범주를 제외하고 엄격한 시간제한이 없으므로 기능별로 적절한 시간 배분을 할 수 있습니다. 이렇게 함으로써 팀 리소스를 상황에 맞도록 유연하게 조정할 수 있습니다.
단점
구현의 범주에 일관성이 결여될 수 있습니다. MoSCoW 방법은 우선순위가 쉽게 설정될 수 있지만 작업의 시퀀스가 없으므로 전체적 시스템적인 릴리즈 계획을 세우기 힘듭니다.
MoSCoW가 요구 사항과 기능을 중요도 순서로 정렬하여 보여준다고 해도, 여전히 전체 그림을 보기는 힘듭니다. 비즈니스에 중요한 큰 기능이 중요도에 따라 나누어져 있는 경우 MoSCoW방법에서 낮은 우선순위가 무시되거나 빠지면, 전체 기능이 완성되지 않을 수도 있습니다. 이런 경우 경험 많은 PM/PO가 비즈니스 목표에 따라 우선순위를 그룹화해서 진행해야 합니다.
필요한 것과 멋진 것 사이에 불균형이 생깁니다. 범주 간의 흐릿한 구분이 종종 필수 목록에 들어가는 기능을 결정하기 어렵게 만듭니다. 의존관계(dependency)나 종속관계 (hierarchy)를 잘 구분하여 우선순위 지정에 반영하는 것이 중요합니다.
사용하는 경우
MoSCoW 방법은 간단하지만 항상 효과적인 것은 아닙니다. 예를 들어 많은 릴리즈 시간에 민감한 프로젝트라면, 시간에 대해 포괄적인 우선순위 접근 방식을 사용하여 MoScoW를 보완해 보십시오. 반면 기술적 제약과 의존성이 크지 않은 소형 제품으로 MoScoW를 사용하는 것은 합리적일 수 있습니다.
워킹 스켈레톤(Walking Skeleton)
워킹 스켈레톤은 기본 아키텍처의 PoC(Proof of Concept: 기술 검증 버전)이라 할 수 있습니다. 일반적으로 PoC는 단일 기능에 더 초점을 맞추지만 워킹 스켈레톤은 최소화된 프로덕트의 엔드 투 엔드를 구현한 것입니다. 즉 개념의 윤곽 정도가 아니고 실제로 실행 가능하고 테스트도 함께 가능해야 합니다. 이 때문에 워킹 스켈레톤은 최소 실행 가능 제품(MVP)의 기능의 우선순위를 정하는 데 사용되며, 그중 어떤 것이 제품이 작동하는데 절대적으로 중요한지 정의합니다.
특징
이 방법은 특정 카테고리에 속하는 요구사항을 뜻하는 것이 아니라 사용자 스토리에 초점을 맞추어 우선순위를 정합니다.
먼저 필요한 사용자 스토리에 순위를 매깁니다.
필수 기능의 구현에 중점을 두기 때문에, 주요 기능이 완전하게 동작하는 제품의 형태를 갖고 있어야 합니다.
비즈니스 가치를 충분히 보여주는 형태를 갖고 있어야 합니다. 그 이유 때문에 여러 가지 기술제한이 있는 상태에서도 핵심 시스템 요소를 표시하기 위해 스토리 맵을 잘 정리해야 합니다.
워킹 스켈레톤은 딜리버리와 배포까지의 모든 과정을 포함하기 때문에 제품 기능 테스트도 과정에 포함됩니다.
장점
핵심 기능의 우선순위를 정의하는 데 많은 시간이 걸리지 않습니다.
출시할 제품/서비스의 비즈니스 가치를 추정할 때, 가능한 한 많은 기능을 포괄적으로 가진 제품을 만들고자 하는 유혹이 항상 강하기 때문에, 핵심 필수 기능에만 초점을 맞추기가 어려운 경우가 많습니다. 워킹 스켈레톤은 실제 동작하는 MVP를 목적으로 하기에 이런 상황을 피할 수 있게 합니다
가장 중요한 장점은 사용자로부터 우선순위 결정에 대한 피드백을 신속하게 받을 수 있습니다. 이것에 따라 전체 프로덕트 팀은 제품 시장 적합성과 비즈니스 아이디어를 전체적으로 평가할 수 있습니다.
단점
주요 기능이 동작하는 프레임워크의 형태를 띠고는 있지만, 여전히 중요한 다른 기능을 포함하고 있지 않을 수 있습니다. (전체 테스트에 큰 제한이 있을 수 있습니다.)
워킹 스켈레톤은 다소 빠른 우선순위 설정 테크닉이지만, 주요 기능이 동작하는 프레임워크가 완성되어야 하기에 첫 릴리즈까지는 시간이 걸립니다.
제품을 첫 출시하려고 할 때, 리더십팀에서는 출시를 가속화하기 위해 주요기능의 우선순위를 조정하려고 할 수 있습니다. 이렇게 되면, 최초의 실행 가능한 제품 버전은 시장에 출시할 준비가 되지 않은 프로토타입으로 나올 위험이 있습니다.
사용하는경우
워킹 스켈레톤은 최소 실행 가능한 제품(MVP)을 출시할 때 가시적인 성과를 기대할 수 있는 매우 유용한 테크닉입니다. 그러나 수많은 추가 기능이나 부가적인 비즈니스 가치를 지닌 보다 지속 가능하고 복잡한 제품을 릴리즈 할 때는 사용을 자제하는 것이 좋습니다.
라이스(RICE: Reach, Impact, Confidence and Effort)
라이스 방법은 약간의 수학 계산이 필요한 방법입니다. 우선순위를 설정하기 위해 등급 점수 모델이라는 방법을 사용합니다.
특징
라이스 RICE는 Reach, Impact, Confidence 및 Effort를 나타냅니다. 우선순위를 지정할 때 각 기능을 평가하기 위한 입력 값입니다.
리치 Reach: ‘도달 범위’로 해석하면 될 듯하고, 특정 기간 동안에 이 기능을 사용할 수 있는 사용자 수를 반영합니다. 일별 또는 월별 활성 사용자(DAU-Daily Active Users 또는 MAU-Monthly Active Users) 등의 실제 프로덕트 지표로 평가합니다. 예를 들어 고객 지원 페이지의 개선 사항을 평가하면 월별 이 페이지를 방문하는 사용자 수가 당신의 리치 지표가 됩니다.
임팩트 Impact: 위에서 얼마나 많은 사람들에게 다가갈지(Reach) 생각해봤으니, 그들이 이 기능을 사용함으로써 어떤 영향을 받을지 생각해 볼 때입니다. 임팩트를 측정하는 절대 과학적인 방법은 없으므로 상대적인 값을 사용합니다. "매우 큰 임팩트"의 경우 3점, "높음"의 경우 2점, "중간"의 경우 1점, "낮음"의 경우 0.5점, 마지막으로 "최소"의 경우 0.25점을 사용하여 평가합니다.
컨피던스 Confidence: ‘신뢰도’ 값입니다. 현재의 상황에서 PM으로서 이 기능이 사용자에게 얼마만큼의 혜택을 주는지에 대한 추정 값입니다. "고 신뢰도 100%", "중간도"의 경우 80, "낮은 신뢰도"의 경우 50 등 객관식 척도를 사용하는 것이 좋습니다.
노력 Effort: 제품, 디자인 및 엔지니어링 팀이 소요한 시간을 보여줍니다. 이것은 "인 월(person-month)"나 “시간” 등으로 계산할 수 있습니다.
입력값이 정해졌다면 다음 공식을 적용합니다.
RICE = (Reach*Impact*Confidence)/Effort, 즉 다른 입력치의 곱을 시간(노력 Effort)로 나누는 것입니다. RICE값이 클수록, 우선순위가 높다는 뜻이 됩니다.
장점
큰 그림을 볼 수 있게 해 줍니다. 여러 요소를 포함시킬수록 제품에 대한 비전, 성공적인 론칭, 추가 프로모션 등 다양한 관점을 볼 수 있는 도움이 됩니다.
이 방법은 실제 제품 릴리즈 과정에서 나오는 의미 있는 숫자와 KPI를 기반으로 하기에, 실제로 매우 의미 있는 평가지표가 됩니다.
RICE 방법은 사용자 경험을 매우 중요하게 생각하기에 사용자 만족도에 충분히 기여할 수 있습니다.
단점
모든 메트릭을 동일하게 고려하기 위해 등급을 매기고 각 백 로그 항목별로 계산을 수행하려면 많은 시간이 필요합니다.
모든 데이터를 다 준비하지 못하는 경우가 생길 수 있습니다. 이런 경우, RICE 방법은 출시를 연기하는 결정을 만들 수도 있습니다.
책임에 대해 명확하지 않습니다. 주어진 우선순위 결정 방법에는 영향과 신뢰도 같은 요소들이 포함되기 때문에, 팀은 결정에 대해 어떤 책임을 져야 하는지 명확하지 않은 경우가 많습니다. PM/PO의 책임의 한도인지, 팀 전체인지, 리더십이 담당해야 하는 부분인지 애매한 부분이 많이 생길 수 있습니다.
사용하는 경우
RICE 우선순위는 여러 측면에서 제품을 종합적으로 살펴볼 수 있는 매우 효율적인 방법입니다. 그러나 모든 우선순위 사례에 적용되는 것은 아닙니다. 예를 들어, RICE를 이용한 우선순위 지정방법은 프로덕트/서비스가 출시되고 라이프사이클을 시작할 때는 사용자에 대한 부분이 좀 더 명확하므로 합리적으로 보입니다. 같은 이유로 RICE는 MVP를 만드는 경우에는 어울리지 않는 방법이라 할 수 있습니다.
카노 Kano 모델
카노 기법은 고객기반의 우선순위 지정 방법입니다. 프로덕트/서비스의 기능에 대해 사용자들의 만족도와 행동이 다르다는 사실에서 시작합니다.
특징
다양한 카노 모델 적용방법 중 가장 기본적이고 기본화된 버전은 사용자 백로그 포인트를 다음의 네 가지 기준으로 나누는 것입니다. Must-be, Performance, Attractive, Indifferent. 사용자 만족을 중심으로 하고 사용자 의견을 바탕으로 하는 방식인 만큼 우선순위를 할당하기 전에 설문조사와 사용자 인터뷰를 진행해야 합니다.
Must-be: 고객은 이러한 기능이 포함된 경우에만 제품의 의미를 두는 반드시 구현해야 하는 기능입니다. MoSCoW 우선순위 할당 방법의 Must Have와 같은 의미입니다.
Performance: 이 기능은 이중적인 특성을 가지고 있습니다. 프로덕트/서비스가 동작하기 위해 반드시 필요한 것은 아니지만, 고객은 이 기능을 매우 갖고 싶어 하는 경우입니다. 이 종류의 기능은 고객의 요구와 기대치를 예측하는 것과 매우 밀접하게 관련되어 있습니다. 고객이 원하는 것을 제품에 포함시키면 고객은 만족감을 유지할 수 있습니다. 그러나 이를 제공하지 못할 경우 사용자가 실망할 가능성이 높습니다. 이 때문에 매우 신중하게 고려해야 하는 기능들입니다.
Attractive: 이 기능은 만족감을 더해주는 것들입니다. 기본적으로, 그것들은 특별한 기대감은 없지만, 가지고 있기 좋은 특징입니다. 즉 MoSCoW우선순위 방법의 Could Have (nice-to-have)와 같다고 생각하시면 됩니다. 이 기능이 없다고 해서 고객은 특별히 불만족스러워하지 않는다는 것에 중요성이 있습니다.
Indifferent: 고객 만족에 미치는 영향이 거의 없습니다. 즉 고객은 관심이 별로 없는 기능입니다.
장점
제품의 잠재적인 장점과 단점을 강조합니다. 카노 모델의 가장 중요한 특징은 사용자 피드백인데, 카노 조사 결과는 미래 제품의 장점과 단점을 객관적으로 보는데 도움이 됩니다. 이를 통해 PM/PO는 개발 초기에 제품/시장 적합성을 볼 수 있습니다.
고객에 대한 가치를 기준으로 프로덕트 기능의 순위를 정하게 되므로, Kano 모델은 가치 제안 관점에서 제품을 평가하고 사용자의 요구에 맞게 조정할 수 있도록 도와줍니다.
단점
카노 모델 방법은 고객의 입장에서 우선순위를 정하는 방법이기에 보다 포괄적인 피드백을 제공하지만, 고객은 특정 릴리즈나 특정 기능에 필요한 시간과 비용을 고려하지 않기에 개발을 진행하는 PM/PO 입장에서는 매우 신중하게 출시 계획을 세워야 합니다.
잠재 고객을 대상으로 할 수 있는 카노 설문 조사를 포함하기 때문에 결과를 처리하고 추정하는 데 상당한 노력과 시간이 필요합니다. 이는 출시 시기를 늦추게 되고, 프로덕트 팀의 개발 집중도를 떨어뜨릴 수 있습니다.
고객의 의견과 지식에 의해 제한될 수 있습니다. 카노 모델은 고객 만족도를 높이 평가하지만, 백로그가 단순히 담당자의 희망 요청사항일 수 있으며, 기술적 배경이 없는 고객의 기대치에만 머물게 될 수도 있습니다. 카노 모델 방법을 효율적으로 만들기 위해서는 기술 개념에 대해서는 따로 논의해야 합니다.
사용하는 경우
초기 UX 디자인에 대한 사용자 피드백이 필요한 스타트업이라면 콘셉트 디자인을 카노 설문조사와 함께 진행하는 것이 상당히 효율적일 것입니다. 글로 설명하는 것보다 보여주면서 설명하는 것이 항상 더 낫다는 점을 고려할 때, 프로토타입과 설문지의 조합은 크게 도움이 될 것입니다. 그러나 일반적으로 고객은 제품의 기술적 복잡성이나 다양한 종류의 어려움을 잘 모르기에, 이 변수를 최종 우선순위 지정을 할 때는 반영해야 합니다.
마무리
프로덕트 백로그는 소프트웨어 개발 및 특히 애자일 기반 프레임워크에서 사용되는 가장 중요한 데이터입니다. 다음 스프린트에서 완료해야 할 스토리 포인트뿐만이 아닌 제품을 구성하는 중요한 요소입니다. 프로덕트 백로그에서 작업의 우선순위를 정하는 것은 PM/PO의 중요한 책임 중 하나입니다. 직감에 의존할 수 있지만, 이러한 접근 방식은 대개 해당 프로젝트와 제품/서비스를 위험에 빠뜨립니다. 우선순위를 지정하는 기법에는 오늘 살펴본 4가지 이외에도 아이젠하워 매트릭스, WSJF(Weighted Shortest Job First), Value vs Complexity/Effort 와 같은 여러 가지 다른 기법이 있습니다. 각각의 장단점들이 있는 상황에서 오늘은 가장 일반적인 우선순위 지정 기법 4가지의 방법, 장단점과 사용하는 경우에 대해서 알아보았습니다.
위의 표처럼 서로의 방법을 비교해 보려 합니다. 이 정리된 표를 보면, 어떤 상황에 어떤 우선순위 지정 기법을 사용하는 것이 효율적인지 파악하실 수 있을 것으로 생각합니다. PM의 주머니에는 제품이라는 요리를 만들기 위한 여러 가지 도구가 있습니다. 도구 자체가 맛있는 요리를 보장해 주지 않습니다. 그 도구를 상황과 재료에 맞게 잘 사용하는 PM/PO의 능력이 맛있는 요리를 만들어주지요.
