회사에 처음 입사했을 때, 회식하던 중에 팀장님이 'PM으로써 어떤 게 가장 중요하다고 생각하는지'를 물어보셨다. 그 때 회식하고 있던 팀원은 나까지 3명이었는데, 한명은 노력이라고 대답했고, 한명은 인내심, 나는 운이 좋아야 한다고 대답했다.

나는 지금도 프로젝트에 있어 운이 중요하다고 생각한다. 팀원들에게도 항상 프로젝트는 ‘기적이 일어나야 끝이 난다’고 이야기하고 다닌다. 내 얘기에 반론을 제기할 사람이 많이 있을 것이고, 대부분의 반론에 일리가 있겠지만 나는 '프로젝트에 있어 운이 중요하다'는 내 지론을 꺾을 생각이 없다. 왜냐하면 프로젝트를 수행하는데 있어 고객의 성향이 많은 것을 좌우하기 때문이다.

같은 산출물이나 보고에도 고객들의 반응은 천차만별이다. 어떤 고객은 PM의 성향과 잘 맞고 어떤 고객은 그렇지 않다. 자신과 잘 맞는 고객과 만나면 프로젝트는 수월하게 진행된다. 하지만 PM은 자신과 잘 맞는 고객을 고를 수 없다. 단지 운에 맡길 뿐이다. 그러면 나와 잘 맞는 고객을 만날 확률을 높이는 것도 운에만 달린 걸까?

진인사(盡人事. 도리를 다 함)를 하면 대천명(待天命. 하늘의 뜻, 명을 기다림) 할 때 마음이라도 편하다. 로또 당첨도 일단 로또를 사고 나서 바랄 수 있는 요행인 것처럼 운도 노력 여부에 따라서 조금은 변할 수 있다.

문서를 까다롭게 보는 고객, 무조건 가격이 싼 제품을 좋아하는 고객, 철야 많이 하면 좋아하는 고객 등 다양한 고객들이 있지만, 모든 고객들이 공통적으로 좋아하는 PM이 있다. 바로 유능한 PM이다. 아무리 프로젝트를 많이 하는 고객이라고 하더라도 PM이 업인 사람보다는 많이 할 수 없는 법, 프로젝트 진행 중에 생길 수 있는 문제들을 차근차근 짚어주고 해결해 주는 PM을 싫어할 고객은 없다.

업무 대 업무로 만난 사람들에게 가장 필요한 것은 ‘문제를 해결하는 능력’을 가진 사람이다. 자신이 진행하는 프로젝트를 꿰뚫을 능력이 생기면 고객은 결국 나에게 맞춰진다. 프로젝트를 꿰뚫으려면 프로젝트가 무엇인지, 어떻게 진행되는지를 단계별로 들여다볼 필요가 있다.

일단 프로젝트가 어떤 사이클을 가지는지 살펴보기로 하자.

‘프로젝트’라는 걸 이해하기 위해서 현실에서 겪을 수 있는 것으로 치환해보겠다. 프로젝트와 가장 비슷한 게 뭐가 있을까. 영업대상을 찾아 헤매고, 프리세일즈를 하고, 제안을 거쳐 프로젝트를 따낸 다음, 수행과 유지보수를 하는 일반적인 개발 프로젝트와 가장 비슷한 건 ‘연애’다.

초보적인 PM이나 개발팀들은 프로젝트를 볼 때 ‘분석->설계->개발->테스트->이행->안정화’의 구축부분만 생각하기 쉽다. 하지만 구축은 프로젝트 전체를 보았을 때 중요하다고 해도 결국은 일부다. 고객을 대상으로 하는 영업단계와 유지보수까지 포함해야 한다.

그럼 연애하다 벌어질 수 있는 일들과 프로젝트와 비교해보기로 하자.

1단계: 사전영업

연애를 하기 전 가장 먼저 해야 하는 일은 ‘상대를 찾는’ 거다.

1) 헌팅

우선 헌팅으로 상대를 찾을 수 있겠다. 길 가다 너무 멋진 이성을 발견했을 때 일단 들이대는 거다. 물론 들이댄다고 무조건 사귀는 건 아니고 기껏해야 전화번호 따면 대성공이다. 물론 자신의 외모가 아주 출중하다면 헌팅을 당할 수도 있다.

사전영업도 마찬가지다. 자신이 팔고 있는 솔루션이나 몸 담고 있는 회사가 인지도가 있거나 눈에 띄었을 때, 고객으로부터 영업문의가 온다. 소위 ‘인바운드 영업’이다. 그렇지 않다면 자신이 영업대상으로 선별된 고객들에게 찾아가거나 메일 혹은 매체를 통해 자신의 솔루션을 홍보해야 한다.

2) 미팅

헌팅 외에도 이성을 만나는 방법에는 미팅이 있을 수 있다. 다들 이성을 만나기 위해 나왔다는 목적이 있기 때문에 미팅은 헌팅보다는 잘 될 확률이 훨씬 높다.

