나는 PM(Project Manager)이다 - 5. 섀도우스트라이커의 역할

앞의 글에서 프로젝트 전체를 개괄했고 각 단계별로 어떤 일들이 일어나는지 살펴 보았다. 이번에는 각 단계별로 구축 PM은 어떤 능력을 요구 받고 어떤 역할을 수행 하게 되는지 한번 살펴 보자(여기서 PM은 앞서 설명드린 PM이라고 하기엔 조금 부족한 PM 기준임).

축구에 섀도우스트라이커라는 포지션이 있다. 공격을 책임 지는 스트라이커와 경기를 조율하는 미드필드 사이에 위치 한다. 이 포지션은 전문적으로 골을 넣거나 미드필드에서 경기를 조율하지는 않지만 팀 공격력에 엄청난 영향을 미친다. 섀도우스트라이커는 공격의 유기적인 흐름이 끊어지지 않게 미드필드와 스트라이커를 도와주어야 한다.

때로 스트라이커를 압박하는 상대 수비를 분산 시키기도 하고 스트라이커를 압박하느라 허술해진 수비를 뚫고 스스로 골을 넣을 수도 있다.

프로젝트 이야기 하다가 생뚱맞게 웬 축구이야기냐고 할 수도 있겠지만 사전영업에서 PM이 해야 하는 일이 앞서 설명한 축구의 섀도우스트라이커와 아주 비슷하다.

사전영업의 가장 중요한 목표는 사업을 수주하기 위해 고객에게 최대한 어필 하는 것이고 이것은 영업의 몫이다. 하지만 고객이 요구하는 구체적인 기술적 의문에 대응하는 데는 한계가 있다(물론 기술직에서 영업으로 이동한 캐리어라면 기술에 좀 더 강할 수 있지만 어차피 필드에서 멀어지면 최신 트랜드나 구축사례에서 약점을 가질 수 밖에 없다). 이럴 때 영업은 실제 구축사례를 통한 구체적인 비전 제시와 현행 시스템의 문제점을 기술적으로 조언할 수 있는 PM의 도움을 요청하게 된다.

그럼 구체적으로 어떤 도움을 어떤 방식으로 요청 하게 될까?

첫번째, 기술문서 요청이 있다.

고객은 일반적으로 자신이 발주하려고 하는 프로젝트에 대해 결정권자를 설득하거나 근거를 제시하기 위한 보고서를 작성해야 하는데 이 과정에서 프로젝트의 필요성이나 타당성을 뒷받침할 기술적 근거가 필요하게 되고 영업이 진행 되는 과정에서 영업대표에게 요청할 수가 있다. 이럴 때 영업은 PM에게 도움을 요청한다.

기술문서는 대체로 두 가지 정도로 나뉘는데 최신 트랜드 및 기반기술의 발전 때문에 프로젝트가 필요하다는 스타일과 특정 업무를 전산적으로 지원하기 위해 솔루션 도입이나 시스템 구축이 필요하다는 스타일이다.

전자의 경우는 최신 트랜드나 기반기술의 발전에 대해 도식화 하거나 쉽게 이해할 수 있게 도표 등으로 구성해서 고객들이 보고하고자 하는 경영층에서 한눈에 알아볼 수 있는 문서를 만드는 능력이 필요하다. 후자의 경우는 영업을 통해 전달 받은 고객의 비즈니스 프로세스를 정확하게 이해해서 시스템의 대략적인 구조를 제시할 수 있어야 한다. 물론 전산화 했을 때의 개선점을 수치화 하거나 객관적으로 제시할 수 있으면 금상첨화.

두번째, 시연 및 기술적 상담 요청이 있다.

영업이 어느 정도 진행되면 고객쪽에서 점점 더 구체적인 문제들을 이야기하게 되고 결국 기술적인 부분에 대해 전문적인 응대가 필요하게 된다. 이 때도 영업은 PM에게 지원을 요청하게 된다. 시연이나 상담은 고객의 상태에 따라 대응방식이 달라야 하는데 고객은 크게 다음과 같은 세 가지로 나눌 수 있다. 

A.백화점엔 왔지만 뭐가 필요한지 몰라요 형

이런 유형의 고객들은 흔히 탑다운으로 개선사항을 지시 받았지만 기술적으로 해결할 수 있는 방법을 알지 못하는 상태인데 탑다운으로 내려온 개선사항이 직접적이지 않고 모호하거나 개념적일 때 흔히 나타난다. (예를 들어 대표이사가 전사적으로 수평적인 커뮤니케이션을 활성화 시킬 수 있게 시스템적으로 지원하라고 하거나 업무노하우를 손쉽게 공유할 수 있는 시스템을 만들라고 지시할 때 등)

