MoSCoW 방법: 필수와 있으면 좋은 것 가려내기

MoSCoW 방법은 일을 네 바구니로 분류합니다. 반드시 있어야 함(Must have), 있어야 함(Should have), 있으면 좋음(Could have), 이번에는 없음(Won't have)입니다. Must는 필수이고 그것 없이는 계획이 실패합니다. Should는 중요하지만 결정적이지는 않습니다. Could는 시간이 허락하면 바람직합니다. Won't는 이번에 무언가를 빼기로 한 의도적인 결정입니다. 이 방법은 고정된 마감이 있고 그 안에 실제로 무엇이 들어갈지 정해야 할 때 가장 유용합니다.

MoSCoW의 유래

MoSCoW는 1990년대에 소프트웨어 컨설턴트 다이 클레그(Dai Clegg)가 개발했고, 애자일과 DSDM 프로젝트 수행의 주력이 되었습니다. 대문자는 네 범주를 나타내고, 소문자 o는 약자를 발음할 수 있게 할 뿐입니다. 이 방법이 퍼진 것은 모든 팀이 마주하는 문제를 풀기 때문입니다. 바람직한 것들의 긴 목록과 그것을 다 할 시간의 부족 말입니다. 모든 것이 최우선인 척하는 대신, MoSCoW는 무엇이 진짜 필수인지에 대한 명시적이고 공유된 결정을 강제합니다.

소프트웨어에서 태어났지만, 이 방법은 마감과 범위가 있는 무엇에나 통합니다. 행사 기획, 제품 출시, 심지어 이사 준비에도 통합니다. 시간이 고정되어 있고 바람이 역량을 넘는 곳이라면 어디서나 MoSCoW가 돕습니다.

MoSCoW를 평범한 우선순위 목록과 구별하는 것은 "타임박스"라는 말입니다. 범주는 중요도의 영구적 순위가 아니라, 하나의 특정 주기 안에 무엇이 들어가는지를 설명합니다. 한 기능이 이번 분기에는 Won't, 다음 분기에는 Must가 되어도 아무런 모순이 없습니다. 질문은 언제나 "실제로 가진 시간을 고려할 때, 이번 출시에 무엇이 속하는가?"이기 때문입니다. 그 틀이 논쟁을 어떤 아이디어가 객관적으로 최고인가에 대한 추상적 토론이 아니라 현실에 뿌리내리게 합니다.

네 범주

• 반드시 있어야 함(Must have). 협상 불가. 그것 없이는 산출물이 작동하지 않거나, 마감을 놓치거나, 법적·안전 규칙을 어깁니다.
• 있어야 함(Should have). 중요하고 빼면 아프지만 우회책이 있습니다. 계획을 깨지 않고 미룰 수 있습니다.
• 있으면 좋음(Could have). 바람직하고 넣는 비용이 낮으며, 시간이 부족할 때 가장 먼저 버려집니다.
• 이번에는 없음(Won't have). 이번 주기에서 명시적으로 범위 밖. 아무도 아직 온다고 넘겨짚지 않도록 공개적으로 보류합니다.

가장 날카로운 시험은 Must 범주에 대한 것입니다. 물으세요. "이것이 빠지면 무슨 일이 생기나?" 정직한 답이 우회책이나 사소한 성가심이라면, 그것은 Must가 아니라 Should입니다. 대부분의 팀은 처음 믿었던 것보다 훨씬 적은 것만이 진짜로 필수임을 발견합니다.

60퍼센트 규칙

가장 흔한 MoSCoW 실수는 모든 것을 Must로 표시하는 것입니다. 그것은 목적을 무너뜨립니다. 모든 것이 필수이면, 우선순위 없는 평평한 목록으로 돌아간 셈입니다. 널리 쓰이는 지침은 Must를 가용 노력의 약 60퍼센트로 유지하고 나머지를 Should와 Could로 채우는 것입니다. 남은 40퍼센트는 여분이 아니라, 모든 실제 프로젝트가 맞닥뜨리는 버그와 아픈 날, 돌발을 흡수하는 완충입니다. 무언가 틀어지면 Must가 아니라 Could를 버리고, 핵심은 여전히 제때 나갑니다.

실제 예시

엄격한 마감이 있는 간단한 예약 웹사이트를 출시한다고 상상해 보세요. 기능 목록이 이렇게 분류될 수 있습니다.

이제 결정이 명확합니다. 시간이 빠듯해지면 다크 모드가 가장 먼저, 할인 코드가 그다음 빠지고, 예약과 확인 이메일은 보호됩니다. 똑같이 중요한 점은, 모두가 적립 시스템이 빠졌음에 동의했으므로 출시 때 그것이 없어도 아무도 놀라지 않는다는 것입니다.

MoSCoW가 다른 방법들과 비교되는 방식

MoSCoW는 "다음은 어떤 단 하나의 작업인가?"가 아니라 "이 고정된 타임박스에 무엇이 들어가는가?"에 답합니다. 개인 일일 목록에는 더 가벼운 ABCDE 방법이 빠릅니다. 개별 작업을 결과로 매기기 때문입니다. 하나의 마감 안에서 분류하는 대신 프로젝트 전체를 기대 가치와 노력으로 비교해야 할 때는 RICE 점수가 순위를 매길 숫자를 줍니다. 진짜 고민이 중요한 일과 급한 일이 계속 충돌하는 것이라면, 아이젠하워 매트릭스가 그 긴장을 직접 드러냅니다.

실전에서 작동시키기

MoSCoW는 분류 도구인 만큼 대화 도구이기도 합니다. 진짜 힘은 팀이나 이해관계자가 범주에 함께 동의할 때 나타납니다. 라벨이 한 사람의 의견이 아니라 공유된 결정을 기록하기 때문입니다. 나중에 고객이 좋아하던 기능이 왜 빠졌는지 물으면, 계획 전체를 다시 다투는 대신 함께 합의한 라벨을 가리킬 수 있습니다. 각 주기 시작에 목록을 다시 보되, Should를 Must로 올릴 때는 60퍼센트 균형을 지키려 무언가를 내릴 때만 그렇게 하세요. 우선순위는 고정된 예산입니다. 한 바구니에 더하려면 다른 바구니에서 가져와야 합니다.

마지막 습관 하나가 MoSCoW를 오래가게 합니다. 위 예시처럼 각 라벨 옆에 한 줄짜리 이유를 쓰세요. 그 이유가 몇 주 뒤에 계획을 변호하게 하고, 상황이 바뀔 때 빠르게 다시 분류하게 합니다. 이유 없는 라벨은 그저 의견이고, 이유 있는 라벨은 뒷받침할 수 있는 결정입니다.

모든 것이 우선순위일 수는 없습니다. 그것을 인정하고 이번에 하지 않을 것을 이름 붙이는 순간, 중요한 일이 마침내 끝날 자리를 얻습니다.