다 중요한 것 같은데... 뭘 먼저 해야할까요?
PM으로 첫 프로젝트를 담당했을 때, 가장 어려웠던 건 우선순위 설정이었어요. 각자가 중요하게 생각하는 기준과 먼저 개발하고 싶은 기능이 달랐기 때문이죠. 중요하게 생각하는 이유로 서로를 설득하는 시간을 가지면 조금 좁혀지겠지? 라는 생각은 미팅 시작 30분 만에 무너졌고, 며칠 동안 뭘 먼저 해야하지? 라는 질문에 대한 답을 찾지 못했어요.
그렇게 각자 생각이 달라도, 판단하는 기준이 필요하다는 생각으로 하나, 둘 모두가 공감하고 동의할 수 있는 내용을 찾기 시작했어요. 팀과 개인의 목표도 있었고, 리서치 내용과 정리한 데이터 내용도 있었고, 회사가 가고자 하는 방향 등도 포함되었습니다. 이런 내용을 하나씩 정리하고 공유하고 논의하며 우리만의 기준을 만들었고, 우선순위를 설정하는 과정에서 서로의 의견이 좁혀지지 않으면 기준에 따라 중재하고 조금더 객관적으로 판단해 결정할 수 있었어요.
이후에도 같은 중요도와 점수를 가진 내용이 있는 경우 더 세부적으로 따져볼 수 있는 방법을 생각하는 등, 우선순위 결정에 필요한 고민들을 계속해왔습니다. 사실 지금도 쉽지 않은 우선순위 결정이라, 오늘은 다른 메이커들은 우선순위 설정 시 어떤 기준과 생각을 갖고 진행하는지 또 우선순위 설정에 참고할만한 방법은 무엇인지 함께 살펴보려고 합니다.
프로젝트 매니저 H : 우선순위 설정에 꼭 필요한 백로그 관리
백로그에 쌓인 무수히 많은 내용들을 보며 한 때는 스트레스를 많이 받았어요. 지금 당장 시작할 수 없는 업무나 의견 그리고 아이디어는 대부분 백로그에 등록해주세요.와 같이 커뮤니케이션을 마무리 하는 경우도 많았습니다. 다양한 성격의 ‘할 일’이 저장되다 보니 해결한 항목보다 해결해야 할 항목이 더 빠르게 늘어나기도 했죠. 가장 큰 문제는 백로그에 무언가 담을 때, 마땅한 구분이 없어 구조화가 되지 않았고 항목 작성 시 내부 기준이 명확하지 않아 제목이나 간단한 내용으로 작성되는 경우가 많다는 점이었어요. 이는 우선순위를 설정하는 과정에서 내용을 정확하게 구분해 파악하기 어렵고 시간을 더 필요로 한다는 문제로 이어졌습니다.
물론, 우리에게도 우선순위를 결정하는 기준은 있었는데요. 달성하고자 하는 목표입니다. 우리가 하고자 하는 기능 개발이 목표에 직접적으로 영향을 줄 수 있을까? 에 대한 답으로 우선순위를 설정하는 방법인데요. 문제는 이 질문에 여러 답이 존재하는 경우입니다. 사실 그런 경우가 많을 수밖에 없기에, 같은 중요도를 지녔을 때 이를 더 세분화해서 파악하고 순서를 정할 수 있는 프레임워크를 폭넓게 살펴보기 시작했어요. 그렇게 MoSCoW, Kano, RICE 등 우리 팀에 잘 맞을 것 같은 몇 가지를 찾아 정리하고 주변 PM들이 자주 사용하는 방법을 함께 살펴봤어요. 그중 MoSCoW는 PM이 업무 단위 내용과 이유를 팀에게 전달하고 활용하기에 가장 적합해 보였고, 난도가 높지 않아 팀에게 진행 방법을 공유해 테스트로 몇 번 사용해 보자고 제안했습니다.
그런데 달성하고자 하는 목표도 명확하고, 우선순위 설정에 필요한 세부 기준도 설정했으니 이전보다 더 쉽게 논의 및 결정이 가능할 거라 생각했지만 실제론 그렇지 않았습니다. 세부 기준까지 고려하지 못한, 급한 마음에 전체 과정을 돌아보고도 일부 단계에 대한 개선점만 적용한 탓이었어요. 또 이 기준이 백로그에 등록 시 구분에는 적용이 되지 않아 보드에서 어떤 범위까지 회의 시 다뤄야 하는지 선정하는 과정은 이전과 같은 어려움이 있었습니다.
그래서 백로그에 담는 순간부터 정리될 수 있는 구분을 정하기로 했습니다. 신규 기능, 기능 개선, 피드백 등 아사나를 기준으로 리스트를 하나씩 생성해 작성하는 순간 특정 구분에 담길 수 있도록 했어요. 또 리스트에 항목을 추가할 때 목표에 어떻게 기여할 수 있는지, 누구를 위해 문제를 해결하는지, 바라는 결과는 무엇인지 등 구체적인 이유와 논의 시 우리가 집중해야 하는 부분들을 함께 정리할 수 있도록 템플릿 형태로 만들어 공유했습니다.
우선순위를 설정하는 기준도 다시 정리했어요. 기존의 프레임워크가 우리에게도 반드시 잘 작동하는 건 아니라는 사실을 앞서 깨달았기 때문입니다. 그래서 알게 모르게 우리가 서비스를 개발하고 관리하는데 영향을 줄 수밖에 없는 내용들을 하나씩 적었어요. 단계 별 설정한 목표에 부합하는지, 기존 운영 정책에 문제 되는 건 없는지, 사용자들에게 어떤 가치를 줄 수 있는지, 서비스 구조(개발 구조)에 영향을 주는 건 없는지, 배포 후 발생할 이슈를 특정할 수 있는지 등 20개 항목을 확인할 수 있었어요.
중복되는 내용은 합치고, Must have/Should have/Could have/Won’t have 네 가지 기준에 각 항목을 하나씩 배치했어요. 예를 들어 Must have가 기존에는 이 기능(항목)을 빼고 서비스 운영을 생각하기 어려운 기준이었다면, 이젠 목표 달성에 도움이 되는지, 리소스가 얼마나 투입되어야 하는지 등 세부 조건이 추가되어 더 빠르게 우선순위를 설정할 수 있는데 도움이 되었습니다. 팀원들 역시 각자의 상황과 입장이 반영되니 기준이 하나, 둘 담겨 있어 기준에 대한 별도 고민 대신 적용 이후 등에 대해 더 깊은 이야기를 나눌 수 있는 환경으로 받아들이게 되었죠.
메이커의 꿀팁
- 우선순위 결정 기준보다 먼저 필요한 건, 백로그가 공통 할 일 목록이 아니라는 점을 인지하는 것
- 우선순위 결정에 포함되는 내용들은 가능한 동일한 포맷(양식)에 맞춰 정리하기
- 백로그에 등록할 때, 결정된 포맷과 기준에 따라 정리하기
- 우선순위를 결정하는데 필요한 기준을 내부 상황에 맞춰 명확하게 정리하기
백로그 관리가 어려운 상황에서 읽어보면 좋은 글
‘ 백로그와 우선순위 선정’글에서도 백로그 관리 시 동일한 기준에 따라 내용을 입력하는 것에 대해 확인할 수 있어요. 백로그 자체가 개발해야 할 기능, 제품에서 요구하는 기능과 우선순위를 뜻하기에 할 일 목록이나 하지 못한 것들을 모아두는 공간으로 인식하지 않는 것이 중요하다고 이야기하고 있죠. 백로그에 무언가 입력할 땐, ‘누가’, ‘어떤 문제’를 겪고 있는지, 그래서 우리가 ‘문제를’, ‘어떻게 해결’할 수 있을지, 그 문제를 해결함으로써 ‘얻게 되거나 기대하는 결과’는 무엇인지 명시해야 함을 말하고 있습니다. 이렇게 동일한 기준에 따라 정리해야 우선순위 선정이 쉬워지고 설득 역시 자연스럽게 이어질 수 있겠죠?
백로그에 필요한 핵심 질문 세 가지가 잘 정리된 글도 있어요. ‘백로그’ 관리의 5가지 팁에서는 스스로에게 묻고, 팀에게 묻고, 수백 개의 백로그 앞세 서서 질문에 대한 답을 요구해야 한다는 내용이 담겨있는데요. (1) 우리가 해결하려는 문제는 무엇인가(왜 우리는 이 일을 하는가) (2) 우리는 누구를 위해 이 문제를 해결하려 하는가(누구에게 어떤 접근이 필요한가) (3) 우리가 원하고 바라는 결과는 무엇인가(성공의 기준은 무엇인가) 등이에요. 백로그를 단순하게 해야 할 일을 쌓아두는 곳으로 여기게 되면, 팀은 잘못된 결과를 만들어 낼 가능성이 높아요. 때문에, 질문으로 시작해 팀이 답을 쌓는 구조가 되어야 과정이 필요하다고 이야기하고 있어요.
프로덕트 매니저 M : 우선순위를 완성하는 것은 공감과 합의
작은 스타트업에서 사수 없이 PM과 기획자 역할을 맡고 있습니다. 처음에는 사내에 우선순위를 정하는 기준이 따로 없이 급한 불을 먼저 끄는 식으로 개발을 하다가, 시간이 지나면서 백로그 정리의 필요성을 느끼고 우선순위 방법에 대한 논의를 시작했어요. 먼저 많이 알려진 프레임워크들을 알아보고 그중 저희 팀에게 적합한 방법을 선정했습니다. 그렇게 시도해 본 것은 ICE 프레임워크였어요. ICE는 임팩트(Ice), 성공 확률(Confidence), 구현하는 데 걸리는 시간(Ease)에 따라 백로그에 있는 아이템에 점수를 부여한 뒤 높게 나온 것부터 작업하는 방법이에요. ICE 우선순위에 따라 백로그 아이템을 열심히 정렬한 목록을 팀에 공유했는데, 생각보다 반응이 시큰둥한 것을 느꼈어요.
팀원들과 한 명씩 이야기를 나누어보니 프레임워크 자체에 대한 불신은 아니었어요. 그보다 프레임워크의 기준을 평가할 때 제가 중요하지 않다고 생각하는 것을 마케팅 팀에서는 중요하다고 생각하거나, 제가 금방 실행할 수 있겠다고 생각했던 것을 개발팀에서는 오래 걸린다고 생각하는 등 저마다 입장이 다르기 때문에 생긴 문제였어요. 또 제가 점수를 매긴 근거에 대해 충분히 소통하지 않고 결과만 기계적으로 전달한 것도 잘못이었어요. 그때 우선순위를 정하는 과정도 결과 못지않게 중요하다는 것을 깨달았어요. PM인 제가 주도권을 가져야 한다고 생각한 나머지, 우선순위를 매기는 과정에서 팀원들의 이야기를 듣는 과정을 생략한 거예요.
그 후에는 백로그와 우선순위 점수를 모두가 볼 수 있는 문서로 설정하여 팀원들이 자유롭게 의견을 제시할 수 있도록 했습니다. 그리고 스프린트에 할 일을 넣기 전, 우선순위에 대해 공유하고 합의하는 시간을 따로 만들었습니다. 우선순위 미팅 때 만약 가장 중요하다고 생각하는 업무에 대해 팀원의 이견이 있을 경우 충분히 이야기를 나눴고, 그 과정에서 서로가 가진 다른 관점과 어떤 가치를 더 중요하게 여겼는지 이해할 수 있게 되었어요. 팀원들이 저의 시야에서 보지 못한 고려사항에 대해 짚어주는 경우도 있었고, 제가 우선순위에 대해 같은 결정을 내리더라도 그 결정의 맥락을 이해한 팀원들이 더 빠르게 동기화되는 효과가 있었습니다.
메이커의 꿀팁
- 프레임워크를 적용할 때 팀원들과 충분히 소통하는 과정 거치기
- 동일한 우선순위 기준이라도 팀에 따라 다르게 점수를 매길 수 있다는 것을 인지하기
- 우선순위 문서를 공개하고 팀원들의 의견을 반영할 수 있는 기반 만들기
팀원의 공감을 얻는 우선순위를 설정하기 위해 읽어보면 좋은 글
‘우선순위, 그래서 PM이 어떻게 설정하라는 건데?’에서도 우선순위 설정의 본질이 ‘수많은 일들 속에서 우리 팀이 해야 할 일을 선별하는 작업’이라고 지적하면서, 협업하는 사람들을 설득하지 못한다면 그 우선순위는 나쁜 우선순위가 된다고 말하고 있어요. 또한 설득의 대상과 범위에 따라 우선순위를 설득을 위한 작업의 깊이를 다르게 가져간다는 말도 공감이 됐어요. 예를 들어, 매일 스크럼을 같이 하면서 배경지식이 공유된 상태에서는 간단한 설명만으로도 우선순위 설정을 하는 데 문제가 없지만, 다른 팀의 업무 협조를 얻어야 하거나 전사 차원의 작업일 경우 업무에 대한 배경지식이 없는 사람들을 위해 명확한 근거를 마련해야 공감을 얻을 수 있다고 말하고 있어요.
‘우선순위에 프레임워크를 사용해보자’라는 글에는 ‘HIPPO’라는 개념을 소개하고 있어요. ‘가장 돈을 많이 받는 사람의 의견’(The Highest paid person’s opinion)의 약자인 이 개념은 직급이 높거나 월급을 가장 많이 받는 사람의 의견이 의사결정에서 절대적인 역할을 해서는 안된다는 뜻을 가지고 있어요. 이 글에서는 2014년 아마존에서 fire phone이라는 모바일 디바이스를 CEO의 강력한 의견대로 출시했다가 실패한 사례를 들고 있는데요, 한 직원은 인터뷰에서 ‘누군가 우리에게 왜 그것을 만드냐고 물어봤을 때, 우리는 항상 제프(CEO)가 원하기 때문’이라고 대답할 수 밖에 없었다’라고 했어요. 우선순위를 설정할 때 PM이나 상급자의 의견이 당연한것처럼 받아들여지고 이견을 제시하기 어려운 분위기가 생기는 경우가 있다면 경계해야 할 것 같습니다.
서비스 기획자 S : 전체 일정과 팀의 상황을 고려한 우선순위 설정
저희 회사는 기능 조직 단위로 팀이 구성되어 있어서, 업무가 주로 워터풀 방식으로 진행되는 편입니다. 그러다 보니 업무 초기에는 주로 기획과 운영정책 설계가 몰려 진행되고 이후 디자인과 개발이 착수되는 형태로 회사 전반적인 업무가 진행되고 있어요. 그래서 처음에는 오랜 고민을 해야 하는 업무 중심으로 우선순위를 두었는데, 워터풀 방식으로 인해 제가 고민을 하는 동안에는 디자인팀과 개발팀은 기획이 완료되길 기다리는 수밖에 없는 상황이 반복되었습니다. 이로 인해 회사가 한 번에 몰려서 업무를 처리하게 되는, 한철 같다는 자조적인 반응들이 많았죠.
그래서 업무 방식을 바꿔 회사가 분기별 진행해야 하는 프로젝트 라인업이 결정되면, 관련된 전체 구성원이 모여서 프로젝트별 다 같이 논의하는 시간을 갖기 시작했습니다. 얼마나 많은 리소스를 투입해야 하는지(기획, 디자인, 개발 등) 그리고 실제 진행했을 때 임팩트는 얼마나 될 수 있을지(핵심 지표, 매출 등)를 기준으로 각 부서별 고민해야 하는 부분을 러프하게 공유, 각 팀이 최소한으로 필요한 시간까지 함께 공유했는데요.
덕분에 기획자들은 팀별 투입이 필요한 시간과 투입 효과를 바탕으로 프로젝트의 범주를 감안하여 먼저 빨리 끝내야 하는 업무와 그보다 조금 뒤에 진행해도 되는 업무들을 조정할 수 있게 되었어요. 무엇보다 서로의 업무 현황 등을 이전과 연결해서 확인할 수 있어, 일정은 물론 우선순위에 필요한 기준을 더 구체적으로 확인할 수 있었고 같은 임팩트를 줄 수 있는 업무라 하더라도 투입 대비 리소스 등에 따라 더 명확한 구분이 가능해졌어요.
전체 일정과 팀의 상황을 고려한 우선순위를 설정하다 보니, 지금까지 제가 고려한 업무의 우선순위는 내가 오늘 할 일과 팀이 해야 하는 일에만 집중하고 있었다는 걸 깨닫게 되었어요. 조율해야 하는 협의체가 늘어날수록 우선순위의 변경과 일정 조율은 더 어려울 수밖에 없는데요. 이를 미리 고려해 우선순위를 설정해 일을 진행하다 보니 같이 일하는 팀과 동료와의 소통도 원활해지고, 우선순위가 자주 바뀌지 않는 안정감을 줄 수 있게 된 것 같아요.
메이커의 꿀팁
- 프로젝트 진행 전, 참여 팀이 함께 모여 서로의 상황을 확인하는 시간 갖기
- 팀 전체를 기준으로 투입 시간과 결과의 임팩트에 따라 우선순위 설정하기
- 전사 → 팀간 협업 → 팀 → 개인 순서에 따라 우선순위를 설정해 혼란 줄이기
팀의 상황을 고려한 우선순위 설정 시 읽어보면 좋은 글
앞서 살펴본 프로젝트 단위의 전체 일정을 고려한 우선순위 설정 시 장점은 아무래도 팀 간 상황을 조금더 정확하게 파악할 수 있다는 점이 아닐까 싶은데요. ‘ 당신은 Great PM 인가요, Good PM인가요?’에서 비슷한 내용을 찾아볼 수 있었어요. Good PM은 팀의 ‘현재’를 파악하지만 ‘Great PM’은 팀의 ‘과거, 현재, 미래’를 파악, 팀이 원하고 필요하고 지금 당장 해야 할일을 파악한다는 내용이었죠. 나아가 이런 배경이 만들어지면, 우선순위에 대한 기준 또한 명확해질 수 있고 세세한 순위까지 다같이 설정할 필요 없이, 팀원이 각자 태스크에 따라 우선순위를 설정할 수 있다는 내용도 포함되어 있어요.
‘ 우선순위를 어떻게 정할까’에서는 투입해야 하는 리소스와 얻을 수 있는 임팩트를 기준으로 우선순위를 설정하는 방법에 대해 더 자세한 내용을 확인할 수 있어요. 유사한 맥락에서 ‘ 프로덕트 디자인에서 우선순위를 정하는 네 가지 방법론’에서는 ‘Value vs Effort(해결해야 할 과제나 업무의 특성을 성과놔 노력이라는 투자 대비 효과로 평가하는 기법’ 내용을 확인할 수 있는데요. 적은 노력과 높은 성과를 낼 수 있는 업무라면 지속적인 유지와 관리가 필요하며, 많은 노력을 필요로 하지만 낮은 성과가 예상되는 업무라면 과감한 결단이 필요한 내용이라는 것을 알 수 있어요. 이 두 가지 방법의 장점은 우리의 상황을 대입해 업무를 진행하기 전, 충분한 논의와 확인을 할 수 있다는 점이 아닐까 싶네요!
프로덕트 디자이너 A : 우리가 정말 해야할 일인가? 확인하기
우선순위 설정에 대한 고민이 많았을 때, 저도 해외/국내 아티클을 다양하게 살펴보고 정리했어요. 디자이너로 업무를 시작한 뒤 첫 PM을 하면서 가장 어려웠던 과정이 우선순위 설정과 그 과정에서의 커뮤니케이션이었기 때문인데요. 제가 사용할 수 있는, 팀에게 잘 맞을 것 같은 방법론이자 프레임워크를 찾는 건 어렵지 않았어요. 하나씩 시도해 보면서 적용해 가는 것도 충분히 활용할 수 있는 상황이었죠.
다만, 제 기준에서 진짜 큰 도전은 ‘진짜 일’과 ‘가짜 일’을 구분하는 일이었어요. 여기서 ‘진짜 일’이란 우리의 핵심 지표에 영향을 주는 것이고, ‘가짜 일’이란 핵심 지표와 관련이 없는 내용이라고 할 수 있는데요. 이 구분이 먼저 진행되지 않으면 우선순위를 설정해 업무를 진행하다가 관련이 없다는 것을 파악할 수 있고, 아이디어 등이 백로그에 들어갈 때 역시 적절하지 않은 내용이 들어가는 등 혼란을 줄 수 있다고 생각했어요.
진짜 일과 가짜 일을 구분하기 위해 제가 먼저 했던 노력은 우리의 목표를 명확히 하는 일이었어요. 목표가 없었던 건 아니지만, 계속해서 동기화를 하지 않으면 목표와 사용자 입장이 아닌 우리가 원하고 필요한 기능 등이 우선될 수 있기 때문이에요. 그래서 기능 개발에 필요한 논의에 앞서 늘 우리의 목표, 달성하고자 하는 것을 확인하고자 했어요. 사공만 많은 배가 되지 않고, 모두가 같은 목표와 기준을 갖고 몰입할 수 있는 환경을 만드는 것이 중요하다고 생각했습니다. 모두가 목표를 명확하게 인지한 상태라면 우선순위를 결정함에 있어서도 투입되는 시간이나 리소스와 별개로 이게 정말 우리 목표 달성에 도움이 되는 건가? 우리가 꼭 해야 할 일이 맞나? 와 같은 질문을 스스로에게 그리고 서로에게 던질 수 있어 다른 길로 새는 것을 막을 수 있어요.
정리해 보면, 우리가 지금까지 진행했던 업무 중 목표와 연관성이 높은 것과 낮은 것을 확인, 이를 바탕으로 앞으로 해야 할 업무를 다시 구분할 필요가 있어요. 이전 업무의 경우 목표 달성에 기여한 것이 무엇인지 확인해 다음 업무와 연결하는 것도 고려할 수 있고요. 이렇게 진짜 일과 가짜 일을 구분한 다음 우선순위 설정에 들어갑니다. 우선순위 설정에 활용할 수 있는 방법은 여러 가지가 있지만 저는 크지 않은 규모의 조직에서 일하고 있어 우리가 최소한의 노력으로 큰 임팩트를 낼 수 있는 기준으로 활용하고 있어요.
메이커의 꿀팁
- 팀이 함께 진행할 업무 중, 우리 목표와 연관성이 떨어지는 것 구분하기
- 이전 진행 업무 중, 목표 달성에 기여한 것 확인하기
- 목표와 연관성이 높은 업무를 대상으로 우선순위 설정하기
가짜 일의 구분이 어려울 때 읽어보면 좋은 글
우선순위를 정해볼까요? 라는 질문을 처음 던졌을 때 팀원들의 반응이 아직도 떠올라요. 뭐부터 하면 좋을까요? 기준이 뭔가요? 이거 진짜 해보고 싶었는데 먼저 하면 안될까요? 등 혼란 그 자체였죠. 우선순위를 설정하는 기준 자체도 중요하지만, 앞뒤로 우리가 무엇을 어떻게 고려해야 하는지를 깨달았던 순간이기도 했어요. 가짜 일과 진짜 일의 구분은 우선순위 설정에 앞서 우리가 중요하게 생각해야할 문화이자 단계라고 생각하는데요.
‘ 가짜 일 문화를 초래하는 원인 12가지’에서는 우리가 가짜 일을 구분하는데 있어 생각해야 할 내용이 담겨 있어요. 몇 가지를 추려보면 (1) 명확하지 않은 사업 및 전략계획 (2) 고객(사용자)에게서 이탈 (3) 근시안적 사고 (4) 무신경한 리더들 등이 있는데요. 저는 이중에서 (1)번과 (2)번에 가장 공감했어요. 모두에게 ‘공통적’으로 적용될 수 있는 기준이 없다면, 각자가 생각하는 방향과 목표에 따라 의견을 내고 우선순위를 생각할 수 있어 위험하고, 이 모든 논의가 서비스나 제품을 사용하는 고객과 사용자 중심이 아닌 경우 그저 팀과 개인의 만족을 위한 업무가 될 수 있기 때문입니다.
가짜 일 vs 진짜 일 도서에서도 유사한 내용을 확인할 수 있어요. 책에서는 가짜 일이 발생하는 주요 원인 10가지를 제시하는데, 직원이 회사가 원하는 목표와 업무 완료일을 제대로 모를 때, 우선순위에 대한 확신이 없을 때, 불합리한 전략, 전략과 실행의 불일치 등이 포함되어 있어요. 결국, 우선순위를 설정하는 데 있어 목표 달성에 꼭 필요한 내용이라는 확신을 심어줄 수 있어야 하며, 실제 업무를 진행하는 데 있어 목표에 얼마나 근접하고 있는지 등을 확인할 수 있어야 한다는 것을 의미합니다.
우선순위 설정에 도움이 되는 방법론
1. MoSCoW 모델
MoSCoW는 요구사항의 우선순위를 정하는 간편한 방법론으로 Must Have, Should Have, Could Have, Won’t Have의 줄임말 입니다. 오라클에서 근무하던 개발자 Dai Clegg가 제품 릴리즈에 대한 개발 작업 중 우선 순위를 쉽게 설정하기 위해 만들었습니다.
- Must have : 프로젝트, 제품에 있어 반드시 필요한 기능을 의미
- Should have : 중요하지만 시급성이 Must have 대비 낮은 기능
- Could have : 있으면 좋지만, 꼭 있어야 할 필요는 없는 기능
- Won’t have : 가장 덜 중요하고, 효과도 미미한 기능
위 4가지 방법에 따라 구분 후 세부적인 우선순위를 추가, 적용하는 방법을 함께 활용할 수 있습니다. 3 – 가장 복잡하며, 불분명한 요구 사항 / 2 – 난이도가 높은 작업 / 1 – 난이도가 평범한 작업 / 0 – 난이도가 쉽고, 가장 긴급한 작업 입니다.
2. RICE 모델
RICE 모델은 제품 관리자가 네 가지 요소에 점수를 매겨 출시할 주요 기능, 제품 등을 결정하는 데 도움이 되도록 설계되었습니다.
- Reach : 얼마나 많은 수의 사용자에게 영향이 미치는지
- Impact : 고객에게 선보였을 때 전환율을 얼만큼 높일 수 있는지
- Confidence : 내가 측정한 R, I, E의 값에 얼마나 자신이 있는지(예, 구체적인 증거가 있다면 도움이 됨)
- Effort : 이를 수행하는데 있어 드는 노력이 얼마나 클지 (시간, 인력)
최종적으로 RICE 점수는 = R * I * C / E 로 계산을 합니다. 이 결과가 큰 순서대로 더 중요한 일이 되겠죠?
3. ICE 프레임워크
그로스 해킹의 아버지, 드롭박스의 그로스 해킹으로 유명한 ‘Sean Ellis’가 사용하는 의사 결정 프레임워크. ICE의 I는 Impact, C는 Confidence, Esms Ease를 뜻하며 이를 조금더 자세히 살펴보면 아래와 같습니다.
- Impact : 이 실험이 얼마나 영향력 있을까? 회사의 핵심 KPI에 얼마나 많은 영향을 미칠지 측정하는 요소
- Confidence : 이 실험이 성공할 확신을 얼마나 가지고 있는지?
- Ease : 이 실험을 론칭하는데 시간이 얼마나 걸리는지?
4. 아이젠하워 매트릭스
작업을 중요도와 시급성을 기준으로 4분면으로 분류하는 방법입니다. 긴급한 업무는 바로 처리되어야 하고 일정 안에 이 작업을 완료하지 않으면 명확한 결과가 나타나는 일을 의미하고, 중요한 업무는 즉각적인 관심이 필요하지 않을 수 있지만 장기 목표를 달성하는 데 도움이 되는 업무입니다. 먼저 사분면으로 일을 나눈 뒤, 각자 다른 전략을 적용합니다.
- 1사분면 (중요하면서 급한 일): 해야 할 일
- 2사분면 (중요하지만 급하지 않은 일): 계획해야 할 일
- 3사분면 (중요하지 않지만 급한 일): 위임할 일
- 4사분면 (중요하지 않고 급하지 않은 일): 삭제할 일
각 요소별 10점을 만점으로, 총 합점이 ICE점수가 되며 점수에 대해서는 충분히 토론한 뒤 PM이 최종 권한을 가지게 됩니다. 점수가 높은 아이디어 순위대로 업무를 진행하게 되고요. 더 좋은 아이디어는 언제든지 추가될 수 있고, ICE 점수별로 전체 리스트에 반영됩니다.
7월 13일 목요일 발행될 다음 뉴스레터 주제는 '업무 리뷰'입니다. 기획 및 정책, 디자인, 마케팅 등 업무 단계에 따라 진행되는 리뷰와 관련해 메이커 코멘트는 물론 관련글을 자세히 살펴볼 예정이에요. 그럼, 다음 뉴스레터도 많은 기대 부탁드릴게요!
#지식토스트