각종 컨퍼런스에 참여해서 발표를 하거나 부스 운영을 통해 자신의 솔루션을 설명하거나 팸플릿을 배포하는 것을 여기에 비유할 수 있다. 어느 정도 비슷한 관심사를 가진 사람들이 모인 만큼 영업 기회가 더 많다.

3) 가지치기

마지막으로 가지치기가 있겠다(이런 저런 만남의 방법이 더 있겠지만 이 정도만 하자). 흔히 소개팅이라는 이름으로 불리는데, 가장 확률이 높다.

영업에 있어 ‘소개팅’은 기존 고객사의 고도화 혹은 솔루션 도입을 위해 이리저리 알아보다가 소개를 받은 경우다. 이미 사용하고 있는 경우엔 말할 것도 없고 지인이나 같은 업종에서 소개를 받았다면 어느 정도 믿음이 뒷받침되어 있기 때문에 가장 확률이 높다.

2단계: 프로젝트 수주

1) 작업

상대를 찾았다면 이제는 그 상대에게 ‘작업’을 할 시간이다. 상대방의 의중을 잘 살피고, 말 한마디, 손짓 하나, 눈빛 하나도 허투로 보내서는 안 된다. 특히 “나는 다정다감한 사람이 좋더라~”와 같이 떡밥을 살포할 때 이걸 놓치지 않고 꽉 물어야 한다.

프로젝트에 있어선 고객사에서 자료의뢰서(RFI. Request for information. 프로젝트에 관계된 정보를 제공해 달라고 요구하는 서면)를 배포한다. 내가 구축하려는 시스템은 구축 목적이 어떻고 방향성은 이러저러하다는 식의 두루뭉술한 문서다. 아주 긴밀하게 영업을 하고 있는 경우에는 RFI단계에서부터 개발사들이 자료를 제공하고 방향성을 제시하기도 하고, 고객사 내부에서 자체적으로 만들어 배포하는 경우도 있다.

서로 공감대가 있다면 썸을 타며 간을 보든 돌직구로 들이대든 뭔가 성과를 내야 한다. 그러기 위해서 상세하게 서로를 알아가는 단계를 거친다. ‘이 사람은 뭔가 안정적인 생활을 원하는구나’, ‘정치성향은 진보적이구나’, ‘취미로 사이클을 타는 구나’ 등.

프로젝트에서는 고객사가 정식으로 사업공고를 내고 제안요청서(RFP. Request for Proposal. 제안서의 제출을 요청하기 위하여 작성하는 서식)를 배포한다. 이 단계에서 고객사는 사업을 위한 비용이나 일정을 확정한 상태에서, 요구사항과 사업에 대한 세부적인 사항들을 상세화해서 RFP라는 문서로 만든다.

(출처: 고용노동부의 <고용노동부 온라인 홍보 용역 제안요청서>)

프로젝트를 수주하려고 하는 회사들은 RFP 구현을 위해 필요한 기술적 요소와 시스템 아키텍처 등을 확인하고, 간단한 사업설명회와 문의를 통해 사업에 대한 구체적인 내용들을 파악한다. 물론 긴밀하게 영업을 하고 있다면 RFP의 내용에 영향력을 행사하는 경우도 많다(이런 경우라면 사업 수주확률이 아무래도 높아진다).

2) 고백

드디어 연애에서 가장 가슴 떨리는 순간인 ‘고백’의 시간이다. 내 거인 듯 내 거 아닌 내 거 같은 너 말고, 정말 우리 오늘부터 1일 하자고 눈 딱 감고 이야기하는 거다.

프로젝트에서의 ‘고백’은 제안서를 작성해서 제출하고 제안발표를 하는 단계다. 제안서에는 RFP에서 제시된 고객사의 요구사항을 구현하기 위한 구체적인 플랜과 기술적 설명뿐만 아니라, 제안사의 재무정보에서부터 사업에 참여하는 인력들의 프로필까지 들어있다.

제안서를 제출하고 나면 정해진 날짜에 고객사에서 선정한 심사위원들 앞에서 제안발표를 한다. 예전에는 제안발표만 전담으로 하는 인력이 있었지만, 요즘엔 구축에 투입될 PM이 직접 발표를 하는 게 일반적이다.

3) 고백 후 기다림

고백을 하고 나면? 기다림의 순간이 찾아온다. 고백을 하고 바로 키스를 받는 사람도 있고 조금 시간을 달라는 사람도 있다. 그리고 1일이 시작되든지 친구로 지내자는 한 바퀴 돌린 정중한 거절에 늦은 밤 소주잔을 기울이기도 한다.

제안발표를 하면, 고객사에서 정해진 심사를 거쳐 ‘우선협상대상자’를 발표한다. 우선협상대상자는 말하자면 ‘제안에 참여한 업체 중 1등’이란 의미인데, 우선협상대상자가 되었다면 아주 거대한 문제가 없는 한 그 사업은 사실상 수주한 것이다. 이 바닥에서 1999년부터 일했지만 우선협상대상자가 계약하지 못하는 경우를 본 적이 없다.

3단계: 프로젝트 수행

1) 연애의 시작. 그러나

