'방법론의 기여'와 '포수의 리드가 팀에 부여하는 기여'

영리한 포수는 팀의 실점을 줄이는가?
포수의 리드 공헌도를 평가하기 어려운 이유에 대한 글이다.

방법론의 기여가 '포수의 리드가 팀에 부여하는 기여'와
일맥상통하는 부분이 많다는 점에서 통찰을 얻기 위해 방법론 용어로 변환해 봤다.0.0


-------- 여기서부터 변환된 내용 -----------

개별 방법론의 우수성을 프로젝트 실패율과 같은 것으로
비교하거나 평가하는 것은 상당히 어려운 문제다. 왜냐하면 이런 문제가 있기 때문이다.

1) 한 프로젝트를 표본으로 삼는다 해도 표본의 숫자가 충분하지는 않다.
2) 대부분의 팀에서 방법론은 한가지를 채택하고 그것으로 끝까지 추진한다.
   즉 2개 이상의 방법론을 같이 측정할 만한 표본이 부족함.
3) 가장 중요한 것인데 서로 다른 두 방법론을 같은 수행팀이 추진 했다고 해도
   수행팀의 컨디션(환경)이라는 요인이 더 중요
4) 프로젝트 실패율이나, 제안 대비 지연된 개월 수 등은
    PM과 방법론을 제외한 PL을 비롯한 개발팀의 영향을 많이 받는다.

1번과 2번은 '방법론의 공헌도'를 기록으로 측정할 때 부딪히는
가장 기초적인 문제이며 3번이 의외로 중요한 의미를 제공하고 있다고 본다.
왜냐하면 프로젝트 환경이라는 요인이 더 중요한 것처럼 기록이 나온다는 것 자체가
사실은 '방법론의 공헌도'가 프로젝트팀의 실패율을 낮추는 데
별로 도움이 되지 않을지도 모른다는 사실을 방증하고 있기 때문이다.

즉, 방법론의 가이드가 
프로젝트 환경 변화나 도메인, 상대 고객의 라인업이나 전력 등
다른 요소에 비해 눈에 띌 만큼 프로젝트에 중요한 영향을 미친다면
그만큼 눈에 띄는 기록으로 구현되어야 한다. 굴뚝을 때면 연기가 나야 한다. 그런데 별로 그런 것 같지는 않다.


2008년 현재까지 상황별 기록이 전무한 한국SE는 물론이거니와
북미,유럽,일본 등에서도 이 문제는 충분히 해소되지 않은 것으로 보인다.
agile, up evangelist들도 이 문제는 우물쭈물하면서 넘어가는 경향이 있기 때문이다.

지금까지 그네들이 내놓은 결론의 경향을 살펴보면,

1) (앞에서도 했던 말이지만) 기본적으로 표본이 충분하지 않다.
2) 방법론의 공헌도를 측정하기에 프로젝트 드랍 방어율이나
   기타 전통적인 지표들이 적합한가도 사실 의심스럽다. (어쩌라고. -_-;)
3) 그럼에도 불구하고 굳이 분석을 하자면 단일 프로젝트를 기준으로 삼으면
   방법론에 따라 PM이 갈리는 횟수가 조금씩 달라지는 경향이 존재한다.
   그러나 웃긴 것은 단일 프로젝트에서 PM이 갈리는 횟수를 많이 낮춰 준(?) 방법론이 
   다른 프로젝트에서는 드랍, 수개월 지연, 법정공방을 야기시킨 주범의 하나로 전락하고,
   드랍된 프로젝트의 방법론이 또 다른 프로젝트에서는 갑자기 엄청난 이슈해결의 명수가 되는 등
   널뛰는 경향(fluctuation)이 적지 않다.
4) 이상을 종합해 보면, 발전된 방법론이 전통적 방법론보다
   프로젝트를 잘 끌어갈 능력이 있는가 없는가는 모르겠으나
   그러한 능력이 SE에서 구체적으로 합당한 기록이나 통계로 구현되는 것 같지는 않다.
   즉, 그런 능력이 있는지 의심스럽다. 설혹 있다고 해도 게임에서 써먹을 만한지는 모르겠다.

별 도움 안 되는 예로는 현재 우리나라에서 가장 높은 평가를 받고 있으며,
은퇴한 waterfall를 가볍게 제낀다고 많은 사람들이 (함부로) 여기는 rup와 agile을 들 수 있다. 
2006년에서 2008년까지 rup와 agile의 성적 비교.
최근 3년의 기록을 구한 것은 기록을 구할 수 있는 범위가 딱 거기까지이기 때문.

흠 역시 명불허전의 rup야.
2006년 rup 804프로젝트 - PM갈린 횟수 3.67
2006년 agile 243프로젝트 - PM갈린 횟수 4.73

별 차이가 없긴 한데... 
2007년 rup 927프로젝트 - PM갈린 횟수 3.26
2007년 agile 207프로젝트 - PM갈린 횟수 3.22

어라?
2008년 rup 775프로젝트 -  PM갈린 횟수 3.43
2008년 agile 359프로젝트 - PM갈린 횟수 2.78


