💦 나만 모르는 프로덕트 관리 이야기 [✏️ 제품 개발에 도움이 되는 방법론 : MoSCoW 모델] (👀간단 요약) 📌 MoSCoW란? ✓ 요구사항의 우선순위를 정하는 간편한 방법론으로 M

💦 나만 모르는 프로덕트 관리 이야기 [✏️ 제품 개발에 도움이 되는 방법론 : MoSCoW 모델] (👀간단 요약) 📌 MoSCoW란? ✓ 요구사항의 우선순위를 정하는 간편한 방법론으로 Must Have, Should Have, Could Have, Won’t Have의 줄임말 ✓ Must have : 프로젝트, 제품에 있어 반드시 필요한 기능을 의미 ✓ Should have : 중요하지만 시급성이 Must have 대비 낮은 기능 ✓ Could have : 있으면 좋지만, 꼭 있어야 할 필요는 없는 기능 ✓ Won’t have : 가장 덜 중요하고, 효과도 미미한 기능 📌 Must have ✓ MUST는 Minimal Usable SubseT의 약자이기도 ✓ 이 기능이 이번 릴리즈에 포함되지 않을 경우 어떤 영향을 주게 될까? ✓ 우리 프로덕트(서비스)가 이 기능 없이 잘 작동할 수 있을까? ✓ 이 기능이 없다면 이번 릴리즈가 의미 없게 되거나 대신할만한 기능이 없고 ✓ 서비스가 잘 작동하지 않을 가능성이 높은 경우 Must have에 포함 가능 📌 Should have ✓ 나중에 해도 우리가 진행 중인 ‘단계’에 해당하는 프로젝트에 큰 영향이 없다는 것이 핵심 ✓ 있으면 좋겠지만, 최우선 순위에 해당되지 않는 경우 ✓ 생략해도 프로덕트나 서비스가 작동하는데 문제가 없는 경우 ✓ 있으면 더 좋겠지만, 그렇다고 지금 당장 할 필요는 없는 기능에 해당 ✓ 현재 릴리즈에는 영향을 주지 않아, 다음 릴리즈에 다시 고려할 수 있다는 것을 의미하기도 📌 Could have (= nice-to-have) ✓ 과감하게 제거하더라도 큰 영향을 받지 않는 기능 ✓ 핵심 기능을 모두 적용한 뒤 사용자를 더 만족시킬 수 있는 수단으로 활용 📌 Won’t have ✓ 하지 않아도 되는, 중요하지 않고 효과도 미미한 기능에 해당 ✓ 때때로 “W”는 “Won’t” 대신 “Wish”를 사용하기도 📌 활용 방법 ✓ 우리가 프로젝트를 진행하는 이유와 목표 그리고 범위는 꼭 확인해야 ✓ 누가 우선순위 결정 과정에 포함되어야 하며, 결과를 확인해야 하는 사람(이해 관계자)이 누구인지에 대한 정의도 필요 ✓ 우리팀에 맞는 조건 등을 설정했다면 우리가 고려해야 할 ‘작업’을 모두 나열하는 것으로 시작 ✓ 4가지 기준에 따라 작업을 분류하는 순서는 팀에게 맞는 방법을 자유롭게 확인하는 과정이 필요 ✓ Could – Should – Must 순으로 살펴보는 방법 등 ✓ 4가지 (M,S,C,W) 등의 구분을 적용하고 우선순위에 따라 작업 내용을 재구성 ✓ 4가지로 구분 된 기존 방법 내 세부적인 우선순위를 추가, 적용 ✓ 3 – 복잡하며, 불분명한 요구 사항 / 2 – 난이도 높은 작업 / 1 – 난이도 평범한 작업 / 0 – 난이도 쉽고, 긴급한 작업 ✓ 어떤 작업을 먼저 시작해야 할 지 다시 정리하는데 많은 도움을 줄 수 있는 것이 4가지 추가 조건