PM수첩: 꼭 알아야 할 4가지 우선 순위 정하기 기법
카테고리
[성장의 피땀눈물]
태그
PM/PO
일하는 방법
프레임워크
요약
상황에 맞게 논리적으로 우선순위를 정하는 기술은 누구에게나 필요합니다. 이 글에서 언급되는 PM은 소프트웨어 서비스 기억의 프로덕트 매니저, 프로덕트 오너 등을 지칭하고 있으나 응용하여 해석하면 타 직군에도 대부분 적용될 수 있을것입니다.
빠르고 합리적인 "우선순위 정하기"는 모든 현대인의 생존 기술
현업의 PM에게 업무 중 가장 어려운 부분이 무엇이냐고 물으면 압도적으로 차지하는 대답은 "실제 시장의 피드백이 부족한 상태에서 로드맵에 따른 백로그의 우선순위를 지정" 하는 것이라고 합니다.
백로그 작업의 우선순위를 정하는 것은 PM의 가장 중요한 업무 책임 중의 하나입니다. 가장 단순하면서 명료한 원칙은 "첫번째로 중요한 일을 가장 먼저 하는것" 입니다.
하지만 이 일을 어렵게 만드는 잠재적 변수들이 있고, 아이디어들의 우선순위를 위한 미팅과 토론은 결정에 대한 영향력과 성공가능성의 극대화라는 목적때문에 늘 치열하게 이루어집니다. 그 덕에 많은 IT기업이 우선순위를 정하기 위한 여러가지 "우선순위 지정 기법"을 사용합니다.
모스코우(MoSCoW)
MoSCoW는 애자일 프로덕트 관리 방법에서 중요한 것과 그렇지 않은 것을 구별하고 이해하기 위해 일반적으로 사용되는 방법입니다.
🄼 Must Have : 이 기능을 빼고 제품 딜리버리/서비스 론칭을 생각할 수 없는 것
🅂 Should have : 높은 우선순위를 지니는 기능이 분명하지만, 그것이 없어도 프로덕트에 재앙이 닥칠 운명까지는 아닐 때
🄲 Could have : 많이 이야기하는 'Nice to have'에 해당하는 것. 충분한 자원이 있다면 할 수 있었을 것이지만 성공을 위해 꼭 필요한 것은 아닐 때
🅆 Will not have : 많은 PM들이 "다음 버전에 포함하도록 신중히 검토하겠습니다."라고 말하는 것. 주로 개발자원 부족의 이유로 이번 버전에는 포함되지 않을 것이라는 의미로 사용
워킹 스켈레톤 (Walking Skeleton)
워킹 스켈레톤은 최소화된 프로덕트의 엔드 투 엔드를 구현한 것입니다. 최소 실행 가능 제품(MVP) 기능의 우선순위를 정하는데 사용되며, 그중 어떤 것이 제품이 작동하는데 절대적으로 중요한지 정의합니다.
이 방법은 특정 카테고리에 속하는 요구사항을 뜻하는 것이 아니라 사용자 스토리에 초점을 맞추어 우선순위를 정합니다.
① 먼저 필요한 사용자 스토리에 순위를 매깁니다.
② 필수 기능의 구현에 중점을 두기 때문에 주요 기능이 완전하게 동작하는 제품의 형태를 갖고 있어야합니다.
③ 비즈니스 가치를 충분히 보여주는 형태를 갖고 있어야합니다. 여러가지 기술 제한이 있는 상태에서도 핵심 시스템 요소를 표시하기 위해 스토리맵을 잘 정리해야합니다. 워킹 스켈레톤은 딜리버리와 배포까지의 모든 과정을 포함하기 때문에 제품 기능 테스트도 과정에 포함됩니다.
라이스 (RICE: Reach, Impact, Confidence, Effort)
라이스 방법은 우선 순위를 설정하기 위해 등급점수 모델이라는 방법을 사용합니다.
🅁 Reach : 특정 기간에 이 기능을 사용할 수 있는 사용자 수. DAU, MAU 등의 실제 프로덕트 지표로 평가
🄸 Impact : 이 기능을 사용함으러써 어떤 영할을 받을지에 대한 것. 상태적인 값으로 매우 큰 임팩트의 경우 3점, 높은 경우 2점, 낮을 수록 1점, 0.5점, 0.25점을 사용해 평가
🄲 Confidence : 신뢰도 값. 이 기능이 사용자에게 얼마만큼의 혜택을 주는지에 대한 추정값. 높은 경우 100%, 중간 80%, 낮음 50% 등 객관식 척도를 사용하는 것이 좋음
🄴 Effort : 제품, 디자인 및 엔지니어링 팀이 소요한 시간. 소요 일 수나 시간 등으로 계산
➥ RICE = (Reach*Impact*Confidence)/Effort
R, I, C의 곱을 E(시간)으로 나누어 계산. RICE의 값이 클수록 우선순위가 높다는 뜻이 됨
카노 모델 (Kano)
카노 기법은 고객 기반의 우선 순위 지정 방법입니다. 프로덕트의 기능에 대해 사용자의 만족도와 행동이 다르다는 사실에서 시작합니다.
Must-be : 고객이 이 기능이 포함된 경우에만 제품의 의미를 두는 반드시 구현해야하는 기능
Performance : 프로덕트가 동작하기 위해 반드시 필요한 것은 아니지만, 고객은 이 기능을 매우 갖고 싶어 하는 경우
Attractive : 만족감을 더해주는 것들. 이 기능이 없다고 해서 특별히 불만족스러워하지는 않지만 가지고 있으면 좋은 기능
Indifferent : 고객 만족에 미치는 영향이 거의 없는 것
프로덕트 백로그에서 작업의 우선 순위를 정하는것은 PM의 중요한 책임 중 하나입니다. 직감에 의존할 수도 있지만 이러한 접근방식은 대개 해당 프로젝트와 제품/서비스를 위험에 빠뜨립니다.
원글에서는 위의 각 방법의 장단점과 이를 비교해놓은 표로 글을 마무리하고 있습니다. 어떤 상황에 어떤 우선순위 지정기법을 사용하는 것이 효율적인지 파악하실 수 있으니 관심이 가신다면 아래의 원글 링크에서 자세한 내용을 확인해보세요.
빠르고 합리적인 "우선순위 정하기"는 모든 현대인의 생존 기술
현업의 PM에게 업무 중 가장 어려운 부분이 무엇이냐고 물으면 압도적으로 차지하는 대답은 "실제 시장의 피드백이 부족한 상태에서 로드맵에 따른 백로그의 우선순위를 지정" 하는 것이라고 합니다.
백로그 작업의 우선순위를 정하는 것은 PM의 가장 중요한 업무 책임 중의 하나입니다. 가장 단순하면서 명료한 원칙은 "첫번째로 중요한 일을 가장 먼저 하는것" 입니다.
하지만 이 일을 어렵게 만드는 잠재적 변수들이 있고, 아이디어들의 우선순위를 위한 미팅과 토론은 결정에 대한 영향력과 성공가능성의 극대화라는 목적때문에 늘 치열하게 이루어집니다. 그 덕에 많은 IT기업이 우선순위를 정하기 위한 여러가지 "우선순위 지정 기법"을 사용합니다.
모스코우(MoSCoW)
MoSCoW는 애자일 프로덕트 관리 방법에서 중요한 것과 그렇지 않은 것을 구별하고 이해하기 위해 일반적으로 사용되는 방법입니다.
🄼 Must Have : 이 기능을 빼고 제품 딜리버리/서비스 론칭을 생각할 수 없는 것
🅂 Should have : 높은 우선순위를 지니는 기능이 분명하지만, 그것이 없어도 프로덕트에 재앙이 닥칠 운명까지는 아닐 때
🄲 Could have : 많이 이야기하는 'Nice to have'에 해당하는 것. 충분한 자원이 있다면 할 수 있었을 것이지만 성공을 위해 꼭 필요한 것은 아닐 때
🅆 Will not have : 많은 PM들이 "다음 버전에 포함하도록 신중히 검토하겠습니다."라고 말하는 것. 주로 개발자원 부족의 이유로 이번 버전에는 포함되지 않을 것이라는 의미로 사용
워킹 스켈레톤 (Walking Skeleton)
워킹 스켈레톤은 최소화된 프로덕트의 엔드 투 엔드를 구현한 것입니다. 최소 실행 가능 제품(MVP) 기능의 우선순위를 정하는데 사용되며, 그중 어떤 것이 제품이 작동하는데 절대적으로 중요한지 정의합니다.
이 방법은 특정 카테고리에 속하는 요구사항을 뜻하는 것이 아니라 사용자 스토리에 초점을 맞추어 우선순위를 정합니다.
① 먼저 필요한 사용자 스토리에 순위를 매깁니다.
② 필수 기능의 구현에 중점을 두기 때문에 주요 기능이 완전하게 동작하는 제품의 형태를 갖고 있어야합니다.
③ 비즈니스 가치를 충분히 보여주는 형태를 갖고 있어야합니다. 여러가지 기술 제한이 있는 상태에서도 핵심 시스템 요소를 표시하기 위해 스토리맵을 잘 정리해야합니다. 워킹 스켈레톤은 딜리버리와 배포까지의 모든 과정을 포함하기 때문에 제품 기능 테스트도 과정에 포함됩니다.
라이스 (RICE: Reach, Impact, Confidence, Effort)
라이스 방법은 우선 순위를 설정하기 위해 등급점수 모델이라는 방법을 사용합니다.
🅁 Reach : 특정 기간에 이 기능을 사용할 수 있는 사용자 수. DAU, MAU 등의 실제 프로덕트 지표로 평가
🄸 Impact : 이 기능을 사용함으러써 어떤 영할을 받을지에 대한 것. 상태적인 값으로 매우 큰 임팩트의 경우 3점, 높은 경우 2점, 낮을 수록 1점, 0.5점, 0.25점을 사용해 평가
🄲 Confidence : 신뢰도 값. 이 기능이 사용자에게 얼마만큼의 혜택을 주는지에 대한 추정값. 높은 경우 100%, 중간 80%, 낮음 50% 등 객관식 척도를 사용하는 것이 좋음
🄴 Effort : 제품, 디자인 및 엔지니어링 팀이 소요한 시간. 소요 일 수나 시간 등으로 계산
➥ RICE = (Reach*Impact*Confidence)/Effort
R, I, C의 곱을 E(시간)으로 나누어 계산. RICE의 값이 클수록 우선순위가 높다는 뜻이 됨
카노 모델 (Kano)
카노 기법은 고객 기반의 우선 순위 지정 방법입니다. 프로덕트의 기능에 대해 사용자의 만족도와 행동이 다르다는 사실에서 시작합니다.
Must-be : 고객이 이 기능이 포함된 경우에만 제품의 의미를 두는 반드시 구현해야하는 기능
Performance : 프로덕트가 동작하기 위해 반드시 필요한 것은 아니지만, 고객은 이 기능을 매우 갖고 싶어 하는 경우
Attractive : 만족감을 더해주는 것들. 이 기능이 없다고 해서 특별히 불만족스러워하지는 않지만 가지고 있으면 좋은 기능
Indifferent : 고객 만족에 미치는 영향이 거의 없는 것
프로덕트 백로그에서 작업의 우선 순위를 정하는것은 PM의 중요한 책임 중 하나입니다. 직감에 의존할 수도 있지만 이러한 접근방식은 대개 해당 프로젝트와 제품/서비스를 위험에 빠뜨립니다.
원글에서는 위의 각 방법의 장단점과 이를 비교해놓은 표로 글을 마무리하고 있습니다. 어떤 상황에 어떤 우선순위 지정기법을 사용하는 것이 효율적인지 파악하실 수 있으니 관심이 가신다면 아래의 원글 링크에서 자세한 내용을 확인해보세요.🧑🏻⚕️ 요약자
관심 분야
타겟 오디언스
공유 날짜
2022/04/14
5 more properties