프로포즈를 하고 나서 결과가 좋았다면 연애가 시작된다. 사귀기 전에는 그 사람이 나를 사랑한다고 하기만 해도 세상을 다 가진 것처럼 기쁠 것 같고 네가 존재 하는 것만으로 세상은 아름다워 보이지만, 현실은 그렇게 녹녹하지 않다. 썸만 타고 있을 때는 잘 모르던 서로의 본모습을 알게 되고, 사랑이라는 이름으로 서로를 속박하려 하고, 마음에 들지 않는 부분을 뜯어 고치려고 달려든다.

RFP와 제안서를 거쳐 요구사항이 구체화되었다고는 하지만, 고려하지 못했든 일부러 숨겼든 새로 추가 되었든, 여러 가지 요구사항들이 추가되고 변경된다. 개발사는 리소스를 투입하고 기술적 한계들과 고군분투하며 서류상의 요구사항들을 실제로 연성시킨다(강철의 연금술사 덕후 아님).

2) 갈등

한편 사랑싸움이 진정될 무렵이면 주변 사람들과의 갈등이 서서히 드러나기 시작한다. 남자친구의 친구들은 왜 저러는지, 여자친구의 친구들은 또 왜 저러는지. 관계가 더 깊어지면 서로의 가족들까지 엮이면서 복잡다단해진다.

프로젝트에서는 사장님께 이번 프로젝트를 자신의 성과로 보고 해야 하는 고객사 임원, 이번 프로젝트 범위는 아니지만 지난번에 예산을 배정받지 못한 자신의 요구사항을 끼워 넣고 싶은 옆 부서 임원, 실제 업무에 유용한 기능을 더 넣고 싶은 현업, 유지보수하면서 문제가 생길 것 같은 요구사항을 받아들일 수 없는 관리부서 대리에서부터, 자신의 기획을 한 치도 물리고 싶지 않은 초짜 기획자, 말도 안 되는 고객사 CI 때문에 자신의 디자인 세계를 펼치지 못해 욕구불만인 디자이너, 야근에 찌든 개발자, 진도를 맞춰야 하는 PM 등 수많은 이해관계자가 충돌한다. PM은 이 수많은 이해관계자들을 설득하고 정리해서 ‘프로젝트 완료’라는 목표로 몰고 가야 한다.

연인은 ‘이 사람이다’하는 운명적 느낌이 들어서든 간에 할 수 없어서든 간에 결혼이라는 것을 한다. 성대하게 결혼식이라는 세레모니도 하고 신혼여행도 거하게 갔다 온다.

야근과 각종 이슈들에 지쳐도 결국 오픈일자는 다가오고, 프로젝트는 오픈이 된다. 검수를 하고 나면 그동안 아웅다웅했던 현업들과 회식도 하고 오픈했다고 각종 매체에 홍보기사도 뿌린다. 고객사에 프로젝트 완료 보고까지 하면 구축은 끝이 난다.

4단계: 유지보수

1) 콩깍지가 벗겨지다

결혼을 하고 나면 본격적으로 콩깍지가 벗겨져 그 사람의 각종 단점들이 눈에 띈다.

프로젝트에서는 개발 때 고려하지 못한 오류가 생기기도 하고 이쯤이면 충분할 것 같았던 기능들도 사용하기 불편하다며, 사용자들이 불만을 접수하기 시작한다.

2) + α

아이가 태어나고 나이가 들면, 월세에서 전세로, 전세에서 자가로, 자가에서 더 큰 집으로, 자꾸만 욕심이 난다. 

유지보수에서도 부족한 기능을 추가 발주하기도 하고 새로운 기능을 덧붙여 개발하기도 한다. 일반적으로는 시스템이 점점 더 복잡해진다. 성공적으로 운영됐다는 전제 하에, 고객사가 그룹일 땐 그룹에 배포하기도 한다.

통상적으로 우리나라에서는 구축 후 1년간 무상유지보수가 지원된다. 1년 후 고객사는 정식으로 유지보수 계약을 맺을지를 결정한다. 유지보수에 대해 계약을 한다면 관계가 계속 이어지지만, 그렇지 않은 경우에는 다른 회사에서 유지보수를 맡아서 하거나 시간이 경과함에 따라 새로운 시스템을 구축하기도 한다.

이상으로 프로젝트라는 놈의 실체를 연애와 비교해서 최대한 이해하기 쉽게 이야기 해보았다. 다 아는 이야기일 수도 있고, 처음 듣는 얘기일 수도 있다.

이렇게 수박 겉핥기로 쓰윽 프로젝트 전체 모습을 스케치한 것은 프로젝트의 전체적인 사이클을 아는 게 그만큼 중요하기 때문이다. 프로젝트가 어떤 사이클을 가지고 있다는 걸 인식하는 PM과 그렇지 않은 PM은 각 단계별로 자신에게 주어지는 일을 처리하는 퀄리티에 차이가 날 수밖에 없다.

다음 시간에는 이렇게 스케치한 프로젝트 전체 모습을 바탕으로, 실제 프로젝트 상황을 상정해, 자세하게 알아보는 시간을 가져 보도록 하겠다.

초하류

편집: 딴지일보 챙타쿠