우선순위, 그래서 PM이 어떻게 설정하라는 건데?
PM이 꼭 알아야 할, 우선순위 설정 기본 개념 잡기
우선순위 설정 작업은 PM의 존재 이유라 할 수 있을 정도로 중요하다
PM은 정말 다양한 일을 한다. 제품 전략부터 커뮤니케이션, 예산을 따오거나, 팀 관리를 하거나 데이터 분석까지. 개발과 디자인 빼고 안 하는 일이 뭐냐고 물어보는게 더 빠를 정도다. 그래서 IT업계가 아닌 지인들한테 Product Manager가 무슨 일을 하는지 설명하는 데 종종 애를 먹을 정도다.
그럼에도 불구하고, PM이 하는 모든 일들을 관통하는 하나의 키워드가 있는데, 그것은 바로 우선순위를 설정하는 작업이다. 우선순위 설정 작업은 PM의 존재 이유라 할 정도로 매우 중요하다. 저 PM이 우선순위를 어떻게 설정하는지에 따라 좋은 PM과 나쁜 PM을 구분할 수 있을 정도다.
업무들 간 우선순위가 제대로 설정되어 있지 않을 때의 전형적인 패턴은 팀이 산으로 가는 것이다. 개발자/디자이너는 끊임없이 바쁜데, 눈에 보이는 성과는 요원하기만 하다. 분명 요청사항들은 다 해결해주고 있는데, 돌이켜보면 남는 것은 없다. 이는 중요한 일과 중요하지 않은 일들을 구분하지 못해, 눈 앞에 보이는 일들을 기계적으로 쳐내고 있었다는 의미이다.
일반적인 회사라면 개발 리소스는 항상 부족하다.(그렇지 않은 회사는 위험하다) 그렇기 때문에 한정적인 개발 리소스를 가장 효과적으로 사용하여 큰 효과를 낼 수 있도록, 그 많은 일들 중 "좋은 일"들을 선택하여 선별적으로 처리하는 것이 필요하다. 이렇듯 수많은 일들 속에서 우리 팀이 해야 할 일들을 선별하는 작업이 바로 우선순위 설정 작업이라 할 수 있다.
우선순위 설정에 마법같은 공식 따위는 없다
대개 제품팀 내에서의 최종 의사결정은 Product Manager(또는 Product Owner)가 담당한다. PM은 매일 팀 내에서 수많은 고민들과 업무 리스트들을 마주하며, 때로는 제품 전략에 따라 새로운 업무들이 만들어지고는 한다. 다시 말해 PM의 일상은 끊임 없는 의사결정 순간들의 연속이다. 그리고 대개 PM이 내리는 의사결정은, 우리 팀이 어떤 작업을 어떤 순서로 해야 하는지에 대한 우선순위를 설정하는 작업이다.
그러나 이런 우선순위 설정 작업은 초보 PM들이 가장 어려워하는 부분(필자를 포함) 중 하나이기도 한데, 애석하게도 이런 우선순위 설정 스킬은 가장 습득하기가 어려운 부분이기도 하다.
업무의 우선순위는 매우 신중하게 설정되어야 한다. 비단 내 업무 뿐 아니라, 프로덕트/프로젝트 차원에서 어떤 순서로 일을 해야 할지, 어떤 일을 하고 어떤 일을 하지 말아야할지가 팀원들 및 유관 부서와 명확하게 보여지고, 공감될 수 있어야 하기 때문이다. 애매모호하고 설득되지 않는 우선순위의 경우 업무를 추진하는 데에 있어 많은 도전을 받게 되고, 심각할 경우 PM으로써의 신뢰까지 잃어버리는 계기가 되기 때문이다.
필자 역시 PO로써 처음 업무를 수행할 때 이러한 우선순위 설정 작업에 애를 먹곤 했다.(사실 지금도 꽤 많이 어렵다) 항상 시니어PO로부터 "우선순위를 왜 이렇게 설정했느냐?"라는 근거를 요구받기도 했고, 메이커들로부터 필자가 설정한 우선순위에 대한 공격을 받기도 했다. 당연히 더 잘하고 싶은 욕심에 다른 팀, 그리고 내로라 하는 빅테크 기업들에서 우선순위를 어떻게 설정하는지에 대한 내용들을 열심히 찾아보고 공부하기도 했다. 나름의 인사이트는 있었지만, 정작 그렇다고 해서 당시 필자의 업무에 큰 도움이 되었던 것은 아니다. 왜냐면 우선순위 설정에 마법같은 공식 따위는 없기 때문이다. (물론 공부했던 내용들은 지금 와서 돌아보면 큰 도움이 되긴 했다)
이는 우선순위 설정 자체가 하나의 스킬이라기보다는, 여러 인사이트와 경험들이 합쳐진 하나의 종합예술과 같기 때문이다. 바로 이러한 속성 때문에 많은 기업들의 채용에서 PM직무가 신입보다는 경력을 더 선호하는 이유가 되기도 한다.
우선순위 설정의 기본은 업무의 속성을 파악하는 것
위에서 우선순위 설정에 마법같은 공식 따위는 없다고 이야기한 바 있다. 그럼에도 불구하고 우선순위 설정을 도와주는 몇 가지의 개념들은 있는데, 이들을 간략히 살펴보도록 하자.
먼저 우선순위에 대한 기본 개념부터 살펴보자. 기본적으로 제품/업무에 있어서 우선순위를 설정하는 가장 큰 이유는 자원(대개 메이커 팀의 리소스)이 한정되어 있기 때문이다. 예를 들어 해야 하는 일이 100가지가 있는데, 우리 팀은 1달 동안 10개 정도의 일밖에 할 수 없다고 하자. 그러면 당연히 1달 동안 할 수 있는 10가지 일과, 할 수 없는 90가지 일이 생기게 된다. 그렇다면 여기에서, 이번 달에 해야 할 10가지 일과 그렇지 않은 90가지 일은 어떤 근거를 가지고 구분해야 할까? 이번 달이 끝난 후, 다음 달에는 또 어떤 근거로 해야 할 10가지 일을 선정할 수 있을까?
우선순위 설정의 가장 기본은 해당 업무의 속성을 파악하는 것이다. PM이라면 새로운 '일'을 마주했을 때 기본적으로 다음과 같이 생각해야 한다. 과연 이 일이 충분히 중요한 일인가? 다른 일보다 먼저 해야 하는 가치가 있는가? 얼마나 빨리 쳐리해야 하는가? 이 일을 끝냈을 때 얻을 수 있는 효과는 충분히 큰가? 이 일이 다른 일에 영향을 주는가? 팀원들은 이에 대해 어떻게 생각하는가?
당연히 여기에서 꼬리 질문이 생긴다. '아니 그래서 업무의 속성은 어떻게 파악하나요?'와 같은 것들이다. 정답부터 먼저 말하자면 '그 때 그 때 다르다'이다. 언뜻 보면 굉장히 무책임하게 들릴 수 있지만 실제로 그렇다. 그것은 업무가 어떤 업무이냐에 다라 업무의 속성 역시 달라지기 때문이다.
예를 들어 다음과 같은 업무들이 있다고 해보자. 아래는 모두 제품 및 기능이 변경되는 경우이다.
업무A: 제품 가치 창출을 위한 신규 기능개발 검토
업무B: 고객 불만 사항 처리를 위한 신규 기능 개발 검토
업무C: 새로운 정부 규제에 맞춘 기능 변경 검토
업무A는 새로운 가치를 창출하는 일이다. 이 일이 얼마나 중요하냐 물어보면, 추가하려는 기능이 우리 제품 전략, 고객의 방향과 얼마나 맞는지, 얼마나 큰 효과를 주는지, 개발 비용은 얼마나 되는지 등이 우선적으로 고려되어야 할 것이다.
업무B는 인입된 고객 불만 사항을 처리하는 일이다. 모든 고객 불만 사항을 다 처리할 것인가? 그렇다면 좋겠지만 현실적으로 그럴 수는 없다. 앞서 얘기했듯 개발 리소스가 한정되어 있기 때문이다. 심지어 고객1과 고객2의 의견이 서로 상반되어, 둘 모두를 만족시킬 수 있는 기능 추가가 불가능한 경우도 있다. 이런 경우 고객 불만이 얼마나 잦은 빈도로 발생하는지, 고객 불만이 얼마나 큰지, 기능 개선에 얼마나 시간이 걸리는지 등이 주로 고려되어야 할 것이다.
업무C는 정부 규제로, 흔히 컴플라이언스(compliance) 이슈라 불리는 것들이다. 현재의 상황과 관계 없이 무조건 해야만 하는 일이다. (어떻게 보면 PM 입장에서 제일 속 편한 케이스이기도 하다) 이럴 경우 정부 규제에 맞춘 기능의 개발 일정을 산출한 다음, 규제 일정에 맞추어 우선순위를 최상위로 올려야 한다.
이렇듯 우선순위를 설정하는 기준은 업무의 속성에 따라 달라진다. 때문에 PM이라면 업무를 맞닥뜨렸을 때 이 업무가 어떤 속성의 업무인지를 빠르게 파악하는 능력이 중요하다고 할 수 있겠다.
당연하지만 현실에서는 위 3가지 케이스 말고도 수많은 케이스로 업무를 분류할 수 있다. 모든 업무 분류에 맞추어 우선순위 기준을 열거하는 것은 가능하지도 않을 뿐더러 멍청한 일이다. 때문에 좋은 PM이라면 업무 분류 자체에 집착하지 않고, 업무가 어떤 속성을 가지는지, 즉 본질 자체를 파악하는 능력 자체를 기르는 것이 중요하다고 할 수 있겠다.
업무의 본질 자체를 파악하는 능력을 기르는 것은 중요하다. 하지만 능력 자체를 가르치는 것은 불가능하다. 이는 이것이 기술이 아니라 일종의 통찰력이기 때문이다. 따라서 스킬 자체에 집착하는 것보다는, 매일 일상에서 수많은 업무를 마주하고, 다른 사례를 참고해보고, 인문학적 지식을 넓혀가며 내재화하는 것이 중요하다.
일반적으로 PM은 평생에 거쳐 위 능력을 개발해간다.
이와 같이 일의 속성을 파악하는 것은 신입PM이 가장 어려워하는 부분이기도 하다. 하지만 의식적으로 위와 같이 생각해나가다 보면 점차 일과 업무의 속성을 파악하게 되는 '짬'이 생기게 되고, 나중에는 새로운 일을 마주하자마자 위 속성들부터 먼저 생각하게 된다.
우선순위 파악에 도움을 주는 기본 개념들
그럼에도, 우선순위 파악에 도움을 주는 기본 개념들은 있다. 아래는 대표적으로 통용되는 우선순위 판단의 근거가 되는 속성들로, 빠르게 일의 속성을 파악하는데 도움을 받을 수 있다.
1. 중요도/효과성
중요도/효과성은 이 일이 얼마나 중요한지, 그리고 팀/회사/고객에게 어느 정도의 Business Impact을 가져다 줄 수 있는지를 나타낸다. 경우에 따라 중요도/효과성의 기준은 매출일 수도 있고, 비용 절감일 수도 있다. 또는 고객 만족도일 수도 있고, 심지어는 팀 내의 소소한 즐거움(사기 증진)이 목적일 수도 있다.
즉, 아래와 같은 것들이다.
이 기능 개선의 결과물이 충분히 큰 고객에게 영향을 주는지? 특정 집단에만 영향을 주는지, 아니면 고객 전반에 거쳐 영향을 주는 기능인지?
버그나 오류의 경우, 이 버그/오류로 인해 얼마나 많은 고객들이 불편을 호소하고 있는지? 버그/오류의 발생 빈도는 어떠한지? 특정 한두 명만 호소하는 오류가 아닌지? 그 버그/오류로 인해 기능 오작동이 발생했을 경우, 단순 불편에 그치는지 아니면 고객 이탈과 같은 치명적인 피해로 돌아오는지?
2. 시급성
시급성은 말 그대로 얼마나 이 업무가 빠르게 처리되어야 하는지를 나타낸다.
대개 치명적인 버그/오류의 경우 빠르게 해결되어야 하므로 시급성이 높다. 반대로 고객이 불편을 호소하지만, 고객 이탈/매출 감소로 이어질 가능성이 낮은 단순 불편사항인 경우 빠르게 그 오류를 해결해야 할 시급성은 낮을 것이다.
시급성의 개념은 상대적이다. 업무A가 충분히 중요하고 빠르게 처리해야 함에도 불구하고, 지금 보았을 때 더 중요하고 더 빠르게 해야하는 업무B가 있다면 당연히 업무B의 시급성이 업무A보다 높을 것이다.
크리스마스 연휴에 대박을 칠 만한 아이템이 있다. 그러나 지금은 6월이라고 해보자. 기능 개발에 3주 정도가 소요된다고 했을 때, 지금 시점에서는 굳이 해야 할 필요는 없으므로 시급성이 매우 낮을 것이다. 그러나 10월, 11월이 되었을 때 우선순위를 다시 산정할 때는 시급성이 매우 높을 것이다. 따라서 PM은 시기에 맞추어 우선순위를 재산정할 필요도 있다.
시급성 차원에서 치트키같은 존재가 있다. 바로 컴플라이언스 이슈다. 법 규제, 개인정보 보호 정책 등이다. 이들은 대개 시급히 처리되어야 하거나, 해결해야 할 기한이 정해져 있는 경우가 많다. 급작스럽게 컴플라이언스 이슈가 발견되었다면 다른 모든 우선순위를 후순위로 미루고 최상위로 올려야 하는 경우가 많다.
3. 소요 리소스(비용, 개발 기간 등)
PM 입장에서 소요 리소스는 대개 이 기능을 개발하는 데에 얼마나 많은 메이커 인력이 투입되어야 하는지를 나타낸다. 하지만 꼭 인력 뿐 아니라 회사의 자본 등도 같은 개념으로 분석할 수 있다.
업무A의 효과성도 크고, 시급성도 높다고 해보자. 즉 업무A는 해낸다면 팀에 명백히 좋은 일이다. 하지만 업무A는 구현하는 데에 있어 최소 1년 이상의 시간이 걸리는, 매우 어려운 작업이라 한다면 우선순위를 높이는 데에 있어 조심해야 할 것이다. 왜냐하면 업무A를 함으로써 다른 업무들을 하지 못하게 될 가능성이 매우 높기 때문이다.
때문에 소요 리소스가 작은 일들은 우선순위를 높이는 데에 유리하다. 구현 난이도도 쉬운데, 효과성이 크다면? 하지 않아야 할 이유가 없다.
4. 상위 전략과의 Alignment
우선순위 설정에 있어 각 요소들 간의 비교 분석이 어려운 경우가 종종 발생한다. 예컨대 A과제는 시급하게 해야 하지만 그 효과성은 다소 떨어지고, B과제는 효과성은 크지만 시급히 하지는 않아도 되는 일이다. 즉, 시급성과 효과성(중요도)를 어떻게 판단해야 하는지에 대한 내용인데, 여기까지 읽은 사람이라면 알겠지만 딱 잘라 이게 정답이다라고 할 수는 없다. 어떠한 경우에는 효과성이, 어떠한 경우에는 시급도가 더 중요하게 작용할 수 있기 때문이다. 이렇게 각 요소들이 충돌하거나, 판단이 힘든 경우에는 대개 상위 전략과의 Alignment를 고려해야 한다.
위 3가지는 대표적인 우선순위 산정의 근거가 되는 속성들이다. 당연하지만 회사와 제품, 팀에 따라 다른 속성들이 존재할 수 있다. 때문에 기본적으로 여러 업무를 접해보면서 내 업무에 맞는 속성이 무엇인지를 찾아가는 것이 중요하다고 할 수 있겠다.
우선순위 설정 프레임워크: MoSCoW
위와 같은 업무의 속성을 잘 파악했다면 우선순위 설정에 더 명확한 근거를 가지게 된다. 우선순위를 최종적으로 결정하는 데 도움을 주는 몇 가지 프레임워크가 있는데, 그 중에 가장 범용적으로 사용되는 MoSCoW 프레임워크를 소개하도록 하겠다.
(TMI: Moscow는 모스크바의 영문 표현이다. 이를 기억하면 외우기 쉽다.)
MoSCoW 프레임워크는 업무 속성을 기반으로 다음과 같이 우선순위를 최종 결정할 것을 권장한다.
- Must have
반드시 해야만 하는 업무이다. 제품이나 팀에 가장 필요한 업무이며, 개선 효과에 대해 논쟁의 여지가 없다.
- Should have
중요한 업무이지만 필수적으로 해야만 하는 일은 아니다. 그러나 이 업무를 했을 때 제품 및 팀에 중요한 개선 효과가 있을 것으로 예상되는 업무이다. 일반적으로 중요하지만, Must have보다는 중요도와 시급성이 낮은 업무를 의미한다.
- Could have
있으면 좋지만, 굳이 꼭 필요하지는 않은 업무이다. 어느 정도의 개선 효과는 있겠지만, 이것이 비즈니스 차원의 효과로 이어지기에는 미미한 경우이다. 예컨대 특정 한두 명의 고객은 만족시킬 수 있겠지만, 이것이 매출/고객 수 등의 효과로 이어진다고 보기에는 힘든 경우이다.
- Won't have
있으면 좋을 것 같기도 하지만, 그 효과 자체가 의심되거나 효과가 매우 미미할 것으로 예상되는 경우이다.
일반적으로 팀의 업무는 대개 Must have와 Should have를 위주로 결정된다. Could have의 경우 팀의 리소스가 많이 남는 상황이 아니면 하는 일은 많이 없지만, 비용이 크지 않다면 Must have나 Should have 급의 업무를 처리할 때 같이 끼워넣어 처리하기도 한다. Won't have의 경우 실질적으로 업무를 하는 경우는 거의 없다.
주의해야할 점은 모든 것은 비즈니스 환경에 맞추어 변화한다는 점이다. 최초에는 Could have급의 우선순위를 지닌 업무였지만 환경이 변화함에 따라 이것이 Must have로 옮겨갈 수도 있다. 물론 그 반대의 경우도 마찬가지.
우선순위 설정에서 조심해야 할 안티 패턴
우선순위를 판단하겠답시고 중요도, 시급성 등을 계량화하여 기계적으로 적용하는 어리석은 행위는 하지 않길 바란다. 이는 가능하지도 않을 뿐더러 대개 그 결과도 나쁘기 때문이다.
가령, 영향받는 고객의 수가 1000명 이상이면 중요도 10점, 5000명 이상이면 50점 등과 같은 것이나, 1달 이내에 처리되어야 하는 것이면 시급성이 50점, 6달 내라면 10점 등을 점수로 매겨, 총점 80점 이상이면 Must have, 60점 이상이면 Should have와 같이 넣는 식이다.
물론 이런 식으로 업무 속성의 판단 기준을 접근하는 것은 권장할 만 하지만, 우선순위는 이와 같이 기계적인 점수로 판단되어야 하는 것은 아니다. 즉 위처럼 접근했을 때 업무A의 총점이 90점, 업무B의 총점이 80점이라 해서 업무A가 업무B보다 꼭 더 우선해야 하는 것은 아니다.(대관절 총점의 합계 기준을 정하는 것부터가 굉장히 어렵고 공감을 받지 못할 가능성이 크다)
우선순위는 업무의 속성과 팀/제품/비즈니스의 맥락을 종합적으로 고려해서 설정되어야 하기 때문이다. 즉 위와 같은 접근법은 중요한 '참고'는 될 수 있을지언정 기계적으로 우선순위를 정해서는 안된다. 심지어 명확한 근거는 없을 지언정, PM이나 팀의 훌륭한 직관에 의해서 특정 업무의 우선순위를 최상위로 올릴 수도 있다.
우선순위는 설득과 공감의 기술이다
당연한 얘기지만 우선순위는 명확한 근거를 가지고 설정될 수록 좋다. 그러나 때에 따라 근거가 명확하지 않더라도 우선순위를 최상위로 올릴 수도 있다. 그것은 관계자 모두가 해당 업무의 우선순위에 대해 충분히 설득과 공감이 되었을 경우이다. 즉, 누가 보더라도 이 업무는 중요하고 시급하다는 공감대가 있다면, 굳이 복잡한 우선순위 설정 작업을 할 필요가 없다. 오히려 당연히 해야 할 업무를 하기도 전에, 우선순위를 설정하느라 시간과 비용을 뺏기는 결과가 될 수 있다.(물론 이러한 경우 우선순위의 근거가 없다기보다는, '굳이' 근거를 가지고 설득하는 작업을 생략한다는 의미가 더 맞을 것이다)
여기서 우선순위 설정 작업의 가장 큰 본질이 드러난다. 즉 우선순위를 설정하는 것은 작업 순서에 있어 협업하는 사람들을 설득 및 공감시키는 작업과 같다는 것이다.
내가 아무리 멋들어진 프레임워크와 기준에 따라 열심히 노력하여, 긴 문서를 만들어 우선순위를 설정하여도, 그것이 팀에 공감대를 얻지 못한다면 그 우선순위는 나쁜 우선순위가 된다. 반면 훌륭한 직관에 의한 판단이 있다면 간단한 배경 설명만으로 우선순위 설정이 가능할 것이다. 즉 우선순위 설정 근거가 공격받는 것은, 내가 설정한 우선순위의 근거가 팀의 공감을 얻지 못했다는 뜻이다.
이어져서 우선순위 설정의 근거를 작성하는 작업은 설득의 대상과 범위에 따라 달라지기도 한다. 매일 스크럼을 같이 하며 배경이 충분히 공유되고 있는 상태에서의 작업이라면, 위와 같이 간단한 배경 설명만으로 우선순위를 설정하여도 큰 이견이 없을 것이다. 그러나 다른 팀의 업무 협조를 이끌어내야 하거나 전사 차원의 프로젝트를 진행해야 하는 경우 그들은 이 업무에 대한 배경지식이 떨어질 것이므로, 내가 왜 이 업무의 우선순위가 높아야 하는지에 대해 명확한 근거를 가지고 그들과 소통해야 한다.
