MoSCoW : 요구사항 우선순위를 정하는 간편한 방법

제품 개발을 진행하다보면 항상 리소스가 부족합니다. 세상 어디에도 리소스가 남아도는 팀을 본 적은 없는 것 같습니다. 그렇기 때문에 성공적인 제품 개발은 한정된 리소스를 얼마나 잘 운영하는가가 핵심 중에 핵심이라고 볼 수 있습니다. 한정된 리소스를 잘 운영하는 방법은 여러가지가 있겠지만, 가장 정석은 요구사항의 우선순위화가 아닐까 합니다. (개발팀에게 맛있는 걸 많이 사줘서 생기 넘치는 야근을 유도한다!가 즉효약이긴 합니다...)

주변을 보면 우선 순위화를 잘하는 분들이 있습니다. 그 분들은 경험이 많아서 감이 좋은 걸까요? 아마 사실일 겁니다. 근데 실은 머리속에서 우선 순위를 결정하는 프레임워크가 존재하고 그 프레임워크에 여러 조건들을 대입해서 경험을 살린 나름의 우선순위화를 하는 것입니다. 이런 우선 순위화 방법 중, 아주 쉽고 기초적인 방법인 MoSCoW를 소개드리려 합니다.

MoSCoW는 요구사항의 우선순위를 정하는 간편한 방법론으로 Must Have, Should Have, Could Have, Won't Have의 줄임말 입니다. 대강 감이 오시겠지만 한국말로 조금 의역하면 다음과 같습니다.
- Must have : 치명적이고 시급성이 있는 꼭 필요한 기능!
- Should have - 매우 중요하지만... 시급성이 Must have 대비 낮은 기능
- Could have - 있으면 좋겠는데.. 꼭 있어야 할 필요는 없는 기능
- Won'have - 가장 덜 중요하고, 효과도 미미한 기능

그런데 문제는 말이 쉽지 막상 저 기준으로 나누어 보려면.. 애매모호 합니다. 이럴 때 도움이 되시라고 단계별 체크포인트와 예시를 정리해 보았습니다.
① Must have :
. 이 기능이 없다면 이번 릴리즈를 할 필요가 없어지거나,
. 이 기능이 없다면 이번 릴리즈, 프로젝트, 제품이 크게 훼손되고,
. 이 기능을 대체할 다른 쉬운 방법이 없다면 Must have!
. 예를 들면, 파일 보내기 기능을 개발한다고 할 때, 보내기 버튼을 제공하는 것은 Must have 입니다. (쉬운 예를 들자니.. 좀 꺼벙한 예가..)

② Should have : 나중에 해도 망하지는 않는다는 것이 핵심
. 이것이 있다면 확실한 가치를 제공하지만 없어도 제품이 동작하고,
. 지금하면 참 좋은데.. 리소스가 너무 부족해서 다음으로 미루어도 제품 동작을 못하게 하지 않는 다면 Should have!
. 예를 들면, 성능 개선 같은 요건입니다. 지금 파일이 10초에 보내지는데.. 3초 내로 전송이 완료되면 참 좋겠습니다. 3초내로 전송 완료하는 것은 Should have 요구사항이 됩니다. (제품의 관점과 경쟁력에 따라서 Must have와 큰 차이가 없기는 합니다.)

③ Could have : 흔히들 nice-to-have 라고 부르기도 함
. 과감하게 제거하더라도 큰 영향을 받지 않는 기능이라면 Could have
. 예를 들면, 카카오톡에서 1기가 짜리 대용량 파일 보내기 기능은... 있으면 좋을 듯 하지만, 빈도수가 적어서 꼭 지원해야 하는 기능은 아닐 수도 있습니다.

④ Won't have - 그냥 하지 않아도 되는 중요하지 않고, 효과도 미미한 기능
. 없는 것보다는 있으면 좋은 구석이 있으니 요구사항으로 등록했을 겁니다. 그런데, 리소스를 엄청 투입해야 하는데... 얻는 효과가 너무 미미한 경우라면 Won't have!
. 예를들면, 한달을 열심히 개발해서 기능을 추가해야 하는데... 담당 임원 한명만 사용하게 되는 기능이라면... (개발해야 할까요?)

MoSCoW는 이처럼 나름 간단하지만... 단점이 꽤 많기 때문에 주의할 점이 있습니다. MoSCoW는 상당히 일차원적인 시각에서 개별 요구사항의 중요도만 판단한 것이기 때문에... 각 요건이 제품에 기여할 수 있는 가치를 종합적으로 평가해서 선정하기 어렵습니다. 수익화가 제품의 목표이겠으나, 사용성이 좋아야 수익화로 이어집니다. 또한 UX 디자인도 멋져야 사용성이 좋아지겠죠? 예를 들면, 앱의 배경색상을 다크모드로 바꾸는 것은 개별적으로만 본다면 Could have 정도일 수 있습니다. 그런데, 배경 색상으로 인해 전류 소모량이 50% 감소할 수 있고 이를 통해 배터리 사용 시간이 증가해서 잠재적으로 20%의 판매 증가가 예상된다면..? Ooops..? 네.. 그렇습니다. 우선 순위화의 판단 기준이 하나, 두개 뿐이라면 Should have 인지? Could have 인지를 쉽게 판단하겠지만... 복잡한 제품에서는 꼭 그렇지는 않습니다.

그래서, 가능하다면 MosCow와 함께 2~3개의 추가적인 우선순위화 방식을 사용하는 것을 권장합니다. 대표적으로는 RICE Scoring과 Kano Model이 있습니다. 이번 포스트에서 이 두개까지 다루기에는 내용이 너무 길어져서 링크로 대신합니다.

항상 인력은 부족합니다. 그래서 우선순위화는 빠른 사업 추진의 필수 요소입니다. 경험이 많아서 감각이 뛰어난 분이라면 이런 도구나 프레임워크는 필요하지 않겠지만, 다른 사람에게 나의 감각적 판단 기준을 쉽게 설명해 주기 위해거라도 이런 도구들을 사용해 보시길 추천합니다.

 

[참고자료]

www.productplan.com/glossary/moscow-prioritization/

What is MoSCoW Prioritization? | Overview of the MoSCoW Method

https://medium.com/theagilemanager/management-moscow-the-simple-prioritization-technique-for-small-products-cbbfb13ae30c

Productivity: MoSCoW the simple prioritization technique for small products

https://productschool.com/blog/product-management-2/prioritization-techniques-product-managers/

3 Prioritization Techniques All Product Managers Should Know