SI프로젝트에서 업무이해와 의사소통

  요즘 SI 개발업체 인력운영의 가장 큰 특징은 수행조직을 철저히 분업화하여 운영하는 것이다. 따라서 PM 및 사업관리를 제외하고는 다른 팀원들은 전체 프로젝트 기간에 투입되지 않는다. 아마도 인건비 절약이 가장 큰 이익조건이 되기 때문일 것이다. 우선 PL 및 상당한 기간의 유경험자(중급 개발자 이상)가 설계를 하고 설계에 대한 승인이 나면, 단순 코딩을 하는 일반 개발자들이 투입된다. 좀 더 규모가 크거나 예산이 풍부할 경우 또는 예산이 풍부하고 갑, 을 모두 프로젝트 성공에대한 열망이 대단한 경우 테스트 전담인력을 마지막에 투입한다.

 

  SI 업체의 경영적인 측면에서는 보기 좋을지 모르겠지만, 수행팀 입장에서는 생각보다 프로젝트가 쉽게 진행되지 못한다. 원인이나 고려해야할 사항이 여러가지가 있겠지만 여기서는 단순히 인력 운영 측면에서만 생각해 보자. 이론적으로는 설계자 따로 개발자 따로가 맞을 수도 있다. 하지만 실제로는 그 업무에 대한 이해도 및 전체적인 흐름에 대해서는

프로젝트 참여자 모두가 충분히 인지하고 있어야 한다.

 

  정말 파트 타임으로 투입되도 되는 디자이너 부터 단순히 문서나 경비를 관리하는 사업관리 조차도 그 프로젝트의 특징과 업무를 이해해야 한다. 이를 위해 요즘 유능한 PM 은 파트별로 단계적 투입이 되는 현실을 적응하기 위해 설계가 끝나면 각 모듈별로 개발자를 배정하고 그에 따른 교육을 실시한 후, PL 외 다른 설계를 철수시킨다. 그리고 테스트시에는 개발인원 전체를 참여시켜 수행한다.

 

  하지만 여기엔 복병이 하나 도사리고 있다. 요구분석시 과업이 늘어나건, 추가요구사항이 나왔건 간에 일정이 지연될 경우이다. 건축이나 제조 등 다른 프로젝트에서는 보기드문 SI 프로젝트에서만 특징이 있다. 일정지연에 대한 해결책으로 가장 단순한 방법이 인력을 더 투입하는 것이다. 하지만 SI 프로젝트에서는 이 해결책이 잘 안통한다. 왜냐하면 그 업무를 이해하고 그 프로젝트만이 갖고 있는 표준을 익히고 해야 본격적인 개발에 들어갈 수 있기 때문이다.

 

  이를 거의 40년 전에 IBM 에 다니던 부룩스(Frederick P. Brooks)라는 사람이 예견했다. 이른바 브룩스의 법칙이다.

" 의사소통 때문에 발생하는 지연은 어떤 팀에 있는 인력수의 제곱에 비례한다 . 늦은 프로젝트에 인력을 추가로 투입하면 오히려 더 늦어질 뿐이다"

 

  

 

브룩스 교수가 그의 저서  멘먼스 미신(Mythical Man-Month, 1975년에 발행된 책이다)책에서 밝힌 내용이다. 브룩스는 당시(1950년대) IBM 에서'시스템/360'의 OS인 OS?360을 개발하는 관리자였는데, 타사의 경쟁 제품이 더 빨리 출시될 것이라는 소식을 들었고, 이에 대한 해결책으로 인력을 더 투입했음에도 지연되자, 그 이유를 깊이 고민하다가 인력투입과 개발기간 간에 상관관계를 알아냈다. 만약 복잡한 프로젝트를 진행중에 있고 그 소요공수는 12MM 라고 가정하에, 타사의 경쟁 제품이 더 빨리 출시될 것이라는 소식을 들었다면, 브룩스를 제외한 다른 프로젝트 관리자들은 12명의 프로그래머를 스카우트 하고 이들이 한 달 동안 일을 하면, 한명이 12개월 일한 것과 동일하므로 해결이 될 것이라고 할 것이다.

하지만 브룩스는 다른 결론을 얻었다. '지연되는 프로젝트에 인력을 더 투입하면 오히려 더 늦어진다.'

  이것이 브룩스의 법칙이다. '1개발자 X 12개월 = 12개발자 X 1개월'이 아니라는 것을 깨달았다. 개발자를 추가할수록 그들 사이에 미팅, 인터페이스 합의, 이메일 송수신 같은 커뮤니케이션 비용이 월등히 증가하게 되고 커뮤니케이션의 빈번한 오류로 원상태로 수정 작업을 하는 일들이 자주 발생하여 더욱 지연되는 현상을 겪게 되었기 때문이다. 이에 대해 브룩스는 지연되는 프로젝트를 원래 일정대로 진행하려면 인력을 더 추가하는 것이 아니라, “개발하기로 약속했지만 아직 완성하지 못한 기능”을 없애는 것이 합리적인 방법이며, 프로젝트의 범위를 조절함으로서 일정을 제어해야 한다고 주장했다.

 

  그러나 우리 현실에서 이렇게 봐줄(?) 고객이 없기 때문에 다른 대안을 생각해야 한다. 우리가 흔히 쓸 수 있는 방법은 예상되는 추가인력에 대한 비용을 인센티브로 제시하고 기 투입된 인력들에게 좀더 능률을 내고 작업시간을 연장할 수 있도록 하는 것이다.

 

  과거 진행했던 프로젝트가 있었다. 원인이 무엇이든 상당히 심각하게 지연되었을 때다. 당시 사업관리는 이에 대해 필요한 소요공수를 제시하였는데, 나와 해당 과업의 PL은 인력추가보다 그 예산을 확보한 다음 인력들에게 금전적인 보상을 약속하는 방법을 쓰고자 했다. 하지만 각 개발자의 리더들을 설득하는 것에 실패했고, 투입된 PMO 역시 아주 단순한 해법인 인력을 추가하라고 요구했으며, 고객은 그 PMO 손을 들어줬다. 

하지만 위에서 브룩스 교수가 업급한 것처럼, 일정이 단축되기는 커녕 테스트도 불안했고, 일정은 추가투입 전 지연 예상 기간만큼 늘어났다.

 

  즉, 우리가 할 수 있는 대안은 반드시 개발자이 희생을 설득하는 전제 조건이 필요한 만큼 프로젝트 범위를 조절할 수 있도록 관리 및 근거 자료를 잘 만들어 놓아야 한다고 생각한다.