프로젝트 관리자(PM)의 역할. 고객 요구와 하위 개발 단위 안정성

프로젝트를 관리한다는 것은 계약 또는 결정된 프로젝트 내용의 목표를 달성할 수 있도록 실행 작업 과정을 관리한다는 말이 됩니다. 이는 개발과 관련은 있지만 정확히 개발은 아닌 분야이며, 기획과 관련이 있지만 정확히 같지는 않습니다. 하지만 프로젝트 관리자의 고객 요구에 대한 결정은 진행될 하위 개발 단위에 영향을 미치는 것은 확실합니다.

 

 

 

프로젝트 관리자 

 

흔히 PM(프로젝트 관리자 영어명의 약자)이라 불리는 프로젝트 관리자는 프로젝트가 완료될 수 있도록 관리하는 사람입니다.

 

그런데 프로젝트가 정확히 무엇인지 모른다면 관리를 할 수 없습니다. 그러므로 일반적으로 PM은 해당 프로젝트 관련 분야를 잘 아는 사람에게 맡기는 경우가 많습니다.

 

문제는 인사/조직 관리 차원에서 관련 프로젝트에 참여한 경력이 풍부한 것과 관련 프로젝트를 관리할 수 있다는 것은 인과 관계가 거의 없다는 사실입니다. 

 

예를 들어 인사/조직 관리 측면에서 높은 성과를 내던 직원을 관리자로 승진하는 경우 실패하는 케이스도 종종 나타나는 것을 알 수 있습니다. 이는 실무 측면의 능력과 관리 측면의 능력이 다르기 때문입니다.

 

이러한 이유로 꼭 해당 프로젝트 관련 분야에 일을 했다고 프로젝트 관리는 잘한다고 단정할 수 없는 것입니다.

 

여기에 부분 최적화와 전체 최적화의 문제 때문에 외주 개발 프로젝트 시 꼭 경험 많은 개발자가 좋은 PM이 되는 것은 아니라는 사실을 생각할 수 있습니다.

 

실제 각 하위 단위 기술 리딩과 관련하여는 단위 프로세스를 리딩하는 PL이 존재합니다. 

 

이러한 점에서 프로젝트 관리(PM)는 꼭 실무의 각 부분을 잘 수행할 수 있어야 하는 것은 아니라는 사실을 생각할 수 있습니다.

 

이점이 IT 개발의 경우 풀스택 개발자가 최고의 PM이라는 가정이 성립되지 않는 이유기도 합니다.

 

단, 문제가 되는 것은 프로젝트 범위와 내용도 모를 때인 것입니다. 이 경우 프로젝트 관리가 근본적으로 불가능하기 때문입니다.

 

 

 

 

관리와 프로젝트 최적화 이슈

 

일반적으로 프로젝트의 경우 하나의 공정만으로 완성되는 경우는 극히 희박합니다. 전체 프로젝트 프로세스는 여러 하위 공정을 통해 진행되며, 이 하위 공정들은 각각 연결되어 조화가 필요하게 됩니다.

 

프로젝트 관리의 문제는 여기서도 나타납니다. 바로 R&R 문제인 것입니다.

 

두 개의 하위 공정이 연동될 때 명백히 구분되는 작업 과정도 존재하지만, 모호한 영역도 존재하게 됩니다. 바로 이 영역의 처리 문제가 두 개의 하위 공정의 조화 이슈로 등장할 수 있습니다.

 

전체 시스템 측면에서 어떤 선택을 할 경우 두 개 하위 공정 중 한 공정은 더 많은 일을 해야 할 수도 있습니다. 심지어 이 일이 기존 작업에 비해 난이도가 더 높은 일이 될 수도 있습니다. 여기에 추가된 업무의 배분 문제는 기본 작업 진행 구성에 영향을 줄 수 있습니다.

 

이로 인해 때에 따라서 업무를 배정받은 단위 공정의 작업 안정성은 현저히 저해될 수도 있습니다.

 

문제는 이런 상황을 미리 대비하기는 매우 어렵다는 것입니다. 

 

