기획 프레임워크
MoSCow와 Rise
기획의 가장 큰 역할은 '분류'와 '우선순위' 라 생각합니다.
IT 서비스를 위해서 '기획'은 너무나 당연한 절차입니다.
어떤 서비스를 할 것인지 방향에 맞게 핵심 기능들과 부가기능들을 잘 조합하고, 각 기능들을 정의하고 유저 사용성이 편하도록 와이어프레임을 설계하는 것까지 기획의 역할은 범주가 아주 넓습니다. 초기 스타트업일수록 시간과 자금이 충분하지 않은 기업일수록 선택과 집중이 필요하기에 기획의 역할은 중요하고 부담이 큰 포지션입니다.
서비스 첫 설계 시 어떤 기준으로 기능을 담을 것이며, 어디까지를 MVP 서비스로 정의할 것인가? 또는 서비스의 첫 출시 이후에도 영업팀이나 고객관리 CS, 사내 의견등 다양한 경로로 서비스의 개선 요구사항들이 다양하게 접수될 것인데, 어떤 것부터 빠르게 반영해야 할지 결정하는 것이 쉽지 않습니다.
특히나 기획자의 객관적인 기준 없는 독단적인 우선순위 판단은 다른 부서에서 충분한 공감을 하지 못하여 팀워크가 잘 이루어지지 않는 상황까지 흘러가기도 합니다.
기획의 우선순위를 객관적으로 정하여 모두가 같은 기준으로 우선순위를 정할 수 있는 기획자가 알면 좋을 프레임워크 두 가지(MoSCoW와 Rise)를 소개하고자 합니다. 이 두 가지 프레임워크의 장단점이 있기 때문에 저는 병행하여 활용하고 있습니다.
MosCoW 프레임 워크
MoSCoW 프레임워크는 크게 4가지로 분류됩니다.
Must Have : 서비스 운영에 핵심적인 기능으로, 이 기능 없이는 온전한 서비스가 불가능하다는 기준
Should Have : 서비스 운영에 필요한 기능이긴 하지만, 해당 기능 없이도 서비스 사용은 가능하다는 기준
Could Have : 꼭 필요하지 않은 기능으로 있으면 '있으면 좋고 없으면 어쩔 수 없는' 기능
Won't Have : 기능을 반영했을 때 가치가 크게 더해지지 않는 기능으로, 적용 시 효과도 미미하고 서비스 운영에 전혀 영향을 주지 않는 기능
MoSCoW 프레임 워크는 아주 단순하게 우선순위를 나눌 수 있습니다. 수십, 수백 개의 Backlog 가 쌓여있을 때 Must have로 분류된 것을 빠르게 파악하고 기획 업데이트 및 시스템 반영 시킬 수 있고, Won't Have 로분류 되는 것은 개선 부적합 처리로 이슈 클로징 하여 Backlog로 방치하지 않고 내용 공유가 빠르게 이루어진다는 것이 큰 장점입니다.
하지만 4가지 분류 단순하게 구분 가능한 만큼 Should Have 나 Could Have 수준의 요구사항 들은 기준이 다소 애매하여 사람마다 다르게 측정한다는 것입니다. 혹은 이용자의 특성에 따라 Should와 Could로 분류가 달라지기도 합니다.
MoSCoW 프레임워크만 사용하여 4개의 분류만 잘해두어도 Must have backlog를 추려내는데 큰 도움이 되었습니다.
Rise 프레임 워크
MoSCoW 프레임 워크는 해당 기능이 얼마나 '필요성'이 있는지에 집중한 프레임워크라면
Rise 프레임 워크는 해당 기능개발이 얼마나 '효율적'인가 관점으로 분류한 것으로 느끼고 있습니다.
Rise 프레임워크는 크게 4가지로 분류됩니다.
Reach : 해당 기능이 얼마나 많은 이용자에게 영향을 주는지 기준입니다. (이용자 수)
마케팅, 영업팀, CS에서 각자 도출 할 수 있습니다. 각 요구사항들이 시스템으로 반영시 얼마나 많은 이용자에게 효과가 있는지 알 수 있습니다. Rise 프레임워크를 '효율' 기준의 분류로 보았을 때 Reach 수가 적다면 개발대비 효율이 떨어집니다. Reach 수에 따라 우선순위가 달라질 수 있습니다.
Impact : 해당 기능이 우리의 목표에 어느 정도의 영향을 주는가? (효과)
Rise 프레임워크에서 Impact의 해석은 다소 차이가 있지만, 제가 가장 공감했던 부분은 우리가 선택한 목표에 얼마나 Impact 가 있는가?입니다. (원분 링크)
우리의 목표와 OKR을 달성하기 위해 어느 정도 영향을 주는 기능인지를 기준으로 5단계로 나누어 점수를 산정할 수 있습니다.
Confidence : 기획자의 성공 가능성 판단
Reach와 Impact, Effort 값을 고려했을 때 기능 반영시 어느 정도 성공적 일지 개인 판단을 수치로 표현합니다. 사내 모두가 객관적인 기준으로 우선순위를 산정하고 공감한다는 목적으로 프레임워크를 도입한 취지에는 어긋나는 변수로 생각합니다. 하지만 서비스 기획을 총책임지는 PO/PM 입장에서는 스스로 냉정하게 판단해볼 수 있는 항목이라고 생각됩니다. (저는 confidence 값을 제외하고 활용하고 있습니다)
Effort : 기능을 개발하는 과정이 얼마나 오래 걸리고 인력이 투입되는지 기준입니다.
해당 기능을 개발하는데 들어간 인력과 시간에 따라 우선순위가 달라질 수 있습니다. 앞서 Reach 수와 Impact 값이 낮은데 Effort 수준이 높다면 효율이 떨어지는 작업이며, Reach와 Impact 값이 높은데 Effort 수준이 낮다면 빨리 반영할수록 좋은 기능으로 판단할 수 있습니다.
QA 매니저로서 기획 프레임워크
저는 QA 매니저입니다. 서비스 전체적인 품질을 신경 써야 하는 입장이라, 마케팅과 영업에서 접수되는 잠재고객들의 기능 요구사항과 서비스를 이용 중인 고객의 CS 목소리를 중요시하고 집중하고 있습니다.
당연히 더 좋은 품질의 서비스로 개선되기 위하여 다양한 요구사항들 중 빠르게 대응하거나, 느리더라도 꼭 반영되어야 할 기능들을 분류하고 관리하고 있습니다.
MoSCoW와 Rise모델은 QA 매니저로서 기획자와 영업, 마케팅, 개발팀과 협업을 위한 소통툴로 큰 효과를 보고 있어 내용을 정리해 보았습니다.
#기획프레임워크, #MoSCoW모델, #Rise모델, #QA매니저직무
