PM은 뭐 하는 사람이에요?
'프로젝트 굴렁쇠'입니다.
우선 내가 말하는 쿠팡페이의 PM은 Product Manager가 아닌, Project Manager이다. 그래서 일반적으로 핀테크에서 칭하는 PM과 다를 수 있다. Project Manager는 프로젝트가 계획한 타임라인에 맞춰 런칭되기 위해 관리해야 하는 모든 것(프로젝트 범위/일정/원가 등)을 챙기고, 이슈가 발생하면 이슈 해결을 위해 빠르게 에스컬레이션하고 문제를 해결하는 역할을 수행한다.
다만, PM이 프로젝트의 어디서부터 어디까지 알아야 하며, 어떤 일까지 직접 처리해야 하는지 일하다 보면 가끔 헷갈린다. 그래서 오늘은 내가 생각하는 PM(Project Manager)의 role에 대해 정리해 보려고 한다. 물론 이것은 내 개인적인 생각으로 본인이 속한 조직의 특성 또는 개인의 성향에 따라 다를 수 있다.
Project란?
보통의 프로젝트는 제한된 시간 안에 한정된 자원으로 목표를 완수해야 한다. 고유의 제품, 서비스, 결과물을 만들기 위해 수행하는 일시적인 노력이다.
프로젝트는 고유하고 일시적일 뿐 아니라 다음의 특징을 가진다.
Uniqueness: 있는 것을 또 만들 필요는 없다.
Temporary Endeavor: 끝나지 않은 작업은 프로젝트 대상이 아니다.
Drive Change: 팀/조직 혹은 사회에 변화를 만든다.
Value Creation: 모두가 노력하더라도 가치가 없다면 의미가 없다.
Intiation Context: 많은 좋은 일들 중에서 이 프로젝트가 시작되는 이유가 있다. 규제, 기업/조직 전략, 개선 등의 배경이 있다.
Constraint of scope, cost and time: 범위와 비용, 시간의 제약이 있다.
Progressive Elaboration: 프로젝트는 후반기로 갈수록 프로젝트 위험과 불확실성이 낮아진다.
Project Management란?
지식, 도구 및 기법 등을 통하여 프로젝트 활동들이 요구사항을 달성하게 하는 것이다.
프로젝트 관리자는 보다 효율적으로 프로젝트를 관리하여 프로젝트가 성공적으로 수행될 수 있도록 해야 하며, 프로젝트 시작부터 끝까지의 일정, 자금, 인력 등 전반적인 부분을 관리해야 한다.
프로젝트 관리의 성공 여부를 평가하는 주요 목표는 다음과 같다.
비즈니스 목적의 달성 여부
이해관계자들의 합의 달성 여부
위험에 얼마만큼 잘 대응했는지
제한된 범위/일정/원가를 준수했는지
프로젝트 생애주기
프로젝트 생애주기는 예측형 생애주기(폭포수 모델)와 점증적 개발방식(애자일)으로 나뉘며, 각 생애주기에 맞는 프로젝트 관리 방법론을 적용해야 한다.
예측형 생애주기(예측형 프로젝트 관리)
출처: PMP Agile 바이블- 프로젝트 범위가 명확할 때 예측형 프로젝트 관리 방법론을 적용한다.
- 프로젝트 요구사항을 초기에 정의하고, 프로세스와 산출물 관계를 명확히 하며, 이해관계자에게 산출물을 문서화하여 보고한다.
- 예측된 프로세스에 따라 작업을 관리한다.
- 제조, 건설, 조선, 플랜트, 서비스, IT 등 모든 산업 분야에 적용된다.
점증적 개발방식(적응형 프로젝트 관리)
출처: PMP Agile 바이블- 프로젝트 범위의 변경 가능성과 불확실성이 크고, 창의적인 구현을 필요로 할 때 적응형 프로젝트 관리 방법론을 적용한다.
- 프로젝트 전 단계에 걸쳐 요구사항이 계속 추가되며 개발 단계에서 개발자 중심으로 작업을 진행한다.
- 고객 니즈를 충족시키기 위한 창의적인 구현에 초점을 맞춘다.
- 주로 IT, 연구개발 분야에 적용된다.
PM의 업무에 대해 이야기하기 위해 프로젝트와 프로젝트 관리에 대해 간단히 정리해 봤다. 이제 진짜 PM의 업무에 대해 이야기하려고 하는데, 먼저 많이들 헷갈려 하는 PM과 PO의 차이점에 대해 이야기하려고 한다. Project Manager가 없는 조직에서는 대부분 PM(Product Manager)이 요건 정의부터 프로젝트 범위, 일정, 원가 등 모든 것을 혼자 관리하지만, Project Manager가 있는 조직에는 Product Manager 대신 PO가 있다.
PM과 PO의 차이점
우선 Product Manager와 Product Owner는 불리는 호칭만 다를 뿐, 업무 롤은 거의 일치한다. 다만, 토스와 같이 Product Manager와 Product Owner 모두 있는 조직에서는 PM은 현재 고객 대상의 서비스를 만들고, PO는 잠재 고객 대상의 서비스를 만든다는 차이가 있다. (출처: 토스 시리즈)
*즉, 업무 구분에 대한 정의는 답이 없다. 조직 by 조직
그렇다면 이제 PM(Project Manager)과 PO(Product Owner)의 차이점을 알아보자.
PO는 조직이 추구하는 비즈니스를 기반으로 프로덕트 요건 정의부터 프로덕트가 구현되기 위해 필요한 모든 일련의 프로세스를 수행한다. 그리고 PM은 프로덕트 구현을 위한 프로젝트가 시작됐을 때 투입되며, 프로젝트가 성공적으로 완료(프로덕트의 출시) 될 수 있도록 프로젝트의 시작부터 끝까지 범위, 일정, 원가 등 전반을 관리한다.
- PO : 고객의 불편을 해소하기 위한 최고의 프로덕트를 정의하고 만드는 사람
- PM : PO가 원하는 프로덕트가 구현될 수 있도록 프로젝트 전반을 관리하는 사람
PM, 이것까지 해봤다.
PM은 PO가 정의한 프로덕트 요건에 따라 프로덕트가 구현될 수 있도록 프로젝트 전반을 관리하는 사람이다. 즉, 프로젝트가 제대로 굴러가도록 하기 위한 모든 업무를 처리해야 한다. 보통 각 분야의 전문가에게 업무를 맡기고 모니터링하지만, 일정이 촉박하거나 리소스가 부족한 경우 등 때에 따라 어떤 업무라도 직접 해야 할 수 있다.
나는 하나의 프로젝트 안에서 이런 것까지 해봤다.
① 외부 솔루션 구매를 위해 여러 후보 업체들의 영업 담당자와 컨택하고 견적을 받았다. 이후 구매팀과 함께 계약서 및 SLA를 작성하고, 선정된 공급업체와 최종 금액 협상을 진행했다.
→ 원래라면 BM팀에서 진행해야 하는 일인데, 일정이 촉박해서 직접 진행했다. 중간에 BM팀의 도움을 받았지만, 대부분의 프로세스는 혼자 진행했다.
② 고객의 니즈를 파악하기 위해 고객들에게 전화를 돌리고, 짧은 전화 인터뷰를 진행했다. 통화가 안 되면 문자와 카톡을 남겨서라도 끝내 통화를 완료했다.
→ UT 전문 팀이 있긴 하지만, 짧은 전화 인터뷰는 누구나 할 수 있으므로 빠른 결과 도출을 위해 PO와 함께 진행했다.
③ QA 시나리오를 작성하고, 테스트 계정을 구해서 QA팀과 함께 QA를 진행했다.
→ 프로덕트의 서비스 흐름에 따라 QA 시나리오를 작성하고, 테스트 가능한 계정을 구하고, QA팀과 함께 QA를 진행했다. 신규 서비스여서 QA팀에서 시나리오를 작성할 수 없었는데, 당시 PO팀 여력이 안되어 내가 작성했다.
이 외에도 정말 많지만, 자세히 적을 수 없으므로 이만 줄이겠다.
즉, 개발 빼고 다 한다.
이처럼 PM은 프로젝트가 제대로 굴러가기 위한 모든 일을 한다. 즉, PM의 업무 범위는 따로 없다. 개발 빼고 다 한다는 마음으로 일하면 오히려 속이 편할 것이다. 심지어 나는 개발도 쪼금 할 수 있으니, 필요하다면 개발도 할 것이다.
다만, 굳이 전문가가 있음에도 내가 모두 하려고 할 필요는 없다. 나보다 더 잘할 수 있는 담당자가 있다면 담당자에게 업무를 맡기고 진행 상황만 체크하면 된다. 이것이 나에게도, 그 사람에게도, 프로젝트 팀에도 좋은 일이다. 그러나 각 담당자들의 리소스는 한정되어 있는데, 매번 내 프로젝트만 우선순위 높여서 진행해달라고 부탁할 수는 없는 일이니 필요에 따라 내가 직접 하거나, 함께 하면 된다. 아무튼 일정을 맞출 수만 있다면 누가 하는지는 중요하지 않다.
PM은 프로젝트의 처음부터 끝까지 모두 알아야 하며, 필요에 따라 어떤 일이라도 해야 한다. 또한 누구나 할 수 있지만, 모두 하기 싫어하는 일이 있다면 그건 PM이 하면 된다. (예를 들어, 공문 작성이나 프로젝트 회식비용 품의 같은 일 말이다.) PM에게 중요하지 않거나 하기 싫은 일은 없다. 그냥 필요하면 다 하면 된다.
