iamyhs

크게 세파트로 나뉘었던 프로젝트 진행중에, 다른 파트의 일,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
새로 투입된 넷중의 한사람이 나다,만일 협업하는 파트의 사람들과 원만한 관계가 아니었다면,

그리고 같이 참여한 업체들끼리 협업이, 이게 개인적으로든 회사적으로든 , 매끄럽지 않다면 문제는 대단히 심각해졌을꺼다.

사실 위와같은 문제가 본질적인 문제중의 하나다.

그리고, 투입된 인력들이 양산해(?)냈을 법한 버그는 고려하지 않았다.사실 이건 더 심각한거다.ㅋ

현재 진행형인 프로젝트의 총 개발리더의 입장에서,뷰단을 바라본다면 과연 이 프로젝트가 성공적으로 가는 프로세스인가,아니면 그 반대인가.

거의 900명에 육박하는 이정도 규모의 프로젝트는 앞으로도 접하기 힘든 프로젝트 일것 같다.

이런 대규모의 프로젝트의 전형적인 문제들인 커뮤케이션,의사결정,정치역학,인력관리등등의 논외로 하고, 내가 속한 뷰단에 초점을 맞춰보고 싶다.

프로젝트 초반에(현재는 중반에 접어들고 있는 시점이라 본다) 총 책임자의 골짱,몸짱,얼짱 이란 표현이 무척 와닿는다.

내 관점으로 재 해석하면 골짱의 역할은 모델링이고, 몸짱의 역할은 프로세스이고, 얼짱의 역할은 플렉스이다.


과연, 골짱과 몸짱과는 별개로 얼짱이 될수 있을까?
과연, 골짱,몸짱,얼짱이 효과적으로 분할 및 통합의 프로세스가 이뤄질수 없나?
과연, 얼짱을 위한 골짱(데이타 모델링)이 필요할까?
과연, 얼짱다운 화면이란건 뭔가?


솔직히 순서대로,

없다.
    아주 순진한 원론적인 이야기 이다.이중적이게도,현실에선 이렇게 할수 있는 방법을 찾아내야 한다.

있어야 한다.
    현실적으로,이건 기술의 문제라기 보다는 조직의 구조적인(커뮤니케이션,정치역학등) 인자에 더 영향을 받는것 같다.
    이 정도 대규모라면? 복잡다단하다.

없다.
    용어도 생소한 UI 컨설턴트중에는 뷰단을 위해 모델단의 변경을 말하는 이들이 있다, 꼬리가 머리를 흔드는 꼴이다.

시행 착오중이다.
    한도 끝도 없는 주제이다.
    이 부분은 선택한 기술과는 무관한 부분이 더 많다고 생각한다.플렉스 다운 화면이란 말에서, 플렉스를 다른 신기술 용어로 대체해보라.


다시 내가 총 결정권자이라면

과연 뷰단의 솔루션으로 선택한 플렉스가 올바른 선택인가?

개발편이성,유지보수성,비용면 등등에서 상대적 우위를 차지하고 있나? UI 가 이쁜건 알고 있으니 고만해라.

지금까지 내린 부분적 결론은 성급한 선택이었다.

현 시점에서 얼짱 역할을 맡은 뷰단은 기묘하게 성형수술을 시도한 추녀같다.수술비용도 만만치 않지만,아마 나중에는 코가 주저앉을지도 모른다.



아침에 Ryan Stewart 포스팅에 링크된  Flex Interface Guidelines 을 보다 문득 들었던 생각을 적어본다.

그리고, 다시 DATA MODELING FUNDAMENTALS A Practical Guide for IT Professionals - Paulraj Ponniah  pdf를 보고 있다.


ps
한달전쯤에 WallMart 의 GXXX 시스템의 구축의 프로젝트를 설명하면서 자사의 솔루션을 소개하러 HP 차장님 세분이 강좌를 한적이 있었다.

'EIS 같은 기보적인(?) 수준에서, IDM,EDW,DPP ' 도표를 보여주면서, 상당히 깊이있게 번갈아 가면서 진행을 했었다.

커뮤니케이션 문제를 어떻게 풀었냐는 질문에,총 리더와, 부 리더, 그리고 그 밑의 7개파트(?) 정도의 중간 리더가 프로젝트 전반에 걸쳐서 지속적으로 협력햇었다 라는

아주~ 일반적인 답변을 들었다.

대규모 프로젝트의 접근방식은 말 그대로 특화된 방법론이 필요한것 같다.수준이,차원이 틀리다.