Joypia

팀 구성하기 본문

PM Story

팀 구성하기

Laughing Stone 2020. 10. 7. 14:56
반응형

  PM이 가장 먼저 신경쓰는 것이 팀원 구성이다. 그리고 그 구성된 팀원을 어떻게 잘 이끌어 가는가가 프로젝트의 성패를 좌우한다. 팀원이 구성되는 경우는 대게 3가지 경우이다.

 

-  PM의 의사와 상관없이 팀원이 구성되는 경우,

- 어느 정도 자기가 원하는 팀원으로 구성되는 경우,

- 팀원의 일부 또는 전부가 계약직(프리랜서)으로 구성되는 경우 이다.

 

  두번째를 제외하고 첫번째와 세번째는 PM 입장에서 여간 난감한 게 아니다. 우선 쉬운 두번째의 경우를 보자,

이런 경우는 보통 회사 사정이 여유가 있을 때 발생한다. 사업을 준비하는 단계부터 PM 으로 내정되고, 자기와 소통이 잘되고 실력 있는 팀원을 물색하여 해당 팀원의 동의도 받아 놓을 정도로 준비과정 부터 탄탄하다. 여기엔 PM의 리더로써 자질만 있으면 좋은 팀워크를 이룰 수 있다. 즉, 프로젝트가 성공할 가능성이 매우 높다.

 

  과거에 겨우 코스닥에 상장한 SI 전문업체에서 사업부장을 할 때, 유능한 PM 은 준비하고 있는 프로젝트에 브리핑을 하면 바로 팀워크에 대해 생각하고는 자기가 맘에 들어하는 개발자를 직접 섭외한다. 그리고는 그 수를 많이 확보하기 위해 그 개발자가 직접 나에게 그 프로젝트에 참여하게 해달라고 말하게 하곤 했다. 그 PM이 맡은 프로젝트가 무난하게 성공적으로 완료되었던 것은 두말할 나위 없었다.

 

  물론 이 경우에도 실패 요인이 있다. 너무나 서로를 잘 아는 나머지 '알아서' 잘할 것이라고 내버려 두는 경우다. 아무리 호흡이 잘 맞는다고 할지라도 PM은 반드시 체크하는데 게을리 해서는 안된다.

 

  그다음 앞에서 말한 문제의 경우를 들어보자. 나머지 두 가지 중 그래도 자사 인력으로 구성되는 경우가 그래도 낫다.

PM 의사와 상관 없이 팀원이 구성되는 경우는, 그 PM 이 사업을 준비하고 있는 동안 프로젝트를 수행하고 있었던 경우이거나 PM 의 요구가 받아들여 질 수 없는 특이한 경우이다.

 

  특이한 경우는 그 예가 매우 많다. 프로젝트 성격상 특정 개발자로만 구성된다든가, 내정된 PM 의 갑작스러운 사고라든가... 그 중에 가장 않좋은 경우가 있는데, 바로 개발자 들이 그 PM 과 일하기를 꺼려하는 경우다. 이 경우 사실 그 PM 은 아무리 실력이 뛰어나도 내보내야 한다. 회사 사정상 그럴 수 없는 경우 발생하는데 리더로써의 자질을 배양할 수 있도록 회사에서 투자를 하든가 해야 한다. 만약 인격적 또는 정신적 문제가 있다면 반드시 해고를 고려해야 한다. 방치했을 때의 그 피해는 훨씬 크다. 

따라서 PM 이거나 또는 PM 이 될려면, 인간성이나 인격적으로 성숙하고 원만하여야하며, 행동에도 주의를 기울여야 한다. 이 때는 빨리 팀원을 파악하여야 한다. 그 개발자와 일한 경험이 있는 동료를 얼마든지 접촉할 수 있으니 신상파악은 그리 어렵지 않을 것이다. 그리고 그에 맞춘 업무 분담을 하고, 프로젝트 초기에 의견 교환에 대한 규칙을 세워 의사소통에 만전을 기해야 한다.

 

 

  PM은 자기와 일한 개발자의 신상정보를 반드시 노트해 놓아야 한다. 고객 중에 노동부 산하기관의 한 과장은 자기와 일한 모든 업체의 개발자들의 특징과 신상을 기록해 놓고는 프로젝트 협상시 자기가 원하는 개발자가 투입되게끔 업체를 괴롭혔다. 그 과장이 그 기관에서 인정받는 것은 두말할 나위 없었다.

 

  마지막으로 다수의 프리랜서가 팀원으로 구성된 경우다. 만약 프리랜서를 통제하지 못한다면, 그 PM은 아직 멀었다.

최근에 마친 프로젝트에서도 많은 PM 들이 겨우 한두 명의 프리랜서들을 통제하지 못해 어려움을 호소하곤 했는데, 참으로 안타까운 일이었다. 그 프리랜서들은 적당히 일하고 정규직 직원보다 더 많은 돈을 가져갔다. 그 것이 요즘 프리랜서들의 특징이라고 핑계를 되곤 하는데, 전혀 아니다. 내 경험에 의하면 프리랜서들도 전력을 다해서 일한 경우가 훨씬 많다. 야근과 휴일 출근도 기꺼이 따라 주었다.

 

  프리랜서는 프린랜서로써 대우를 해야한다. 즉 업무량을 배분하고 그 업부가 완료될 수 있도록 확실히 통제해야 한다.

프리랜서 본인이 그 일을 책임지고 야근을 해서라도 끝낸다면, 팀워크를 이룰 수 있으므로 같이 갈 수 있지만, 그렇지 않고 불만이나 토로하며, 오히려 팀 분위기를 해친다면, 바로 교체해야 한다.

특히 PM은 더욱 많은 신경을 써야한다. 프리랜서 혼자 또는 그들 끼리 밥을 먹게 해서는 안된다. 모든 일에 정규직과 같이 동참하게 해야한다. 어느 회사는 명절날 정규직만 선물을 주거나 또는 따로 선물을 마련하는 경우가 있는데, 회사에 건의해서 정규직과 같은 선물을 주도록 하는 것이 좋다. 만약 자기들끼리 모여서 대화-대화 내용이 무엇이든 간에-를 하는 것이 목격되거나, 다른 개발자에게 불평을 하였다면, 지체없이 조치를 해야한다. 만약 조금이라도 내버려 두었다면 팀워크는 이미 무너지고 있다고 봐야한다.

 

 

  2005년도 교유부 산하기관에서 프로젝트를 할 때이다. 나는 거의 프로젝트 중간기간(투입 후 일주일 후에 중간감리가 있었다)에 투입되었는데, 이미 프로젝트는 엉망이 되어 있었다. 처음 투입된 정규직은 한 명을 빼고 모두 퇴사하였다. 할 수 없이 프리랜서로 대체해야했는데, 너무나도 어려웠다. 다행히 운이 좋아 최종적으로 투입(1~2주만에 그만두는 프리랜서들이 많았다)된 프리랜서들이 전력을 다해 주어서 그나마 기간안에 마무리 할 수 있었다. 지금도 그 친구들의 고마움은 잊지 못한다.

반응형

'PM Story' 카테고리의 다른 글

공공SI 프로젝트 사업관리를 위한 체크리스트  (0) 2020.10.08
SI 프로젝트에서 약속의 속성  (0) 2020.10.08
일정계획 세우기  (0) 2020.10.07
사업관리 수명 주기  (0) 2020.10.06
회의록 작성하기  (0) 2020.10.06
Comments