다음 제품 출시때 어떤 기능을 출시할 지에 대해 회의를 열고 있다. 누구의 의견이 제일 옳을까?
-
회사를 설립하고 지금까지 이끌어온 대표의 의견
-
매일 고객과 만나고 현장의 목소리를 잘 알고있는 영업팀의 의견
-
제품의 성장에 대해 매일 고민하고 연구하는 PM의 의견
-
직접 제품을 개선시키고 결과물을 만들어 내는 제품팀의 의견
-
고객의 불만을 듣고 이를 해결하는데 최선을 다하는 CS팀의 의견
정답은 없다고 생각한다. 모두 맞는 말이고 중요하지 않은 것은 없다고 말할 수 있을거 같다. 하지만 그 모든 의견과 생각 사고들이 고객을 생각하는 고객 중심의 사고여야 한다고 생각한다.
그게 PM이 존재하는 이유 중에 하나라고도 생각한다. PM은 고객의 문제를 해결해주는 해결사이다. 사용자의 문제, 이 서비스가 왜 있어야하는지를 명확히 알고 있어야하며, 팀 전체 의사결정을 고객 중심으로 풀이해야한다.
"팀 전체 내의 모든 역할군은 결국 사람이다. 또 사람은 자기가 하고싶은대로 생각하고 행동하기 마련이다."
예를 들어서, PM 없이 프로젝트가 굴러간다고 생각해보자. 영업팀의 의견만 들으니 제품이 Heavy해지고 개발팀이 원하는대로 만드니 정작 고객이 원하는 기능이 없다. 반대로 CS팀의 요청을 다 반영해서 개발했더니 전체적인 전략이 없어졌다. 모두의 의견을 반영한다고 해서 좋은 제품이 나오는 것이 결코 아니다.
현재 구글 플레이스토어와 앱스토어에만 등록된 앱(Application)만 중복 가능성 포함 400만개라고 한다. 이 말이 무슨 말이냐 IT프로덕트의 특징은 많은 다수와 경쟁하기에 난이도가 높고 성공률은 현저히 낮은데 반해 많은 리소스를 요구한다. 개발자랑, 디자이너 2명으로 시장 트렌드를 따라가며 6개월안에 제품을 개발할수 있는가? 물론 가능은 하겠지만 제품 퀄리티도 낮을테고 성공률도 낮다고 보면 된다.
인력이 투입되는 만큼 인건비가 들어가고 수입 없는 매출은 곧 빚이되어 현실적인 risk로 작동된다. 그 안에 또 비효율적인 의사소통으로 인한 팀 구성원간 risk도 포함하면 점입가경이다. '많은 기업들이 엄청난 시간과 비용을 들이고도 매우 허망한 성과를 거두는 현상은 그리 놀라운 일도 아니다'(인스파이어드:inspired 인용)
정말 PM이 필요한 순간이다. 이 제품의 생명주기와 연관된 모든 것을 조율해 오로지 제품의 성공에만 집중하는 전문 인력이 PM이다. 제품 서비스에 대한 두 가지 불편한 진실은 아이디어 중 최소 절반은 유효하지 않을 것이다. 그리고 가치 있는 아이디어할지라도 비즈니스 가치를 만들기 위해 몇번의 시도와 실패가 필요하다. 많이 순화된 표현이였지만 몇번이 아닐수도 있다. 수십 수백번일수도 있다.
프로젝트 관리자의 업무인 프로젝트 관리는 실질적으로 개발을 하는 엔지니어의 편의를 위해 요구사항을 수집하고 문서화해서 주는 것이다. 폭포수 모델처럼 기획 > 요구사항 정의 > 디자인 > 개발이다. 이처럼 좋아보이는 결과물이 좋은 성과물을 낼 수 있을까? 그렇지 않다. 줄곧 실패하고 좋은 제품을 만들지 못한다. 계획이 완벽한데 왜 실패할까?
프로젝트 관리의 근본적인 문제는 '고객에 대한 검증'이 너무 늦게 일어난다는 것이다. 완벽한 기획을 했어도 6개월 뒤 고객 니즈가 바뀌고, 모든 기능을 다 만들고 검증했더니 아무도 안쓰는 사례가 나오며 기획을 다 하고 개발했더니 개발팀이 처음부터 다시 만들어야 한다고 하는 경우가 비일비재 하기 때문이다.
결국 우리가 배워야 하는 것은 "기획" 이 아니라 "적응"이다. 제품을 만들면서 계속 조정할 수 있는 조직이 되어야한다. 따라서 프로그래머들이 모여 애자일 선언을 하게 된다.
Agile이란 기민하다, 민첩하다라는 뜻을 내포하고 있다. 민첩하게 의사소통하고 결정하여 아이디어가 나올때마다 제품을 기획하고 만들고 시도하고 문제 파악할때 빠르게 맞닿뜨려 개선하는 Lean start-up 개발 방식도 있다. 시장의 리스크를 없앤다고 하여 좋은 평가도 있지만 그 만큼 도전하는 마음이 있어야 가능하지 않을까 싶다. 아무리 좋은 아이디어여도 실패할 확률은 높기 때문에 빠르게 실패하는 방식인 것이다.
그럼 어떻게 해야하는가?
IT 제품을 성공시키기 위해서는 전문가가 필요하다. 각 구성원들 즉 전문가들은 자신의 분야에서 활약할 때 최고의 역량을 발휘한다. PM은 '협업'과 고객을 중심으로 태어난 직무이다. 제품이 과연 가치가 있는지 사용하기 좋은지 우리가 만들수 있는지에 대해 고민하며 위험은 마지막이 아니라 '초기'에 대응한다.
PM은 궁극적으로 구성원들간 즉 PM이 속한 팀을 미션팀으로 만드는게 이상적이다. 그럼 왜 미션팀일까?
용병팀과 미션팀으로 나뉠수있는데, 용병팀은 다소 수동적이고 각 구성원이 개인적인 경향이 큰 구성원들이다. 속된 말로 월급은 월급대로 받고 영혼 뺏기며 시키는 대로 일하는 게 용병팀이다. 미션팀이 용병팀보다 나은 이우는 미션팀은 제품의 성공을 목표로 삼고, 문제해결을 위해 고민하고 개선한다.
그에 반해 용병팀은 주어진 업무만 처리하고 결과에는 크게 관심이 없다. 미션팀은 실패를 통해 개선하고 다음 기회를 노리지만, 용병팀은 실패하면 각 구성원들이 책임회피를 하며 "내 잘못 아니다"라고 생각하고 끝나고, 미션팀이 있으면 PM의 역할이 크게 줄어 PM이 없어도 제품이 성장한다.
하지만 현실 한국에 IT기업들은 대부분 용병팀으로 구성되어있거나, 한국인들의 정서가 용병팀이 더 편할수도있는데, 각 기업들이 어떤 가치를 더 중요하게 생각하느냐에 따라 다르게 구성하는 경향이 있다고 생각한다.
소통과 협업을 중시 한다면 미션팀과 같은 기업문화를, 지시와 절차를 중심으로 한다면 용병팀과 같은 기업문화인 것처럼 말이다.
"이상적인 PM의 역할은 존재하지만 모든 회사가 이상적인 PM을 원하지는 않는다."
구성원내에 협업을 방해하는 요소는 항상 있다. 서로 다른 정보를 주고받아서 팀이 다르게 움직이는 정보 불균형과 실제 성과와 예상 성과를 분석하는 전략적 격차라는게 존재한다.
PM이 협업을 방해하는 요소들을 효과적으로 해결하기 위한 핵심 전략들은 크게 3가지이다.
-
정보 불균형 → 정보를 조율하는 사람이 필요하다, 모든 부서가 동일한 정보를 기반으로 의사결정을 할수있도록 조율하고 의사 결정 과정에서 정보가 누락되지 않도록 관리 필요
-
우선순위 출동 → 우선순위를 통일해야 한다,팀 전체가 동일한 목표를 바라볼 수 있 도록 공통의 기준을 세우고,"이 기능을 추가하면, 궁극적으로 제품의 목표와 일치하는가?"에 대한 질문
-
책임 회피 → 책임을 명확하게 나눠야 한다.
이러한 핵심 전략은 미션팀을 만들기 위함이 바탕이기도 하다. PM은 팀원들이 제품의 목표를 이해하고 있어야하며 정보 불균형을 해소하고,우선순위 출동 방지를 위해 병목 없는 빠른 의사결정이 이루어져야한다. 그리고 팀원들에게 주도성을 부여해 책임회피보단 각 구성원이 역할에 따른 책임을 명확하게 나눠 분담할수있도록 해야한다.
미션팀을 만들기 가장 어려운 요소는 용병팀을 추구하거나 수직적인 분위기의 기업 문화이거나, 기업 내에 평가 시스템이 있어 개별 성과내에 평가를 부여하면 미션팀을 방해하기도 한다. 그리고 지나치게 느린 의사결정 프로세스는 미션팀의 강점을 무력화한다. 이 방해요소들을 타파하기 위한 방법론들이 다양하지만 "PM은 방법보다 원칙에 집중해야 고집이 아닌 지조있는 PM이 될 수 있다."
"각 제품팀을 운영하기 위해 어떤 원칙을 세워야하는지 어떤 문제를 해결해야하는지, 적용할 수 있는 방법론들이 어떤 원칙하에 설계되었는지 이해하고 실제로 이 방법론을 적용해 보는 과정에 대해 실험하고 학습하는 과정이 중요하다."
현실에서 용병팀이어야지만 항상 실패하고 매출이 적게 나는 것이 아니다. 하지만 내가 어디서 일할지는 선택지는 나에게 있다.
모든 이슈와 의사 결정 안건을 CEO에게 보고하는 용병팀에서 근무하거나, 이해관계자를 모으고 그들끼리 결정하도록 도와서 최종적으로 스스로의 필요한 업무를 자동적으로 하는 미션팀에서 근무하는 것이다.
내가 어디에서 일할지 고민하기 전에 "어떻게 일하는 것이 나의 역량을 살리며 더 높은 프로덕트 성과를 낼 수 있을까?"에 대해 스스로에게 질문해보는 것도 중요하다.
