–
지난주, 우선순위 설정에 도움을 받을 수 있는 ‘KANO’ 모델에 대해 정리했는데요. 이번에는 두 번째 편으로 국내 스타트업에서도 자주 쓰이는 ‘MoSCoW’ 모델을 정리하고자 합니다. 팁스터 뉴스레터를 통해 올해 ‘서비스를 만드는 사람들’ 이야기를 시작했는데 플레이오와 드림포라에서도 모두 해당 모델을 활용 중이라는 이야기를 들었고, 저 역시 계속 변형되고 있지만 유용하게 사용 중인 모델입니다.
–
서비스에 기능을 더할 때는 사업의 방향성을 먼저 고려합니다. 프로덕트가 더 잘 팔리기 위해 어떤 기능이 더해져야 하는지 나열해요. 그다음 사용자들이 원하는 기능들도 리스트에 추가합니다. 서비스에 추가해야 하는 기능들은 많지만 MoSCoW 방법론을 사용해 필수로 진행되어야 하는 업무부터 우선순위를 정합니다. 서비스에 기능을 더할 때는 귀한 개발 리소스가 많이 필요하기 때문이죠.
우선순위에 따라 어떤 방식으로 사용자에게 기능을 제공할지 데이터를 기반으로 기획하고 개발팀에 공유합니다. 개발팀에서 기존에 진행하던 일과 새로운 기능 추가 작업에 우선순위를 판단하여 개발 일정을 조율합니다. 개발 일정이 나오면 운영팀, 마케팅팀과 논의하여 사용자가 매끄럽게 온보딩 할 수 있도록 최종 기능 점검을 진행합니다.
서비스를 만드는 사람들, 드림포라 프로덕트 디자이너 편 (발행 예정 – 2월 22일 화요일)
우리의 리소스는 한정적이기 때문에 프로젝트 성격마다 방식이 다르기는 하지만, 가장 단순하면서 명료한 원칙을 따르려고 합니다. 우선 가장 사용자에게도, 비즈니스 적으로도 임팩트가 있고 리소스를 고려하여 현실화 가능한 것 위주로 리스트업을 합니다. 이 과정 안에서는 기획팀에서 사용자의 데이터를 리포팅하며 이 기능은 사용자들에게 꼭 필요해!라고 주장하거나 개발자들이 높은 크래쉬 레이트를 보여주며 이 부분을 다른 기능으로 대체할 수 없을까? 와 같은 치열한 논의가 오고 갑니다.
논의를 통해 나온 아이디어들은 1) Must have: 없으면 릴리즈 불가능한 꼭 필요한 필수 기능, 2) Should have: 높은 우선순위는 분명 하나 필수는 아닌 기능, 3) Could have: 우선순위는 낮지만 있으면 긍정적인 영향을 줄 수 있는 기능, 4) Will not have: 이번 릴리즈에는 포함되지 않아도 되지만 검토해볼 만한 기능 정도로 나누어 우선순위를 지정합니다. 이후 협의된 높은 우선순위의 기능부터 프로젝트를 진행하고 있습니다.
–
MoSCoW 모델 기본 개념
앞서 소개한 카노 모델도 그렇고, 오늘 정리한 MoSCoW도 그렇지만, 우리에게 적용을 하기로 결정하면 그 구체적인 방법을 먼저 공유하고 확인하는 과정을 꼭 거쳐야 합니다. 정리된 문서를 공유하고, 이 방법을 어떻게 활용할 수 있을지 등에 대해 먼저 논의하는 시간을 활용해보세요! 그래야 도입 과정에서 발생할 수 있는 문제를 미리 확인하고, 최소화할 수 있습니다. 어떻게 활용할 것인지 팀 단위의 논의가 마무리되었다면, 연습 기간을 갖는 것도 꼭 필요하다고 생각해요.
MoSCoW는 요구사항의 우선순위를 정하는 간편한 방법론으로 Must Have, Should Have, Could Have, Won’t Have의 줄임말 입니다. 오라클에서 근무하던 개발자 Dai Clegg가 제품 릴리즈에 대한 개발 작업 중 우선 순위를 쉽게 설정하기 위해 만들었습니다.
- Must have : 프로젝트, 제품에 있어 반드시 필요한 기능을 의미
- Should have : 중요하지만 시급성이 Must have 대비 낮은 기능
- Could have : 있으면 좋지만, 꼭 있어야 할 필요는 없는 기능
- Won’t have : 가장 덜 중요하고, 효과도 미미한 기능
(1) Must have
이 범주에 속하는지 더 명확하게 구분하려면 아래의 질문에 대해 생각해보는 것이 좋습니다. 참고로 MUST는 Minimal Usable SubseT의 약자이기도 합니다.
- 이 기능이 이번 릴리즈에 포함되지 않을 경우 어떤 영향을 주게 될까?
- 우리 프로덕트(서비스)가 이 기능 없이 잘 작동할 수 있을까?
- 이 기능을 대체할 더 간단한 방법이 있을까?
- (자동차라면) 타이어, 엔진, 연료 등이 될 수 있습니다.
다시 정리해보면, 이 기능이 없다면 이번 릴리즈가 의미 없게 되거나 대신할만한 기능이 없고, 서비스가 잘 작동하지 않을 가능성이 높은 경우 Must have에 포함시킬 수 있습니다. 즉, 우선순위가 가장 높은 단계로 생각할 수 있어요. 메시징 서비스에서 메시지 작성과 전송에 해당한다고 할 수 있습니다.
(2) Should have
나중에 해도 우리가 진행 중인 ‘단계’에 해당하는 프로젝트에 큰 영향이 없다는 것이 핵심입니다. (물론 있으면 좋고요!)
- 있으면 좋겠지만, 최우선 순위에 해당되지 않는 경우
- 생략해도 프로덕트나 서비스가 작동하는데 문제가 없는 경우
- 나중에 추가하면 유용한 기능은 무엇일까?
- 우리가 나중에 적용해도 성공적인 제품을 만들 수 있는 내용인지?
- (자동차라면) 에어컨이 포함될 수 있습니다.
있으면 더 좋겠지만, 그렇다고 지금 당장 할 필요는 없는 기능에 해당됩니다. 현재 릴리즈에는 영향을 주지 않아, 다음 릴리즈에 다시 고려할 수 있다는 것을 의미하기도 합니다. 앞서 사례로 언급한 메시징 서비스라면 주고받은 메시지를 검색하는 기능 등이 포함될 수 있습니다. 메시지 전송 속도 역시 마찬가지입니다.
(3) Could have
nice-to-have 라고 부르기도 합니다.
- 과감하게 제거하더라도 큰 영향을 받지 않는 기능
- (자동차라면) 후방 카메라가 포함될 수 있습니다.
예를 들면, 메신저에서 대용량 파일 보내기 기능은 있으면 좋을 듯 하지만, 빈도수가 적어서 꼭 지원해야 하는 기능은 아닐 수도 있습니다. 핵심 기능을 모두 적용한 뒤 사용자를 더 만족시킬 수 있는 수단으로 활용할 수 있는 기능이 그 대상입니다.
(4) Won’t have
그냥 하지 않아도 되는, 중요하지 않고 효과도 미미한 기능에 해당합니다. 때때로 “W”는 “Won’t” 대신 “Wish”를 사용하기도 합니다. 리소스를 엄청 투입해야 하는데, 효과가 미미하다면 이 기준에 따라 작업 대상을 분류할 수 있습니다.
–
MoSCoW 모델 활용 방법
기본 내용에 해당될 수 있지만, 우리가 프로젝트를 진행하는 이유와 목표 그리고 범위는 꼭 확인해야 합니다. 이런 기준이 없다면 백로그에 등록된 모든 내용을 확인해야 하는 상황을 마주할 수 있기 때문이에요. 이후 누가 우선순위 결정 과정에 포함되어야 하며, 결과를 확인해야 하는 사람(이해 관계자)이 누구인지에 대한 정의도 필요합니다.
실제 프로젝트에 참여하지 않는 사람이 포함될 경우 백그라운드에 대한 이해 없이 의견을 제안하고, 우선순위에 영향을 끼칠 수 있다고 생각해요. 2단계에 해당하는 내용을 1단계에서 고려하는 것은 굉장히 비효율적인 과정이기 때문입니다. 또 의견이 일치하지 않을 경우에 대한 기준을 함께 정하는 것이 좋습니다. 실제 저도 MoSCoW 모델을 있는 그대로 적용했다가 잘 작동하지 않아 아래와 같은 과정을 거치게 되었습니다.
–
알게 모르게 우리가 서비스를 개발하고 관리하는데 영향을 줄 수밖에 없는 내용들을 하나씩 적었다. 단계 별 설정한 목표에 부합하는지, 기존 운영 정책에 문제 되는 건 없는지, 사용자들에게 어떤 가치를 줄 수 있는지, 서비스 구조(개발 구조)에 영향을 주는 건 없는지, 배포 후 발생할 이슈를 특정할 수 있는지 등 20개 항목을 확인할 수 있었다. 작성 후 따로 구분하지 않고 팀원들에게 공유 후 추가로 중요하게 생각하는 기준이 있으면 이어서 써달라고 요청했다. 우리가 이런 논의를 하기 전, 각자의 입장에 따라 논의 내용이 달라지는 적이 많았는데 팀원들이 작성한 내용을 잘 정리하면 이런 문제를 조금이나마 해결할 수 있을 거란 생각이었다.
언제나처럼 중복되는 내용은 합치고, Must have/Should have/Could have/Won’t have 네 가지 기준에 각 항목을 하나씩 배치했다. 예를 들어 Must have가 기존에는 이 기능(항목)을 빼고 서비스 운영을 생각하기 어려운 기준이었다면, 이젠 목표 달성에 도움이 되는지, 리소스가 얼마나 투입되어야 하는지 등 세부 조건이 추가되어 더 빠르게 우선순위를 설정할 수 있는데 도움이 되었다. 팀원들 역시 각자의 상황과 입장이 반영되니 기준이 하나, 둘 담겨 있어 기준에 대한 별도 고민 대신 적용 이후 등에 대해 더 깊은 이야기를 나눌 수 있는 환경으로 받아들이게 되었다.
–
MoSCoW를 시작하기에 앞서 우리팀에 맞는 조건 등을 설정했다면 우리가 고려해야 할 ‘작업’을 모두 나열하는 과정으로 넘어갈 수 있습니다. 포스트잇을 사용해도 좋고, 미로와 피그잼 등의 서비스를 활용할 수도 있습니다. 이후 4가지 기준에 따라 작업 내용을 정리하는 작업이 필요한데요. 작업 내용을 그대로 활용하기 보다 문장으로 표현해 활용하는 것이 좋습니다. 예를 들어 회원가입, 로그인 등의 키워드가 있다면 (1) A user MUST sign up (2) A user MUST log in 등으로 작성하는 방법입니다.
다만 4가지 기준에 따라 작업을 분류하는 순서는 팀에게 맞는 방법을 자유롭게 확인하는 과정이 필요합니다. 위 이미지는 Must Have에 해당하는 작업을 먼저 설정하는게 아니라 Could – Should – Must 순으로 살펴보는 방법으로 이처럼 어떤 순서에 따라 작업을 분류하는게 더 맞는지 따져볼 필요가 있습니다.
이후 앞서 나열한 작업에 4가지 (M,S,C,W) 등의 구분을 적용하고 우선순위에 따라 작업 내용을 재구성합니다. 다만, 이대로라면 세부 작업 순위를 결정하기 어려운 상황이 될 수 있는데요. 이때 4가지로 구분 된 기존 방법 내 세부적인 우선순위를 추가, 적용하는 방법을 활용할 수 있습니다. 3 – 가장 복잡하며, 불분명한 요구 사항 / 2 – 난이도가 높은 작업 / 1 – 난이도가 평범한 작업 / 0 – 난이도가 쉽고, 가장 긴급한 작업 입니다.
6가지 필수 작업이 존재한다고 가정하면, 이는 현재 모두 같은 ‘수준’의 중요도를 가질 수 밖에 없는데요. 우리는 한정된 리소스를 갖고 있기에 어떤 작업을 먼저 진행해야 하는지에 대한 고민이 필요합니다. 이때 어떤 작업을 먼저 시작해야 할 지 다시 정리하는데 많은 도움을 줄 수 있는 것이 4가지 추가 조건이라고 할 수 있습니다.
저는 미로를 쓰다가 얼마전부터는 피그잼 내 템플릿을 직접 제작해 활용하고 있는데요. 스프레드 시트로 제작, 공유되는 템플릿도 많으니 참고해 입맛대로 맞춰가면 좋을 것 같습니다. 아래 리스트는 각 서비스 또는 제작 방법에 따라 확인할 수 있는 템플릿입니다. (가입 없이 확인할 수 있는 기준입니다.)
–
MoSCoW 모델의 장점
사용하기 쉬우며, 복잡한 계산이 필요하지 않은 방법입니다. 카노 모델만 하더라도, 사용자 설문을 진행해야 하고 분석 후 만족도와 불만족에 해당하는 계수를 계산하는 과정이 필요한데요. MoSCoW는 4가지 기준에 따라 백로그에 대해 포인트를 부여하는 방식으로 바로 사용할 수 있는 방법입니다. 역으로 이는 모든 팀원이 동등한 기준에 따라 우선순위를 선정할 수 있는 과정에 참여할 수 있다는 것을 의미합니다. 또, 엄격한 시간제한을 동반하지 않기 때문에 기능 별 융통성 있는 일정을 반영할 수 있습니다. 팀에게 유리한 방식으로 기능 개발, 릴리즈 시기를 조정할 수 있다는 것을 의미합니다. 또 참여하는 팀원들이 우리가 하고 있는 프로젝트에 대해 명확한 기준을 갖고, 기대를 갖게 만드는데 중요한 역할을 할 수 있습니다.
MoSCoW 모델의 단점
하지만, MoSCoW는 일차원적 시각에서 개별 요구사항의 중요도만 판단할 수 있어 각 요건이 제품에 기여할 수 있는 가치를 종합적으로 평가해서 선정하기 어렵습니다. 즉, 우리가 궁극적으로 달성하고자 하는 목표에서 바라보기 어려운 상황을 만들 수 있습니다. 하나의 기능이 주는 서비스에 대한 영향 등을 쉽게 판단할 수 없기 때문입니다. 그래서 여건이 된다면 2~3개의 우선순위 방식을 사용하는 것이 필요합니다. 대표적으로는 RICE Scoring과 Kano Model이 있습니다.
참고 내용
- Productivity: MoSCoW the simple prioritization technique for small products
- MoSCoW Prioritization
- MoSCoW Method: How to Make the Best of Prioritization
- How to Run a Prioritization Session Using the MoSCoW Framework
- 팀의 공통 기준에 따라 우선순위 설정하기
–