각 공정 파트 PL은 명백한 자신의 파트 공정에 대한 계획만을 수립하려 합니다. 다른 PL이 담당하는 단위 공정과 연동되는 영역의 애매한 부분을 굳이 자신의 파트로 넣지 않습니다. (여러 이유가 있지만 일단 애매한 부분은 빼고 작업 계획을 세우는 경우가 대부분입니다. 그리고 최대한 방어를 하는 경향을 보입니다. 물론 조직 내 이해관계를 파악하여 높은 가능성을 가진 경우 대비는 할 것입니다.)  

 

여기서 프로젝트 관리자(PM)에게는 전체 프로젝트 프로세스와 하위 프로세스 간 또는 하위 프로세스와의 갈등이라는 이슈가 발생하는 것입니다.

 

보통 이러한 이슈는 WBS를 통해 표면화됩니다.

 

결국 계약 기준 전체 프로세스는 PM 소관이겠지만, 하위 단위 공정의 프로세스와 하위 공정 간의 연동 관련 이슈로 인한 기간 필요성은 또 다른 계획/설계(여기서 계획/설계는 개발이 아닌 프로젝트 관리 기준입니다.) 협의 사항이 됩니다.

 

정리하면 프로젝트 전체 기준의 최적화와 하위 단위 공정 기준 프로젝트는 동일 목표를 향해 있지만 갈등이 있을 수밖에 없는 다른 영역의 최적화라는 사실입니다.

 

   

 

개발 안정성 이슈

 

여기서 본격적인 개발 안정성 이슈가 등장하는 것입니다.

 

멀리서 산을 볼 때와 산에 들어가 나무를 볼 때 광경은 너무 다릅니다. 프로젝트를 진행하면서도 전체 프로젝트 기준으로 볼 때와 각각의 단위 개발 관점에서 볼 때 전혀 다른 프로젝트를 보게 된다는 것을 의미합니다.

 

그래서 좋은 개발자, 기획자, 디자이너가 경력이 많다고 좋은 PM이 되는 것이 아닌 것입니다.

 

여기서 특히 외주 개발 프로젝트의 경우 고객 요구 사항 기반으로 작업/관리가 진행됩니다.

 

프로젝트 전체를 기준을 보면 어떤 방식을 취하든 고객 요구 사항에 대한 개발을 완료하면 됩니다. 그러나 단위 개발 공정에서는 어떻게 개발할지에 대한 결정은 단위 업무량과 난이도를 결정하게 되는 것입니다.

 

다시 고객이 요구를 바꾸거나 추가하는 경우 이는 기존 개발 진행 방식에 따라 심각한 개발 수정을 해야 하는 상황이 될 수도 있습니다. 그러므로 PM이 개발 도중 고객 요구를 수용하는 것은 심각한 개발 안정성에 영향을 미칠 수 있는 것입니다.

 

문제는 프로젝트 관리 또는 영업 차원에서 이러한 개발 중간 고객 요구를 마냥 무시할 수는 없다는 사실입니다.

 

이러한 부분을 프로젝트 관리에서는 외부 시스템과의 갈등 관리할 합니다. 이는 프로젝트 하위 공정 간 갈등을 관리하는 것도 또 다른 영역의 관리 영역입니다.

 

이 외부(고객) 갈등을 관리하기 위해 경험 많은 프로젝트 관리자는 다양한 전략/전술을 활용합니다. 때로는 회사의 임원이나 영업 담당자를 끌어들이기도 하고, 게약 요소와 기간에 대한 부분을 지적하기도 합니다. 그럼에도 마냥 추가되는 요구를 무시하기는 어려운 것이 국내 갑을 관계입니다.

 

하지만 어떻게 수용하느냐에 따라 추가 요구 이후 진행되어야 할 하위 공정의 안정성에 영향을 미치게 됩니다.

 

수용 방법에 따라 고객은 너무 고마워할 수도 있습니다. 그러면 기간이 늘어나거나 다소간의 개발 문제가 발생해도 이를 자신의 요구 때문이라 생각할 것입니다.

 

그러나 수용 방법에 따라 고객은 당연하게 생각할 수도 있습니다. 이 경우 전체 프로젝트 로드는 늘어나고, 기존 개발 방식과 충돌하는 요구의 경우 단위 공정 안정성도 영향을 받게 됩니다. 이로 인해 개발 안정성과 기간은 나빠집니다. 그러나 고객은 이를 개발사의 실력이 부족한 때문이라 생각할 것입니다.