프로젝트 매니저(PM, Project Manager), 오해

프로젝트 매니저에 대한 오해

당신의 머리속에 프로젝트 매니저(PM, Project Manager) 하면 어떤 이미지가 떠오르는지 궁금하다.

• 개발 잘 못하는 사람, 하루 종일 문서만 쓰고 있는 사람

• 젊어서 개발하다가 어느 정도 나이가 되면 어쩔 수 없이 맡게 되는 직책

• 나는 평생 매니저 안되고 코딩하며 개발자로 살고 싶다는 동료 개발자들의 말

• 내 커리어에 별로 도움이 안되는, 이력서에 뭘했다고 적을게 없는 일
  
  

내가 만난 많은 개발자들이 프로젝트 매니저 하면 대게 저런 것들을 떠올린다. 사실 현실에서 전혀 틀린 말은 아니지만 프로젝트 매니저가 해야하는 중요한 일과 가치를 바라보지 못하는 편향된 시선, 곧 오해가 아닐까?

왜 이런 인식이 팽배할까?

나는 이런 인식이 프로젝트 매니저의 Job Description 에 대한 분명한 정의와 이해의 부족 때문이라는 생각이 요즘 많이 든다. 그래서 틈틈이 나의 실제 경험 안에서 프로젝트에서 무엇이 매니지먼트되어야 하는지 하나씩 정리해 보려고 한다.

오늘은 우선 세세한 매니지먼트 항목들에 대해 살펴보기 전에 매니지먼트란 무엇을 매지니먼트 하는 것인지 전체적인 큰 그림을 그려보고, 매니지먼트의 근본이 되는 개념들에 대해 먼저 정리해 보려고 한다.

무엇을, 매니지먼트 하는가?

프로젝트를 매니지먼트 한다는 것은 무엇을, 매니지먼트 한다는 것일까? 나는 이렇게 생각한다.

• 고객의 필요를 관리한다.

• 프로덕트의 전체 요구사항을 관리한다.

• 프로덕트의 요구사항이 어떻게 구현될지에 대한 설계사항을 관리한다.

• 프로덕트 요구사항이 구현될 일정을 관리한다.

• 프로덕트 요구사항이 어떻게 검증될지에 대해 관리한다.

• 고객의 필요가 프로덕트에 반영되어 구현되고 검증되고 있는지 관리한다.

• 프로덕트가 어떻게 고객에게 배포될지에 대해 관리한다.

너무 뻔한 답일까? 가장 기본적인 것에 대한 매니지먼트의 부재가 늘 큰 문제를 가져오는 듯 하다. 프로젝트 매니저는 프로젝트의 전 주기 (분석-설계-구현-시험-배포) 동안 각 단계 별로 적절한 매니지먼트를 수행해야 한다. 이것은 우리가 폭포수 모델 개발 프로세스를 따르던, 전체 개발 주기가 빠르게 반복되는 애자일한 프로세스를 따르던 분석-설계-구현-시험-배포 각 요소는 어떤 형태로든 반드시 존재한다는 사실에 근거한다.

매니지먼트의 근본 개념

위에서 말한 무엇을, 매니지먼트 함에 있어서 항상 아래의 근본적인 개념들을 생각하게 된다.

매니지먼트란,

• 분명하지 않은 것을 분명하게 정리하고, 그것을 가시화(문서화) 하고, 팀과 공유하는 것이다.

• 불확실한 내일을 위해 오늘 무엇을 할지 결정하고, 팀과 공유하여 팀과 함께 행동하는 것이다.

• 정해진 시간 내에 달성가능한 최선의 결과와 과정을 찾는 것이다.

• 최고의 효율로 일 할 수 있도록 업무를 정리하여 나누고, 나누어진 업무를 다시 통합하는 것이다.

• 최고의 효율로 일 할 수 있도록 적절한 자원(사람, 비용, 도구 등)을 선택하고 분배하는 것이다.

나의 삶

요즘 큰 프로젝트의 PM으로 일하며 참 힘들다는 생각을 많이한다. 큰 규모의 프로젝트 PM 역할을 처음해보는 탓이기도 할 테다. 빡빡한 일정 아래 모든 것이 쉽게 관리되지 않고 때때로 운에 맡겨진 채 프로젝트가 진행되어 간다는 느낌을 받아 불안하기도 하다. 지금도 달려가고 있지만 지나간 팍팍했던 시간들을 돌아보니 아, 그 때는 이랬어야 했고, 또 그 때 이건 내가 참 잘했구나 하는 것들이 선명하게 보이는 것 같다. 그래서 정리해보고 싶어 졌다.

시간이 허락될 때 조금씩 조금씩 정리해 봐야 겠다.

그래서 프로젝트 매니저의 역할이 조금더 선명히 정리되고, 공유될 수 있었으면 하는 바램이다.