우선순위 정하기
[코드스테이츠 PMB 9기] 다양한 이해관계자 요구사항과 우선순위 정하기
지난 글 중 [멀티프로필은 어떻게 보이나요?]의 후속 편입니다. 오늘 글은 지난 글과 깊은 연관성은 없습니다. 다만, 갑작스런 전개로 어리둥절 할 수 있어 간략히 정리해 보았습니다.
[멀티프로필은 어떻게 보이나요?]은 카카오톡 멀티프로필을 릴리즈하지 얼마 안된 상황을 가정했습니다. 릴리즈 후 얼마 지나지 않아 사용자들이 문제를 제기하기 시작한 상황이었죠. 카카오 PM이라면 멀티프로필을 어떻게 개선할지 고민하여 개선점을 이야기해 보았습니다. 이때 개선점은 고객의 요구사항만이 반영된 것이었습니다.
프로덕트에서 고객은 중요합니다. 사용 주체이면서 동시에 개선 내용에 관한 정보를 제공해주기 때문이죠. 그렇다면 프로덕트에는 고객의 목소리만이 반영될까요?
한 프로덕트에는 다양한 이해관계자들의 목소리가 반영됩니다. 프로덕트를 개발하는 팀과 서비스를 운영하는 경영진, 고객을 직접 응대하는 CS 팀, 홍보하는 마케팅 팀 등 다양한 사람들이 서비스를 만들고 운영하는 데 관여하고 있습니다. 이들의 목소리도 프로덕트에 반영됩니다. 지금부터 프로덕트에 대한 그들의 요구사항을 추측해보고, 어떤 방법으로 요구사항을 선택해야 하는지 알아보겠습니다.
다양한 이해관계자
"이런 게 있는지 몰랐어요. 저처럼 처음 듣는 사람들이 꽤 있을 거 같아요"
"유용하지만 상대방과 기분 상할 수도 있을 거 같아 사용하고 있지 않습니다"
① 잠재고객, 이탈고객
멀티프로필을 아직 사용해보지 않은 고객도 있고, 한 두 번 사용해보고 사용가치를 못 느껴 이탈한 고객도 있을 겁니다. 이들에게는 각각 어떤 요구사항이 있을까요? '이런 기능이 있는 줄 몰랐다' '이런 건 별로다' 등의 반응이 있을 듯 합니다. 이들의 요구사항은 초반부터 집중하는 사안은 아닐 수 있습니다. 하지만 신규 고객을 확보하여 시장 점유율을 확대해 나갈 때 중요합니다. 현재 니즈가 있지만 아직 필요를 느끼지 못하는 사람과, 니즈와 필요를 느끼지만 사용 경험이 만족스럽지 않은 사람의 요구사항은 향후 전략을 세우는 데 도움이 될 수 있습니다.
② C-Level 경영 임원진
경영자의 입장은 사업 가치에 더 집중되어 있습니다. 매출 향상, 비용 절감, 장기적 사업성에 대한 평가 등이 그런 것들이죠. 이들은 '어떤 비전으로 프로덕트를 만들고 있나요?' '직접적인 수익이 발생할 수 있나요? 카카오 메신저에 어떤 기여를 할 수 있나요?'와 비슷한 요구사항을 갖습니다. 많은 내용은 프로덕트 개발 프로세스 전반에 걸쳐 개발팀과 공유되었을 수 있어요. 하지만 스프린트 리뷰와 같은 특정 단계에서 보다 직접적으로 이들의 요구사항이 전달됩니다.
③ 개발팀
프로덕트를 만든 프로덕트 오너(PO), 스크럼 마스터, 개발자, 디자이너, QA 담당자들도 이해관계자 입니다. 프로덕트를 만든 주체이지만 프로덕트에 대한 각자의 요구사항은 다를 수 있습니다. 프로덕트 사용자로서의 요구사항일 수도 있고 개발 업무 주체로서의 요구사항일 수도 있습니다. 중요한 건 업무 주체로서의 요구사항입니다. 팀원들은 업무를 직접 수행하는 데 있어 효율성을 높이기 위한 요구사항을 갖습니다. 업무 관련 요구사항이 중요한 이유는 프로덕트 개발의 전 단계에 직접적인 영향을 주기 때문입니다. 서비스가 커질 경우 업무가 효율적으로 이루어지지 않는다면 중요성은 더욱 커집니다. 비효율적인 업무 프로세스는 시간과 자원 비용을 증가시켜 서비스 전반에 부정적인 영향을 미치게 됩니다.
④ 고객 응대 팀(CS)
고객 응대를 한다는 것은 직접 VOC(Voice Of Customer)를 접한다는 의미입니다. 고객으로부터 직접 수집한 요구사항을 다른 팀에게 공유함으로써 현재 고객의 사용경험을 들여다 볼 수 있는 중요한 창구가 됩니다. CS팀의 요구사항은 사용경험 개선과 직접적으로 관련 있습니다. 고객 응대는 프로덕트 사용 경험의 한 부분으로서 궁금한 점, 어려운 점을 직접 물어보고 해소하는 통로이기 때문입니다. 효율적인 고객 지원을 위한 CS팀의 요구사항은 프로덕트의 사용경험을 높이는데 기여합니다.
다양한 요구사항에 대처하는 방법, 우선순위
다양한 이해관계자들의 요구사항이 무엇인지 알았다면 다음 문제는 '무엇을, 어떤 기준으로 선택하느냐' 입니다.
선택 기준을 세우기에 앞서 '언제' '누가' 요구하는지를 판단해야 합니다. 이를 위해 프로덕트의 개발 단계에 따라 이해관계자들의 역할과 영향력의 범위를 명확히 정의해야 합니다. 이해관계자를 구체적으로 정의하는 것은 요구사항에 우선순위를 매길 수 있는 중요한 기준이 됩니다. 예를 들어, 프로덕트 초기 단계에 사용성 개선이 목표라면, 수익을 강조하는 경영진보다 고객의 요구사항에 더 무게가 실리게 되겠죠.
이해관계자를 정의하고 요구사항을 우선순위를 분류했다면, 다음은 전달하는 방법을 정해야 합니다. 전달 방법은 정보의 정확한 전달을 위해 중요합니다. 각자 원하는 방법으로 소통하면 업무 효율성이 낮아지기 때문입니다. 상호 약속한 방법(채널)과 시간 등을 구체적으로 정해야 합니다.
다양한 요구사항을 마주하면 '우선순위를 정하는 일'이 중요하다는 걸 알 수 있습니다. 프로덕트를 둘러싼 다양한 요구사항은 언제나 흘러 넘칩니다. 이를 정리하기 위해 우선순위를 정하는 방법론이 필요합니다. 이제 오늘날 대표적인 네 가지 '우선순위 지정 기법(Prioritization Techniques)'을 살펴보겠습니다.
우선순위 방법론
1. 모스코우 (MoSCow)
• Must have : 해당 기능이 프로덕트에 없다면 상상할 수 없을 만큼 중요합니다
• Should have : 중요하지만, 지금 당장 없다고 해서 치명적이진 않은 기능 입니다
• Could have : 'Nice to have'라고 부르는 영향력은 작지만 있으면 좋은 기능 입니다 (얼만큼 기여할 수 있는지 가치에 대해 다양한 판단 관점이 있을 경우 Should have와의 구분은 더욱 어렵습니다)
• Will not have : 효과가 미미하고 중요도가 낮은 기능 입니다
장점
1. 복잡하거나 깊은 이해가 요구되지 않아 빠르고, 쉽게 적용할 수 있습니다
2. 필수 기능을 제외하면 엄격한 시간 제한이 없어 상황에 따라 유연하게 대처할 수 있습니다
단점
1. 구현하는 데 있어 작업의 일관성을 잃어버릴 위험이 있습니다. 작업의 순서에 대한 내용이 없어 전체적 관점에서 일관성을 유지하기 어려울 수 있습니다.
2. 일차원적 관점에서 개별 요구사항에 대한 중요도를 평가하기 때문에 각 요구사항이 기여할 수 있는 가치를 종합적으로 평가하기 어렵습니다. 중요한 기능들을 중심으로만 작업한다면, 완성을 위해 필요하지만 우선순위가 낮은 요구사항을 놓칠 수 있습니다.
MoSCoW는 간단하고 빠르게 적용할 수 있지만 단점이 많아 사용시 주의해야 합니다. 아래에 다룰 다른 우선순위 방법론과 보완하여 사용하는 경우가 많습니다.
2. 워킹 스켈레톤 (Walking Skeleton)
워킹 스켈레톤은 기본 아키텍처의 PoC(기술 검증 버전 | Proof of Concept) 입니다. 최소 실행 가능 제품(MVP)의 기능을 구현하는데 우선순위 기준으로 사용되며, 프로덕트에 무엇이 절대적으로 중요한지 정의하는데 활용됩니다. 이 방법은 요구사항이 아닌 '사용자 스토리'에 초점을 맞추어 우선순위를 정합니다. 사용자 스토리에 순위를 매겨 필수 기능의 구현에 집중합니다. 이는 비즈니스 가치를 충분히 보여줘야 합니다.
장점
1. 빠르게 우선순위를 정할 수 있습니다.
2. 실제 작동하는 MVP를 목적으로 하기 때문에 핵심 기능에만 집중할 수 있습니다.
3. 사용자로부터 우선순위 결정에 대한 피드백을 신속히 받을 수 있습니다. 제품 시장 적합성(PMF)와 전체적 관점에서의 프로덕트 평가가 가능합니다.
단점
1. 다른 주요 기능이 포함되지 않아 프로덕트 작동에 어려움이 있을 수 있습니다.
2. 프로덕트를 릴리즈 할 때 주요 기능의 우선순위를 조정하려고 할 수 있습니다. 이는 핵심 기능에 대한 집중이 흐려져 신속한 고객 피드백이 어려울 수 있습니다.
워킹 스켈레톤은 최소 실행 가능한 제품(MVP)를 만들 때 유용합니다. 핵심 기능에 대해 집중하기 적합한 방법론이죠. 하지만 복잡한 제품을 개발할 경우에는 적합하지 않습니다.
3. 라이스 (RICE)
라이스 모델은 수학적 방법을 이용해 등급 점수를 매기는 방법론입니다. 여기서 사용되는 프로덕트 평가 기준은 네 가지가 있습니다. 도달범위(Reach), 영향(Impact), 자신감(Confidence), 노력(Effort). 각각의 내용은 다음과 같습니다.
• Reach : 얼마나 많은 수의 사용자에게 영향이 미치는지 측정합니다. '기간당 사람 수' 혹은 '기간당 이벤트 수'로 표현됩니다. 따라서 분기별 고객, 월별 거래 등이 될 수 있습니다.
• Impact : 그 임팩트의 크기는 어떠할지 측정합니다. 즉, 특정 요구사항이 개발되면 고객의 전환율에 얼마나 영향을 미치는지 판단합니다. 영향에 대한 측정은 객관적인 척도(아래 표 참고)를 활용합니다.
• Confidence : 신뢰도 값 입니다. 해당 요구사항이 고객에게 얼마만큼의 혜택을 주는지 판단하는 수치 입니다. 백분율로 표기되며 구체적인 증거가 있다면 Confidence 값은 높아집니다.
• Effort : 제품, 디자인 및 엔지니어링 팀이 소요한 시간을 보여줍니다. 작업에 투입된 사람이나 소요된 시간으로 계산됩니다.
표) RICE 점수 계산법그리고 최종적으로 RICE 점수는 (R x I x C) / E 로 계산을 합니다. 이 결과가 큰 순서대로 더 중요한 일이라고 보는 거죠. 최근에는 'Business Importance(B)'를 추가로 고려하는 BRICE 방법도 고려됩니다. 이때 B는 비즈니스에 미치는 영향을 고려한다는 의미입니다. 관련하여 자세한 내용은 아래 영문 아티클을 참고 하실 수 있습니다.
장점
1. 종합적인 관점으로 볼 수 있습니다. 여러 요소를 포함시킬 수록 다양한 관점을 확인하는데 도움이 됩니다.
2. 실제 의미있는 숫자와 KPI를 기반으로 하기에 의미있는 평가지표 입니다.
3. 라이스 모델은 사용자 경험을 중요시 하기에 사용자 만족도에 충분히 기여할 수 있습니다.
단점
1. 특정 요구사항의 다양한 항목들을 각각 계산하려면 시간이 오래 걸립니다.
2. 모든 데이터를 고려하기 어렵습니다. 이때 출시를 연기하는 결정으로도 이어집니다.
3. 책임소재가 명확하지 않습니다.
라이스 모델은 우선순위 방법론으로 활용성이 높습니다. 특히, 사용자에 대한 부분이 명확한 경우에 적합 합니다. 같은 이유로 MVP 프로덕트에 사용하기엔 적합하지 않습니다.
4. 카노 모델 (KANO)
카노 모델은 고객 기반으로 우선순위를 정하는 방법론 입니다. 이 방법론은 프로덕트의 기능에 대해 사용자들의 만족도와 행동이 다르다는 점에서 시작 합니다. 만족도와 관련된 사용자 의견이 중요하기 때문에 설문조사와 인터뷰 진행이 필요합니다. 사용자 의견은 다음 네 가지 기준으로 나뉘게 됩니다. Must-be, Performance, Attractive, Indifferent
• Must-be : 고객이 가치를 느끼는 데 반드시 필요한 기능입니다. MoSCoW의 Must have와 같은 의미입니다.
• Performance : 프로덕트 작동에 반드시 필요한 것은 아니지만 고객이 기대하거나 원하는 기능 입니다. 고객의 요구와 기대치와 밀접하게 연관되기 때문에 신중하게 고려해야 합니다.
• Attractive : 프로덕트에 대해 만족감을 더해주는 기능 입니다. 해당 기능이 없어도 고객은 크게 불만족스러워 하지 않습니다.
• Indifferent : 고객 만족에 미치는 영향이 거의 없습니다.
장점
1. 프로덕트의 잠재적 장점과 단점을 강조합니다. 사용자 피드백을 통해 제품의 장점과 단점을 객관적으로 볼 수 있습니다. 이는 개발 초기, 제품 시장 적합성 판단에도 도움이 됩니다.
2. 사용자 관점에서 제품을 평가하고, 사용자의 요구에 맞게 조정하는 데 도움이 됩니다
단점
1. 포괄적인 피드백 중심의 평가이기 때문에 특정 기능 개발에 필요한 시간, 비용을 계획하는 것은 PM/PO의 몫 입니다.
2. 시용자 조사 내용을 처리하고 결과와 인사이트를 추정하는 데 노력과 시간이 많이 필요합니다. 이는 프로덕트 출시를 늦게 하고, 개발 집중을 방해할 수 있습니다.
3. 사용자 의견에만 집중할 경우 효율성이 떨어질 수 있습니다. 기술적 배경을 갖고 논의하여 고객의 기대치에만 머물지 않도록 주의해야 합니다.
카노 모델은 초기 개발 단계에서 유용합니다. 초기 사용자 경험을 디자인 할 때 고객의 목소리는 큰 도움이 됩니다. 하지만 일반적으로 사용자는 프로덕트의 기술적 복잡성이나 다양한 어려움을 잘 모르기에, 이를 우선순위 지정시 고려하여 반영해야 합니다.
우선순위 정하는 다양한 방법
프로덕트를 둘러싼 다양한 요구사항은 위의 방법론들을 선택 사용하여 우선순위를 정할 수 있습니다. 어느 한 가지 방법론이 가장 좋다는 건 없습니다. 상황에 따라, 프로덕트에 따라 우선순위를 정할 뿐이죠. PM/PO의 중요한 역할인 우선순위 결정에 도움이 되도록 네 가지 방법론들을 정리해 보았습니다. 각 방법론을 사용할 때 참고할 수 있는 비교 테이블은 아래와 같습니다.
고객을 포함한 다양한 이해관계자들은 한 가지 프로덕트에 대해 각자만의 요구사항을 갖고 있습니다. 이러한 요구사항 중 지금 개발이 필요한 것의 순서를 정하고, 업무 계획을 세우는 일이 PM/PO의 일입니다. 우선순위를 세우는 다양한 방법론을 통해 어떠한 기준이 각 방법론에서 활용하는지, 나아가 왜 이러한 기준들이 각 방법론에서 함께 사용되는지 고민해 볼 수 있는 시간이었습니다.