물론 rup방법론이 대규모 프로젝트에서
주로 역할을 한다는 관점에서 생각해 보면,
rup가 agile에 비해 유독 불리한 환경에서 카오스를 컨트롤 하였기 때문에
rup가 적용된 결과로는 PM이 갈린 횟수가 더 높았다고 볼 수도 있다. 
(바꿔 말하면 agile이 상대적으로 "쉬운" 소규모나 복잡도가 낮은 프로젝트 위주로 적용되었기 때문에.. 

다만 agile이 2년 동안 그랬을런지는 모르겠지만.
더 설득력있는 반론으로는 agile의 프로젝트 숫자가
rup에 비해 확실히 적어서 표본이 충분치 않다는 것을 들 수 있다.
agile도 초대형 프로젝트에 적용되면서 900개 프로젝트에 적용하면 PM갈린 횟수 3.50 넘게 찍을 수도 있다는 이야기.


그러나 개인적으로는 이렇게 생각한다.

1) 어떤 방법론이 다른 방법론보다 리드가 뛰어나서
   그것 자체로 팀에 긍정적인 영향을 미친다는 결론을 내려면
   "기록으로는 보이지 않는 공헌도" 같은 것을 
   따질 필요도 없이 그 뛰어남이 기록에 고스란히 나타나야 한다.
   바꿔 말하면 agile이 적용되었을 때
   PM이 갈리는 횟수나 비즈니스 케이스에 의해 PM이 프로젝트 드랍 여부를 고민하는 상황이 
   rup를 적용 했을 때에 비해 어느 상황에서건 좋은 쪽으로 나타나야 한다. 상황에 따라 폭은 다르겠지만.
2) 그런데 현실은 전혀 그런 것 같지는 않다.
3) 따라서 뻔히 보이는 도메인을 프로토타입을 구현하며 삽질을 하던 xx은행 프로젝트를
   앰블러가 initial requirement, architecture, modeling과 robustness 가이드로
   6개월 걸리던 것을 1개월로 줄이는 것과 같은 극단적인 사례가 아니라면
   방법론의 힘은 생각보다 크지 않은 것 같다.
   대충 생각하기로는, 점수로 환산하면 후하게 쳐서
   15개 프로젝트 정도에서 드랍고민 횟수를 1회 정도 줄여주는 정도가 되지 않을까? 물론 근거는 없다.

기록이라는 요소를 배제해도 두 가지 이야기를 더 해 볼 수 있다고 생각한다.

1) 상식적인 이야기이고 누구나 수긍하는 점인데, 
   유독 방법론 가이드와 관련된 이야기가 나올 때면 아무도 말하지 않는 주제. 
  방법론의 컨셉이 추구하는대로 모든 안드로메다로 가는 상황에서 
  정확히 드라이브 할 수 있는 PM이 도대체 존재하기는 하는가?
   모든 PM이 전성기의 앰블러 정도의 ART(조직구성능력,영업능력,아키텍처이해,정치력,
   조직장악능력,관리능력,인간적인매력,비용확보능력,위기사전제거 또는 위임능력,접대능력)를
   갖추지 못하는 이상 방법론의 컨셉대로 수행할 수 없을 것 같다.
   그러니까, 아무리 방법론이 리드를 잘 해도 PM이 실수를 하거나 잘못 이해하면 그것으로 끝이다.
2) Alistair Cockburn이 그의 명저에서 했던 이야기의 바리에이션. 
   야콥슨이 rup를 처음 고안했을 때 그는 당장 SDLC의 천재로 일컬어졌다. 
   그 시대에만 해도 전략적 프로세스란 요즘으로 치면 M.F나 그려볼 만한 전략이었기 때문이다. 
   긍정적인 문화가 원리인 프로젝트가 활성화되지 않았던 시절에는 
   그 정도 수준이 되는 컨설턴트나 PM들이 팀 문화에 영향을 미치는 요소를 관리할 수 있었고,
   완료태스크 사이즈나 수행시점을 고생산성을 유지시키는 범위로 만들기 위한 전략도 짤 수 있었던 것이다.
   하지만 지금은 이러한 개념도 널리 퍼져 있고, 평균 정도 되는 PL들이라도 
   책과 인터넷을 훑어보거나 주위에 잘 알려진 컨설턴트들의 컨설팅에 의해 전략을 수립하거나 한다.

방법론도 마찬가지다. rup가 1980년대에 적용되었다면 그 가치는 굉장히 높았을 것이다.
그러나 지금은 모든 회사나 개인이 그러한 프로세스와 discipline에 의한 접근법을 알고 있으며,
본사 컨설팅 지원팀들은 방법론 리더들과 프로젝트 상황을 어떻게 타개해 나갈 것인가에 대해 의논한다.
한가지 프로젝트 환경과 상황에 대한 공략법은
그 환경과 상황이 완전히 달라지기 전까지 일정한 패턴으로 존재한다.
그 패턴을 어느 정도 익혀 놓기만 하면 그리고 PM이 제대로 이해하고 운용한다면,
200x년의 1x00억 예산에 계열사에 널리 뻗친 이러한 류의 프로젝트가 아닌 다음에야 그럭저럭 성공할 수 있다.

따라서 이전과 같이 프로젝트의 사상을
하나로 지배하는 방법론 방식은 점점 줄어들고 있을지도 모른다. 우리가 생각하는 것 이상으로..


p.s 생각대로 떠오르는 대로 꾸며봤습니다.
      마지막은 게리폴리스와 콕번이 말하는 것을 꾸며본 것이고,
      중간 내용들은 앰블러 프랙티스 인용한 것이고 실제 프로젝트 사례는 아닙니다.
      중간 rup, agile 수치는 원래 글을 그대로 인용했습니다. 실제 수치가 아닙니다.