PM에게는 WBS와 Backlog가 있다
전문가들 사이에서 PM이 가진 초라한 그러나 궁극적인 무기(?)
같은 매니저여도 프로젝트와 프로덕트는 다르다. 그러나....
서비스 기획과 PM에 대한 수요가 늘어나며, 둘의 차이는 무엇인가? 에 대한 글과 분석이 많다. 정확히는 UX/UI 기획자와 서비스 기획의 역할 범위, 서비스 기획과 프로젝트 매니저, 프로젝트 매니저와 프로덕트 매니저, 더 나아가 프로덕트 매니저와 프로덕트 오너의 차이까지....
그중에서도 줄임말로 똑같이 PM이라고 부르는 프로젝트 매니저와 프로덕트 매니저의 차이는 상당하다고 생각한다. 일이 생겨나는 배경, 최종적으로 내놓아야 하는 산출물, 달성해야 하는 목표의 성질, 관리하는 대상과 범위가 다르다. 애초에 프로젝트랑 프로덕트는 같은 층위에서 비교할 수 있는 성질이 아니니까.
그럼에도 둘 사이에 하나의 공통점이 있다면 그건 바로 '그래서 무엇을 해야 하는가?'에 대한 고민이 라고 생각한다.
프로젝트
: 특정 목표를 달성하기 위해 + 거래처 또는 상대방과 약속한 기간과 비용 내에서 + 필요한 일을 한다
프로덕트
: 프로덕트의 목표를 달성하기 위해 + 고객에 대해 학습하고 가설을 검증하기 위해 + 필요한(우선순위가 높은) 일을 한다
프로젝트 관리자와 프로덕트 관리자의 일은 매우 다르다. 그러나 결국 관리자의 고민은 똑같다. 목표를 완수하기 위해 구체적으로 어떤 일 task을 해야 하는가>프로젝트 매니저에게는 WBS가 있다
잘 설계된 프로젝트라면 프로젝트의 목표와 산출물, 그리고 이를 달성하기 위해 활용 가능한 비용과 예산, 인력이 명확히 구성되어 있다. 이때에 프로젝트 관리자는 이러한 자원을 이슈 없이 관리하며 목표를 달성하기 위한 일들을 담당하게 된다.
1) 프로젝트의 목표를 달성하기 위해 해야 할 일은 무엇인가?
2) 목표로 한 결과물을 품질 이상 없이 만들어낼 수 있는가?
3) 이 일을 달성하는데 필요한 인력 구성과 예산은 얼마나 되는가?
4) 일의 순서나 흐름에는 이슈가 없는가?
▶ 각 담당자가 자신의 일을 약속한 일정 내에서 약속한 품질만큼 제대로 산출하는가?
그리고 이를 한눈에 보일 수 있게 작성하고 관리하는 양식이 바로 WBS, Work Breakdown Sheet다.
WBS의 예시. 기간 내에 누가 어떤 일을 언제까지 할 것인가?를 빠짐없이 구성한다.WBS의 양식 및 관리에 대해서는 이미 시중에 많은 자료와 아티클이 있지만, 간략히 정리하자면 아래와 같다.
1) 목표 결과물을 내놓기 위해 필요한 업무를 "빠짐없이" 나열한다
2) 각 업무의 담당자를 지정한다
3) 각 업무와 업무 사이에 흐름이 있는 경우, 각 업무의 순서와 목표 일정을 설정, 조율한다
프로덕트 매니저에게는 Backlog가 있다
프로젝트 매니저의 업무가 중장기 기간 동안 여러 인력이 약속한 일정 내에 목표한 결과물을 이슈 없이 산출하게 하는 데에 방점이 있다면, 프로덕트 매니저의 업무는 이와 다르다.
물론 프로덕트 팀에서 필요에 따라 일정 기간 이상 지속되는 프로젝트 단위로 일을 진행할 수도 있지만, 프로젝트는 어디까지나 일의 단위 또는 방식의 하나다. 반면 프로덕트 팀은 조직과 팀의 목표를 달성하기 위해, 제품의 성장과 고객 학습을 담당한다. 그래서 평소의 중요 요소는 어떤 지표를 성장시키기 위해, 어떤 가설을 바탕으로, 어떤 일을 할 것인가? 다.
이러한 아이디어를 모아 두고 우선순위를 정리해둔 목록이 Backlog다.
Backlog의 예시. 목표와 가설, 우선순위를 매긴 점수인 I.C.E. 그리고 가설의 성공을 증명할 수 있는 기준과, 실험 방안, 실험을 통해 배운 점 등을 작성한다.백로그도 팀마다, 조직마다 세부 양식은 당연히 다를 테다. 그러나 두루 살펴본 결과, 공통되는 요소는 결국 가설과 검증에 관한 내용들이다.
1) 어떤 목표를 달성하기 위한 아이디어인가?
2) 어떤 가설을 가진 아이디어인가? 이 아이디어로 검증하고자 하는 건 무엇인가?
3) 무엇부터 할 것인가? (우선순위는 어떠한가?)
4) 이 실험이 성공 또는 실패했다고 알아볼 수 있는 기준이 되는 지표는 무엇인가?
5) 이를 구체적으로 어떤 방식으로 진행할 것인가?
6) 성공 또는 실패를 통해 배운 점은 무엇인가?
이 목록을 바탕으로 프로덕트 매니저는
1) 진행 중인 업무에 대해서는 스크럼 scrum을 통해 상황을 공유하고 + 이슈가 발생 시 논의, 조율한다
2) 진행이 완료된 업무는 결과를 분석하여 공유하고, 이를 학습점 lesson-learned으로 삼아 다음 업무에 참고한다
3) 진행하지 않은 업무는, 다음에 이어서 할 업무는 무엇일지 정리하거나 조율한다
전문가의 세계에서 살아남는 PM의 무기
이러나저러나 PM은 구체적인 결과물을 직접 만들어내는 역할이 아니다. 아무리 필요에 따라 배우거나 연습해도, 파트너인 디자이너와 개발자의 실력에 닿을 수 없다. 아니, 실은 그럴 필요도 없다. 어쨌거나 PM의 역할은 조직과 팀이 목표를 달성하는데 필요한 일을 결정하고, 그것이 구체화되는 전반 과정을 서포트하는 역할이니까.
결국 PM이 가진 무기는, 특정 목표를 달성하거나 문제를 해결하기 위해 필요하다고 판단한 과업의 목록인 WBS 또는 Backlog가 전부다. 그리고 이건 단순히 문서 혹은 프레임워크가 아니라, 이 문서를 작성하고 공유 및 설득할 수 있을 만큼 제품과 업무의 흐름을 이해하고, 우선순위를 판단할 만큼 고객과 환경을 이해하고 나서야 만들 수 있는, 제품과 고객에 대한 논리와 이해의 집합체다.
개발자에게 개발 언어가 있고, 디자이너에게 레퍼런스가 있다면, pm에겐 WBS와 Backlog가 있는 것이다. 비록 그것이 겉보기엔 화려해보지 않아도, 팀과 프로젝트의 시작과 끝은 여기에 달려 있으니까.
제너럴리스트인 PM이 가진 무기라고는 어쩌면 문서 몇 장에 담긴 WBS와 Backlog가 전부일지도 모른다. 그러나 거기에 팀과 프로젝트의 시작이자 끝이 달려 있다.
