[알쓸신잡] PM? No! TPM의 직무 알아보기.

비지니스 파트의 직무인 PO(Product Owner), PM(Product Manager)를 널리 사용하다보니 전통적인 PM(Project Manager)의 직무가 개발영역이 아닌 사업영역에서도 할 수 있는 것처럼 인식이되기 시작했고 실제 혼용해서 쓰는 업체들도 많아졌다.

국내에 TPM 이 소개된 것은 AWS 의 채용으로부터 시작되었고 쿠팡이 AWS를 따라하다보니 TPM(Technical Program Manager) 가 알려지게 되었다.

Technical Project Manager 는 3개 등급으로 구분할 수 있다.

• Technical Project Manager
• Technical Program Manager
• Technical Portfolio Manager

 

직무 역량의 크기로 표현하자면 아래와 같다.

 Project << Program << Portfolio

 

그럼 이제 와서 굳이 TPM 인가?

PM 의 업무에 대한 정립이 제대로 되지 않은 상태에서 업무를 수행하다보니 한 사람이 사업적 측면과 개발적 측면을 모두 커버하기엔 어려움이 따르게 되었다.
일반적으로 기획을 하던 사람은 사업적은 측면에 기울어져 있어 사용자 측면과 일정 측면에서 프로젝트를 이끌고 갈 수는 있으나 프로젝트 산출물에 대한 품질과 공정까지 신경 쓸 수 없다. 
전통적인 PM 역할을 수행하던 사람은 SW공학 측면으로 접근이 이루어져 정해진 기간내에 프로젝트를 완수해 내지만 실제 사용자에게 유용하지 않거나 매출로 이루어지지 않을 수 있다.

조직에서는 사업적 측면으로 프로덕트를 리딩할 PO(Product Owner)/PM(Product Manager)와 개발이 잘 진행될 수 있도록 프로젝트를 리딩할 PM(Project Manager)가 필요하게 되었고 직무의 혼돈을 막기위해 T(Technical) 수식이 붙은 TPM이 필요하게 되었다.

 

Technical Project Manager

→ 팀(team) 단위
→ 이해 관계자가 적고 단일 목적의 소규모 프로젝트
→ 일정 관리, 프로젝트 리스크 관리 및 이슈해결 지원

 

Technical Program Manager

→ 부서(division) 단위
→ 프로젝트의 불확실성이 존재하고 다양한 부서와 협력이 필요한 프로젝트
→ 업무(도메인)와 관련된 리스크 관리
→ 리더십과 커뮤니케이션 능력이 강조됨

 

Technical Portfolio Manager

→ 회사(company) 단위
→ 대/내외 이해관계자가 복잡하게 존재하며 큰 규모의 프로젝트
→ 전사 리스크 관리 능력이 필요
→ 프로젝트의 PM에 대한 가이드/코칭 역할 수행

 

직무가 아닌 사람의 역량으로 구분하게 되면

TPM << Senior TPM << Principal TPM 

 

---

AWS Career 

Amazon's global career site

 

 

AWS TPM Saray