크게 세파트로 나뉘었던 프로젝트 진행중에, 다른 파트의 일,8본을 네사람이(새로 추가된 사람 포함) 나눠서 할일이 생겼다.
그리고, 전형적인 문제점을 발견하게 되었고,떠오른 게 바로 Fred Brooks의
The Mythical Man-Month.
정확히 동일한 문제는 아니지만 내가 말하고 싶은건 바로 Communication의 문제이다.
아마 해당 파트의 담당자가 맡았다면 넉넉잡고 반나절이면 모두 다 개발했을것이고,뭐가 문제인지도 단숨에 알았을것이다.
하지만, 새론 투입된 네사람은 다른 사람의 소스를 이해할 시간도 필요하고,
더군다나 투입된 네사람중 한사람은 전혀 처음인 상태인 상황에서 관련 담당자를 찾아다니면서 물어야할 상황이다.
개발사양서의 품질은 최악이고,품질에 대한 담당자는 메일하나 보내는 역할만을 하고 있다.
자 그럼,
어떻게 Communication을 할것인가.어떻게 Communication을 할것인가.어떻게 Communication을 할것인가.
당연(?)하게도 일정은 밀렸다.한사람 8본 반나절 vs 네 사람 8본 2틀~3일 이다.
다시 The Mythical Man-Month,
Assigning more programmers to a project running behind schedule will make it even later, due to the time required for the new programmers to learn about the project, as well as the increased communication overhead. When N people have to communicate among themselves (without a hierarchy), as N increases, their output M decreases and can even become negative (i.e. the total work remaining at the end of a day is greater than the total work that had been remaining at the beginning of that day, such as when many bugs are created).
* Group Intercommunication Formula: n(n − 1) / 2
* Example: 50 developers -> 50(50 − 1) / 2 = 1225 channels of communication
늦어진 프로젝트에 사람을 더 투입할때, 더 늦어질수도 있다.간단한 예지만 실제로 더 늦어졌다, 그것도 한참~
흔히 말하는 이 프로젝트 관리 분야의 명저라고 일컫는 서적들을 읽어봐도 명쾌한 답이 없다.
걔중엔 전혀 현실적이지 못한 중,소규모 프로젝트에나 적용될법도 말법도 할만한 것들만 많다.
또 다시 어떻게 Communication을 할것인가.
한번,티핑포인트식에서 분류한 세 단계의 Commnunicator를 써보면 어떨까 싶다.
- 커넥터(Connector) : 많은 이들을 알고 있는 사람으로 정보를 전파하는 역할
- 메이븐(Maven) : 정보를 공유하고 교환하려는 사람으로 정보의 전달자 역할
- 세일즈맨(Salesman) : 불확실한 정보를 능수능란하게 설득하는 역할
실제로 이렇게 점점 각 파트별로 정치,책임,성과 등의 역학관계가 복잡한 대규모 프로젝트라면
위 처럼 Commnunicator의 역할을 세분화 시켜보는것도 의미있는 작업방식일것 같다.
ps
새로 투입된 넷중의 한사람이 나다,만일 협업하는 파트의 사람들과 원만한 관계가 아니었다면,
그리고 같이 참여한 업체들끼리 협업이, 이게 개인적으로든 회사적으로든 , 매끄럽지 않다면 문제는 대단히 심각해졌을꺼다.
사실 위와같은 문제가 본질적인 문제중의 하나다.
그리고, 투입된 인력들이 양산해(?)냈을 법한 버그는 고려하지 않았다.사실 이건 더 심각한거다.ㅋ