이럴 때는 고객의 요구사항을 구체화 시킬 수 있는 실제 구축 사례와 함께 시스템으로 구현 시 나타날 수 있는 문제점을 함께 짚어 줄 수 있어야 한다. 설득력 있는 안을 제시할 수 있다면 수주 확률이 아주 높지만 고객도 정확하게 알지 못하는 니즈를 구체화 하면서 읽어내야 하기 때문에 난이도가 높은 편이다.

B.조깅을 하려고 하는데 발이 편한 신발 있을까요 형

이 유형은 전사적(全社的)으로 문제가 감지되고 대두 되고 있어서 어렴풋하게 큰 그림은 그리고 있지만 좀 더 구체적인 안이 필요한 경우에 자주 볼 수 있다. 이런 경우에는 고객의 요구사항을 듣고 핵심을 정확하게 이해해서 구체적인 구현모습을 그려줄 수 있어야 한다. 기본적으로 담당자 뿐만 아니라 결제권자들도 문제점은 공감하고 있기 때문에 구체적으로 표현을 못 할 뿐이지 머릿속에 이런 저런 어렴풋한 이미지들을 가지고 있기 때문에 자신이 상상하던 모습과 다르다면 이런저런 의문사항들이 구체적으로 나올 수 있다. 

만약 고객들이 만족할 안을 만들 수 있다면 전체적인 모습을 고객측과 컨펌한 것과 비슷하기 때문에 수주 시 분석이나 설계 단계에 혼란이 적은 장점이 있다.

C.할원이 얼만가요 형

가장 쉽고도 어려운 스타일의 고객인데 자신이 구축하려는 시스템에 대해 상세한 플랜이 있고 설계까지 끝나 있는 상황에서 예산을 최대한 아껴서 구축하려는 경우이다.

고객이 그려 놓은 설계가 문제가 없다면 말그대로 구축에 대한 비용을 설득 할 수 있으면 그만이지만 문제는 고객은 아주 상세하게 그렸고 그대로 구축만 하면 된다고 하지만 실제로 구축하기에는 턱없이 부족하거나 논리적으로 맞지 않을 때가 많다는 점이다.

이럴 때는 이미 자신은 다 알고 있다고 생각하는 고객을 자존심 상하지 않게 문제점을 지적하고 올바른 방향으로 유도할 수 있어야 하기 때문에 기술적인 부분 보다는 커뮤니케이션 스킬이 더 필요하다.

이런 기술적인 문서를 주고 받거나 상담을 진행 할 때 고객은 알게 모르게 PM으로 소개 받은 당신을 탐색하게 된다. 주로 기술적인면과 일을 대하는 애티튜드 두 가지 부분이다.

기술적인 완성도를 판단할수 있는 고객은 상대적으로 적기 때문에 당신이 특별하게 버벅 거리거나 당황하지만 않는다면 대부분 고객들은 첫인상이나 느낌으로 PM으로서 당신을 판단하게 된다.

이때 당신은 너무 영업같아 보여도 너무 엔지니어같아 보여도 안돼는 참으로 미묘한 위치선정이 필요하다 이 글을 시작할때 예로 들었던 섀도우스트라이커처럼. 

영업이 매끄러운 언변으로 제품의 우수성과 도입시 발생할 긍정적 효과들을 풀어 놓을 때는 그저 가벼운 맞장구나 제스추어로 몸을 낮추고 있어야 한다.

그러다 고객쪽에서 뭔가 조금 더 기술적인 문제를 질문 하거나 실제 구축사례에서 알 수 있는 디테일한 질문이 왔을 때 영업이 매끄럽게 대답하기 힘든 질문에 대해 꼭 매끄러운 언변이 아니더라도 질문에 대한 정확한 답변과 함께 그 질문에 의해 일어날 사이드 이펙트까지를 고객의 편에 서서 설명해 준다면 '아 저 사람과 프로젝트를 하면 뭔가 믿을 수 있겠구나, 나를 많이 도와주겠구나'라는 긍정적인 인상을 심어 줄 수 있게 된다.

여기까지가 이 단계에서 PM이 할 수 있는 최선인 것 같다.

기술적인 미팅이나 설득이 성공적으로 진행되어 고객측에서 사업을 발주하기로 결정하면 RFI나 RFP를 작성해서 프로젝트를 정식으로 발주하게 되고 입찰에 참여하기 위해서는 제안서 작성과 제안 발표를 진행해야 한다.

다음 시간에는 PM이 좀 더 전면적으로 나서야 하는 제안서 작성과 제안 발표 시 PM의 역할을 살펴 보도록 하겠다.