[2020년 12월 28일] - 한국에 가면 반복적으로 하는 것이 있습니다. 바로 명함 교환이란 사회적 행위입니다. 외국엔 명함 교환을 하는 의식이 없다는 것이 아니라, 소비자나 기업고객을 직접 상대하는 직업이라면 매우 빈번하게 사용됩니다.
하지만 기술자 엔지니어들의 경우는 그 경우가 현저히 적을 뿐만 아니라, 엔지니어들은 그다지 그런 사회적의식이나 규약을 따르는 일에 익숙하지 않습니다. 더 큰 이유는 저 사람이 무슨일을 하는지 아는 사람들과의 관계가 대부분이기도 하기 때문입니다. 저 역시 한국이나 아시아 국가에 출장을 가는 경우엔 출장 준비 물품중에 명함이 꼭 빠지지 않도록 준비하곤 합니다.
명함을 건내면서 저는 'PM 입니다' 라고 소개를 하면 대부분의 경우가 두가지 부류로 나누어 집니다. ▲첫번째 부류는 많은 분들이 어떤 일을 하는지 직관적으로 이해하시지는 못하는듯 합니다. ▲두번째 부류는 어떤 업계에서도 들어봤음직한 '프로젝트매니저 Project Manager' 라고 이해를 합니다.
또한 기회가 있는 대로 한국의 소프트웨어 산업을 한 단계 성장시키기 위해선 '보다 유능한 'PM'을 적극적 육성해야 합니다'라고 말씀을 드려도 (여기 사용된 PM은 프로덕트 매니저와 프로그램 매니저를 인용한것이었습니다.) 어떤 일을 하고 어떻게 유기적으로 상호간에 일을 하는지에 대한 이해도가 부족함을 느꼈습니다.
또 한가지 중요한 이유로는, 젊은 청년들이 외국의 글로벌 기업에 진출을 하려고 마음을 먹지만, 글로벌 기업의 엔지니어링 조직구조를 잘 모르고 있구나라는 느낌도 받았습니다. 올해 만나뵌 소위 개발 분야의 강호의 초고수를 만나서 이야기를 나누었을때 조차, 이 부분에 대한 개념이 부족한것을 보곤 한번은 정리해야 겠다 싶었습니다.
이런 저런 이유로, IT기업에서의 각각의 PM (프로덕트 매니저 Product manager, 프로그램 매니저 Program manager, 프로젝트 매니저 Project manager) 의 업무 정의와 역할에 대해서 설명을 시작해 봅니다.
0. 시작하기 전에 Pre-requisite
지금부터 설명하게 될 3가지 역할에 공통적으로 붙는 '매니저 manager' 라는 말이 한국에서는 관리자로 이해 되는 경우도 있을텐데, 그러다 보니 '팀원은 몇명이나 데리고 있는지' 에 대한 질문도 많이 듣게 됩니다. 일단 정확히 이해하셔야 할 부분은 3가지 PM의 모든 공통사항인데, management 해야 할 대상이 사람이 아니라는 것입니다.
프로덕트 매니저에겐 관리해야 할 대상은 프로덕트 (제품, 서비스)이고, 시간이고, 기능이 이 일의 역할인란 뜻입니다. 사람을 관리하는 people manager와는 다른 일이란 사실을 먼저 말씀 드리고 들어갑니다.
1. 프로덕트 매니저 Product Manager
프로덕트 매니저를 가장 강렬하게 인용한 어구는 벤 호로비츠가 지은 프로덕트매니지먼트의 바이블이라고 하는 책 'Good Product Manager/Bad Product Manager' 에서 말한 "프로덕트 매니저는 그 프로덕트의 CEO 다" 라는 말입니다. 즉 해당 프로덕트의 성공과 실패를 책임져야 한다는 뜻으로 쓴 말인데, 저는 개인적으로는 '비져너리 Visionary'라는 말을 더 좋아합니다.
프로덕트 매니저는 고객과 시대가 요청하는 사항을 잘 읽어, 그것을 비전화하고 솔루션을 만들어 그것을 제품/서비스에 포함시킵니다. 스티브잡스는 역대 최고의 프로덕트 매니저 였다는 생각을 합니다. 고객의 요청에 '애플'이라는 제품/서비스/브랜드를 어떻게 이미지화 했고, 제품/서비스로 제공했습니다.
IT회사에서 프로덕트 매니저는 반드시 엔지니어링/개발 그룹이나 그와 동등하게 제품/서비스를 소유하고 있는 그룹내에 존재하게 됩니다. 프로덕트 매니저라는 직함은 실제 근무하고 있는 곳이 본사 주소가 아니라고 해도, 그 소속은 엔지니어링/개발그룹내에 속해 있을 가능성이 높습니다. 제품/서비스가 있는 곳에 프로덕트 매니저의 역할이 있기 때문입니다.
프로덕트 매니저는
▲고객의 요청를 수렴하여 그 요청에 부합하는 솔루션을 제공합니다.
▲그 요청을 우선순위로 정리하고, 제품/서비스의 라이프사이클을 정의 합니다.
▲전략적인 사업 목표/비젼 business objective를 정의 합니다. (이 부분은 후에 여러개의 프로젝트로 나뉠 수 있습니다.)
▲해당 제품/서비스의 전체 책임자입니다 (디자인, 개발, 디플로이먼트, 프로덕션)
▲수익모델이나 홍보 마케팅에 대한 부분은 그룹내 판매나 마케팅을 담당하는 부서와 긴밀히 상의합니다.
▲경쟁 제품과의 경쟁력비교를 통하여 제품/서비스의 지속가능한 장점을 구축합니다.
일반적으로 프로덕트 매니저는 올라운드 플레이어로서 자기제품/서비스에 대한 총 책임을 지게 됩니다. 제품/서비스의 크기에 따라서 수십명의 프로덕트 매니저가 한 제품/서비스에 함께 업무를 담당하는 경우도 흔하게 있습니다.
개발 경력이 필수는 아니나 개발자로서 경력을 충분히 가진 사람이 솔루션을 디자인할때나, 개발팀과 효율적으로 소통하고 이해할 수 있다는 면에서 개발자 경력자를 선호하는 면이 있습니다.
2. 프로젝트 매니저 Project manager
IT기업에서의 프로젝트매니저는 엔지니어링/개발그룹에 있을수도 있고, 고객을 지원하는 필드서포트에서도 존재 할 수 있습니다. 즉 프로젝트 매니저라는 직함만 가지고는 정확히 어떤 조직에 속해있는지를 파악하기는 어렵습니다.
한국에서 PM이라고 하면 대부분이 이 프로젝트 매니저를 암묵적으로 이야기 하는 경우가 있는데, 그것은 주요 업무가 SI개발사업에서 대 고객프로젝트가 많은 상황에서, 프로젝트 계획, 업무 분담, 그 진행을 공정시기에 맞춰 관리하는 일이 상대적으로 많고, 접하기 쉬운 이유가 아닐까 생각합니다.
IT기업의 엔지니어링/개발 그룹에도 프로젝트 매니저는 매우 중요한 역할을 수행합니다. 요즈음엔 프로젝트 매니저라는 이름보다는 스크럼 마스터나 스크럼의 스크럼 Scrum of Scrum 이라는 이름으로 주로 프로젝트의 타임라인과 그 진행 스피드를 관리하는 역할을 수행합니다.
타임라인과 진행스피드라는것은 즉 리소스(시간, 사람, 비용)를 어떻게 효과적으로 투입하고 투입한 결과에 대한 분석을 통해서 그 프로젝트의 예정된 시간에 계획되었던 기능을 포함하여 프로젝트를 마치는 것이 모두 포함됩니다.
프로젝트 매니저의 주요 역할은
▲위험 관리 risk management
▲자원 관리 resource management
▲범위 관리 scope management
프로젝트 매니저의 예상치 않은 상황을 헤쳐가면서, 가용가능한 리소스 (시간, 비용, 인적자원)으로, 정해진 시간에, 계획된 품질을 가진 제품/서비스를 출하하는 것이 목표인 역할을 수행합니다.
3.프로그램 매니저 Program manager
아마도 한국에서 가장 생소한 PM중 하나가 프로그램 매니저가 아닐까 합니다. 회사에서 현재 제 업무 역할 역시 프로그램 매니저입니다. (위에서 말씀드린 명함을 주고받을때 저희 역할을 설명해야 하는 이유가 여기에 있습니다.)
가장 설명드리기 까다로운 부분입니다. 프로그램 매니저는 프로덕트 매니저, 프로젝트 매니저와는 달리 회사마다 산업부문마다 약간씩 다른 역할의 의미가 가감되어 있습니다. 회사의 경우에 따라 프로덕트 매니저와 비슷하지만 책임의 한계에서 특정 기능을 소유한 프로덕트 오너 Product Owner로 쓰이기도 하고, 전체 딜리버리(프로젝트를 여러개 묶었다는 의미로 생각하시면 됩니다.
즉 여러개의 프로젝트가 하나의 스위트Suite를 이루어 같은 시기에 고객에 제공된다는 의미입니다.)를 책임진다고 해서 딜리버리 매니저 Delivery Manager의 개념도 존재합니다.
두가지의 경우가 다르기에 이렇게 설명드려 보겠습니다.
A. 엔지니어링/개발 그룹에 속해 있는 프로그램 매니저라면 특정 기능을 소유한 프로덕트 오너쯤으로 생각하시면 됩니다.
밑의 그림을 예를 들어 설명해 볼텐데, 가장 쉬운 예는 마이크로소프트의 오피스를 예로 드는것이 좋을듯 합니다. (특별한 이유는 전혀 없습니다.)
그림의 스코트, 폴, 토니는 모두 각각의 제품을 책임지는 프로덕트 매니저 입니다. 그것에 반해서 엘리자나 피터는 본인이 책임지는 특정 제품/서비스는 없으나 '복사와 붙여넣기' 기능이라던지, '스펠체킹'기능과 같이 여러 제품에 탑재가 되어 동작을 하게 되는 기능을 디자인하고 개발하는 그 기능을 소유한 책임자 입니다. 이런 cross-product/ cross-functional component를 오너들을 프로그램 매니저 라고 부릅니다.
B. 엔지니어링/개발 그룹에 소속여부와 상관없이 프로젝트 매니저와 비슷한 역할을 수행하고 있는 딜리버리 매니저입니다.
산업 전반에 있어서 여러 연관성 있는 프로젝트를 모아서 관리하는 큰 개념의 프로젝트 매니저라고 생각하시면 됩니다. 혼란을 피하기 위해 딜리버리 매니저라는 말을 사용합니다. 각각의 프로젝트에 대한 자세한 이해를 갖기 보다는 각각을 조율하여 하나의 스위트로 나가는 역할을 수행하게 됩니다.
위의 예에서 워드, 엑셀, 파워포인트와 같이 각 프로덕트의 프로젝트 매니저들이 있다면, 그것을 오피스로 묶어서 한번에 딜리버리를 관리하는 딜리버리 매니저가 존재합니다. 그때 회사에 따라서 그 역할을 프로그램 매니저라고 부르기도 합니다.
이때 프로그램 매니저는 각각의 프로덕트가 한번에 셋트로 묶여 나올때의 비즈니스임팩트와 그것을 분석해내는 역량을 요구합니다. 이 부분은 프로덕트 매니저가 볼 수 있는 비젼의 한계를 넘어서기에 그 이유가 있습니다.
스타트업 같이 작은 규모에서는 프로덕트 매니저가 프로젝트 관리도 함께 하는 경우가 많지만, 비즈니스가 진화하면서 위에 설명드린 3가지 역할은 따로 그리고 함께 맞추어 동작하게 됩니다.
자 깔끔하게 3가지 PM의 역할을 정리해 보겠습니다.
▲프로덕트 매니저는 제품의 '무엇' 과 '왜' 에 초점이 있는 역할입니다.
▲프로젝트 매니저는 제품의 '언제' 에 관심이 있는 역할입니다.
▲프로그램 매니저는 제품을 '어떻게'에 모든 열정을 쏟는 역할입니다.
이해에 도움이 되셨으면 좋겠습니다.
By 김영욱 프로덕트매니저(PM) ywkim36@gmail.com
〈저작권자ⓒ 위클리포스트, 무단전재 및 재배포 금지〉
