우선순위에 프레임워크를 사용해보자
프레임워크를 활용해 업무 우선순위 정리하기
"시간의 걸음걸이에는 세 가지가 있다. 미래는 주저하며 다가오고, 현재는 화살처럼 날아가며, 과거는 영원히 정지하고 있다."
- 프리드리히 실러
한정적인 리소스(시간, 인력 등) 내에서 최대의 효율을 내는 것, 변화하는 내/외부 상황에 맞게 과제의 우선순위를 분배하는 것은 기획자와 PM의 역량이다. 보통 회사에 우선순위란 회사의 수익에 직결되는 과제나 높은 직급의 상사가 요청한 과제가 최상단에 위치한다. 그러다 보면, 중장기적 관점에서 더 큰 성과를 낼 수 있는 과제들이나 지금 성과를 극대화할 수 있는 업무들을 처리할 타이밍을 놓치는 경우가 다반사다.
그래서 우리는 '약속된 프레임워크'가 필요하다. 서로 어떤 일이 더 급하다, 중요하다 왈가왈부할 것 없이 명확한 우선순위 가이드라인을 제시한 프레임워크를 만들고, 이 규칙 안에서 과제를 처리해야 한다. 오늘은 이런 업무 우선순위 관리에 도움을 줄 프레임워크 두 가지를 살펴보자.
아이젠하워 매트릭스
아이젠하워 매트릭스(The Eisenhower Matrix) 혹은 아이젠하워 박스(The Eisenhower Box)로 불리는 이 매트릭스는 업무의 중요도, 시급성에 따라 해야 할 일의 우선순위를 결정해주는 4사분면이다. 여기서 누구는 "중요하면 급한 일이고, 급한 일이면 중요한 일 아니냐"라고 반문할 수도 있지만, '중요한 일'과 '시급한 일'은 엄연히 다르다.
미국의 34대 대통령이자, 제2차 세계 대전 기간에 5성 장군이었던 아이젠하워는 후에 아이젠하워 매트릭스로 발전하게 되는 아이디어를 제안했다. 1954년에는 한 대학 총장의 말을 인용하며 “저에게는 긴급한 문제와 중요한 문제, 두 종류의 문제가 있습니다. 긴급한 것은 중요하지 않고, 중요한 것은 절대 긴급하지 않습니다”는 내용의 연설을 하기도 했다.
아이젠하워 매트릭스시급한 일 Vs 중요한 일
'시급한 일'은 즉시 처리해야 하는 업무다. 이들은 대게 갑자기 생겨나거나(긴급한 오류, 수정 등) 예전부터 산재되어 오다가 완료 예정일을 훌쩍 넘긴 업무들이다. 급하지 않았다고 판단했기에 계속 우선순위에서 미루어 왔지만, 결국 약속된 완료일을 넘겼기 때문에 '시급한 일'이 되어 버린 것이다.
'중요한 일'은 즉각적으로 처리해야 하는 문제는 아니지만, 장기적 관점에서 보았을 때 사업의 명운이 달린 중요한 임무다. 중요한 일은 '분기별 회사 전략 과제', '회사 내부/외부 인적 네트워크 관리', '정기적인 테스트, 유지보수 업무' 등이 있다.
어떻게 우선순위를 정해야 할까?
제1사분면 : 중요하면서 급한 일(Do)
우선순위를 정하는 데 있어서 가장 기본은 '상대적으로 중요한 가치가 있는 일을 찾는 것'이다. 즉, 투입 시간 대비 성과의 가치(ROI로 표현할 수 있다.)가 높은 일과 그렇지 않은 일을 분리하는 것이 시작이다. 회사에서 하는 일에 덜 중요하고, 덜 급한 일이 어디 있겠냐만은, 그렇다고 모든 업무를 1사분면에 배정할 수는 없다. 1사분면에 배치되는 업무는 지금 당장 처리하지 않으면 큰 이슈가 생길 수 있는 업무다. 따라서 'Do first'라고도 부른다. 2사분면에 놓인 업무들의 시급성을 고려하여 1사분면에 옮기도록 하자.
제2사분면 : 중요하지만, 급하지 않은 일(Schedule)
2사분면에 배치되는 과제는 가장 중요한 일이다. 회사 중장기 전략을 계획하거나, 인적 네트워크를 관리하는 일은 급하지는 않지만, 우리에게 매우 중요하다. 2사분면에 배정되는 과제는 탄력적, 계획적으로 관리해야 한다. 1사분면의 업무가 '지금 당장 처리해야 하는 과제'라면 2사분면의 업무는 '언제까지 어떻게 끝낼지 계획이 필요한 과제'이다.
제3사분면 : 중요하지 않지만, 급한 일(Delegate)
3사분면에 배치되는 과제는 우리의 시간을 갉아먹는 소모적인 업무들이지만, 무시할 수 없는 일이다. 다량의 페이퍼 워크를 해야 하거나, 타 부서에서 업무 협조 요청이 들어오거나 하는 일들은 무시할 수 없다. 3사분면의 일들은 되도록 줄이거나, 담당자에게 위임해야 한다. (모든 일을 본인이 처리하려 하지 말자.)
제4사분면 : 중요하지도, 급하지도 않은 일(Drop)
4사분면은 우리 업무에 전혀 도움이 안 되는 일이다. 돌이켜보면 나도 4사분면의 일을 스스로 만들어 시간을 좀먹는 행동을 가끔 했었다. 이메일이나 채팅으로 끝나는 가벼운 미팅을 굳이 회의실에서 한다던가, 쓸데없이 업무 노션을 예쁘게 꾸며본다던가, 협업 도구를 이것저것 옮겨 보며 리소스를 낭비하는 행위가 4사분면에 해당한다. 4사분면의 일이 아예 없을 수는 없다. 돌이켜보니 필요하지 않은 일이었을 수도 있다. 그러니 업무가 끝난 뒤에는 충분한 회고 기간을 갖자.
'일이 잘 되는 시간'을 찾자
<이미지= pixabay>사람마다 유독 업무에 몰입이 잘 되는 시간이 있다. 필자의 경우에는 새벽 1-2시, 5-6시가 가장 몰입이 잘되는 시간이다. 보통 몰입이 잘되는 시간에는 급하지 않지만, 중요한 업무에 집중하는 게 좋다. 사업계획서를 작성한다던가, 책을 집필한다던가, 중요하지만 급하지 않아서 미뤄왔던 일을 하는 것이다.
급한 일을 처리하는 시간과 중요한 일을 처리하는 시간을 구분하지 않으면 급한 일만 처리하느라 중요한 일이 오히려 후순위로 계속 밀려나는 기형적인 현상이 발생한다. 일이 잘되는 시간을 찾고 그 시간에는 온전히 한 가지 중요한 일에 집중하면 놀라운 성과를 발휘할 수 있다.
모스코우(MoSCoW) 모델
모스코우 모델('모스크바 모델'이라고도 함)은 애자일 프로덕트 관리기법에서 백로그에서 상대적으로 중요한 것과 덜 중요한 것을 구별하고, 한정된 리소스 내에서 우선순위를 정하는 방법론 모델이다. 필자는 프로덕트 관리기법을 예시로 들었지만, 모스코우 모델은 아이젠하워 매트릭스처럼 일상 속 루티너리한 행위에도 적용할 수도 있다. (브런치 아티클 작성하기, 체력 단련하기 등..)
직접 모스코우 모델을 적용해본 필자의 경험에 의하면, 모스코우의 가장 강력한 장점은 feature 단위로 우선순위를 분리하면 정말 직관적으로 확인할 수 있다는 점이다. 그러나, 개발 일정이나 세부적인 마일스톤을 연계하기는 어려워 초기 창업팀이나 린 프로덕트 개발에 적용하기 용이한 것 같다고 생각했다.
모스코우 모델어떻게 우선순위를 정해야 할까?
Must Have : 프로젝트를 완료하기 위해 반드시 해야 하는 가장 중요한 일
머스트 해브는 제품/서비스의 킬러 피처(Killer Feature), 반드시 검토되어야 할 이슈(서비스 정책/법적 규제 등)들을 말한다. 이것이 고려되지 않는다면 출시가 불가능할 정도로 치명적이기 때문에 가장 최우선으로 고려되어야 한다. 예컨대, 인스타그램의 킬러 피쳐는 사용자 간의 팔로우/팔로잉 기능이다. 만약 인스타그램이 이 기능을 빼고 배포한다면 우리가 알고 있는 인스타그램이라 할 수 있을까? 그런 기능들이 '머스트 해브'에 배치되어야 한다. 머스트 해브는 대체가 불가능하거나, 대체할 방법이 마땅히 없는 일들을 말한다.
Should Have : 필수는 아니지만, 중요도를 고려해야 하는 일
슈드 해브는 이 일을 했을 때 분명히 제품/서비스에 가치가 있지만, 반드시 고려하지는 않아도 되는 일을 말한다. 위에 인스타그램을 예시로 들었으니 한 번 더 예시를 들자면, 인스타그램의 해시태그 기능은 있으면 분명히 좋은 기능은 맞지만, 없다고 해서 불편할 정도라고 보기는 어렵다. 유지보수, 기능 개선 건들이 보통 슈드 해브의 항목에 위치한다. 그러나, 슈드 해브라고 해서 방치해둔다면 기술 부채가 쌓여 안 좋은 결과를 초래할 수도 있다.
Could Have : 안 해도 되지만, 하면 좋은 일
쿠드 해브는 흔히 Nice-to-Have 로도 부르는데, 말 그대로 '하면 좋은 일'이다. 여기서 헷갈리는 건 ''슈드 해브'와 '쿠드 해브'를 어떻게 나눌 것인가?'이다. 둘 다 '하면 좋은 일'로 해석할 수 있는데, 여기서는 '이 요구사항이 유저에게 어떤 가치를 제공할 수 있는가'로 나눌 수 있다. 즉, 이 과제를 수행했을 때 사용자에게 표면적으로나 결과적으로 좋은 영향을 줄 수 있다면? 혹은 개선을 해서 작업 효율을 2배, 3배 증가시킬 수 있다면? '슈드 해브'가 되는 게 맞다. 그러나, '버튼의 UI가 조금 달라진다'던가 이 정도의 레벨은 쿠드 해브가 되어야 맞다.
Won't Have : 굳이 할 필요가 없는 가치가 없는 일
원트 해브는 마치 해서는 안 되는 일처럼 느껴지지만, 그렇지 않다. 우선순위의 최후방에 놓여 있을 뿐 언젠가는 해야 하는 일, 그러나 당장 하지 않더라도 큰 손실은 없는 일이다. 안타까운 건 원트 해브도 어찌 되었건 하면 나쁠 것은 없지만, 중요도에서 밀려 결국 안 하게 될 가능성이 크다. 그러나, 원트 해브에도 밸류가 높은 일이 더러 있을 수 있다. 매번 리스트업을 새로 하면서 이 일이 과연 원트 해브에 위치할 정도로 낮은 밸류인지를 검토해보아야 한다. 이번 출시(release)에 포함하지 않는다는 것이지, 영원히 검토하지 않겠다는 뜻이 아니니까.
HIPPO를 경계하라
<이미지= corporate-rebels>2014년, Amazon의 최고 경영자인 Jeff Bezos는 시애틀에서 'Fire Phone'이라는 아마존의 모바일 디바이스를 출시한다. 약 4년 간 수많은 메이커스들이 투입되어 분골쇄신하며 프로젝트에 매달렸지만, 결국 Fire Phone은 Amazon에 커다란 실패를 안겨주고 말았다. 이에 언론사는 왜 Fire Phone이 실패할 수밖에 없었는지 해당 프로젝트를 담당했었던 직원들을 찾아가 인터뷰를 했었는데, 아래와 같은 의견을 냈다고 한다.
“We poured surreal amounts of money into it, yet we all thought it had no value for the customer, which was the biggest irony. Whenever anyone asked why we were doing this, the answer was, ‘Because Jeff wants it.’ No one thought the feature justified the cost to the project. No one. Absolutely no one.”
"우리는 그것에 엄청난 돈을 쏟아부었지만, 아이러니하게도 그것이 고객에게 어떠한 가치도 줄 수 없다고 생각했습니다. 누군가 우리에게 왜 그런 식으로 만드냐고 물어봤을 때 우리는 항상 '제프가 원하기 때문'이라고 대답할 수밖에 없었습니다. 아무도 Fire Phone의 기능이 그 엄청난 비용을 정당화할 수 없다고 생각했습니다. 절대로요."
Amazon의 Fire Phone 사례는 우리가 회사 생활을 하며 한 번쯤은 경험해보았을 정도로 흔하다. 우선순위를 정하거나, 필요 없는 일(혹은 기능)을 드랍할 때 걸림돌 중 하나는 상급자의 opinion이다. 이게 왜 중요한지, 이 기능은 왜 필요 없는지 실무자들은 알고 있다. 그러나, 직위를 이용해 막무가내식으로 밀어붙이며 사업의 명운을 위태롭게 하는 고집이 많은 상사들도 있다.
프로젝트가 올바른 방향으로 가기 위해서는 우선 'HIPPO'를 경계해야 한다고 한다. 여기서 말하는 HIPPO는 우리가 흔히 알고 있는 동물 '하마(Hippo)'를 말하는 것이 아니라, '가장 돈을 많이 받는 사람의 의견(The highest paid person's opinion)'을 말한다.
즉, 이 사람이 직급이 높다고, 가장 월급을 많이 받는다고 의사결정에서 절대적인 역할을 해서는 안된다는 말이다. 모든 결정은 사실과 데이터에 기반해야 하며, 만약 상사가 사실과 다른 이야기를 하고 있다면 잘못된 결정이 될 수 있음을 반드시 이야기해야 한다. 우리의 성공은 상급자가 아니라 우리 팀 전체에게 달려있다.
위에서 이야기한 아이젠하워 매트릭스, 모스코우 기법 외에도 라이스(등급 점수 모델을 사용해 점수별로 업무 우선순위 설정 방법), 카노 모델(사용자 목소리 및 고객 만족도 기반의 우선순위 설정 방법) 등이 있다. 우리 조직에 어떤 모델이 적절한 지 합의에 따라 사용하면 된다.
같이 보면 좋아요
The Inside Story Of Jeff Bezos’s Fire Phone Debacle
THE HIGHEST PAID PERSON’S OPINION
Product Plan: RICE Scoring Model
루트비히 비트겐슈타인은 말했습니다.
"나의 언어의 한계가 나의 세계의 한계다"
브런치를 통해 지식의 지평을 넓혀가고 있습니다.
오늘도 방문해주셔서 감사합니다.
2022. 12. 06. 채드윅.
