강팀장의 WEB E.Y.G (웹 이야기)

얼마전 이런 쪽지를 받은 적이 있습니다.

"관리가 안되는 프로젝트 (대부분의 한국형 프로젝트)...."

어느 정도 경력도 갖추고 어느 정도 실력을 갖추었다고 자부하던 팀원에게 받은 쪽지는 강팀장에게 약간의 고민을 안겨 주었습니다.

한국형 프로젝트????

도대체 한국형 프로젝트란 무엇이지??
외국에는 다른 프로젝트를 수행하는 건가??? 아니면.. 다른 개발 언어로 개발하는 건가??? 무엇이 다른거지????

간혹 모임이나 동호회에서도 이런 부분에 대해서 토론을 하게 될때도 한국형 프로젝트와 비슷한 말들을 듣습니다.

"선진국의 프로젝트는 이렇게 되는데, 한국에서는 그렇지 못하기 때문에 실패 경우가 많은 거야...."

솔직히 강팀장은 그런 말들에 대해서 이해가 잘 가지 않습니다.
선진국이라고 말하는 부분... 한국형이라고 말하는 부분... 이런 말들은 너무나 상식적인 선에서 자주 나오기 때문에 강팀장 스스로도 혼란스러울때가 많습니다.

일전에... 블로그에 [프로젝트 실패의 원인] 이라는 글을 올린 적이 있습니다.

한국이라는 상황에 스스로 비관적 생각보다는, 어떻게 프로젝트를 효율적으로 진행할 것인가를 고민하는 것이 낫다~! 라는 것입니다.

선진국(?), 외국(?) 사례와 많은 연구 보고서를 보면 한국에서 프로젝트를 진행하면서 겪는 일들이 결코 한국이라는 상황때문에 일어나는 것이 아니라, 발전을 위해 한번은 경험해 보아야하는 과정 같은 것이라 쉽게 알 수 있습니다. - 물론 그런 과정자체를 겪어서는 안되겠지만...... -

이렇기 때문에..??... 결국 포기하는 것인가?? 당연히 실패?? 일정 지연....??  많은 문제점들을 정당화하고자 하는 것이 아니라...

지금 겪고 있는 현재의 상황을 너무 극단적으로 비판할 필요는 없을 것 같습니다.

실패를 최소화 하기 위한 많은 연구가 진행 중이고, 이런 부분에 대한 적용과 실무 진행등의 노력도 지속적으로 이뤄지고 있으니, 앞으로 더 좋아질거라 생각 됩니다.

굳이 "한국형" 이라는 굴레를 만들어 버린다면.. 그 또한 문제가 있지 않을까 생각합니다.

  소프트웨어 프로젝트에서의 리스크 관리  

톰 디마르코 외 지음, 김준식 옮김
2004년 졸트상(Jolt Winner) 수상작. 피플웨어의 저자 톰 디마르코와 티모시 리스터가 제안하는 소프트웨어 프로젝트 리스크 관리를 위한 가이드라인. 프로젝트의 불확정성을 반영한 리스크 계량화 방법을 제시한다.

  Rapid Development - 프로젝트 쾌속 개발 전략  

스티브 맥코넬 지음, 이해영 외 옮김
실제 최전방에서 싸우는 개발자와 관리자들에게 구체적인 사례와 문제 해결 방법을 제시하는 실탄을 제공한다. 풍부한 배경 자료, 다양한 사례 연구, 수백편의 논문과 책을 토대로 분석한 성공 사례를 바탕으로 프로젝트를 일정에 맞추는 동시에 고품질을 유지할 수 있는 방법을 소개한다. 1996년 JoltAward 수상작.

"프로젝트"로 등록된 다른 글.

• 프로젝트 일정에 대한 고민
• 진행중 프로젝트 판단하기.... 관리방법론...
• 한국형 프로젝트???는 없다.
• 프로젝트의 시작과 끝... 입장 차이 - 쓴웃음이 나오는 군요.
• 소프트웨어 프로젝트에서의 리스크관리 - Waltzing with Bears
• [프로젝트 실패의 원인] 프로젝트 실패 인적자원 때문인 경우는 작다.
• 프로젝트 매니저와 아키텍트를 혼동하는 사람들
• 프로젝트 스코프 관리
• 위즈위드 쇼핑몰 웹사이트 프로젝트
• 프로젝트 준비

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

          1.고객이 프로젝트를 설명한것           2.프로젝트담당자가 이해한것      3.분석자가 설계하고 디자인
                                                                                                              한 컨셉



          4.프로그래머가 짠 결과물                  5.테스터가 받은 결과물             6.컨설턴트가 묘사한 결과물


          7. 프로젝트中 문서화된것                8.설치했을때 작동되는 결과              9. 고객이 결과물에 대해
                                                                                                                     지불한 금액의 크기



          10.결과물에대한 유지보수              11.마케팅담당자가 광고했을때        12.실제설치된 시기와 형태


           13.정말로 고객이 원했던것             14.추천사이트에 홍보한 결과        15.이러한 결과로 새계획을
                                                                                                                추진할때



쓴웃음이 나옵니다... 도대체 어디서 부터 잘못된건지.... (그걸 따지는 것 자체가 잘못일까요? ㅡ.ㅡ;;)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

2007년도 12월 한달이 남았습니다.
올해 강팀장은 하나의 프로젝트를 수행하고 지금 하나의 프로젝트를 수행중에 있습니다. 사실 요즘들어 부쩍 고민이 많은 생활을 하고 있습니다.

11년을 넘도록 많은 프로젝트를 하면서 항상 죽음으로 가는 길을 많은 변명과 회사의 명분으로 떠 맡은 경우가 얼마나 있었나 싶더군요.
(물론 모든 프로젝트가 그런 것은 아니였습니다. 그리고 스스로 죽음으로 가는 프로젝트를 자청해 맡은 적도 여러번 있었습니다.)

많은 분들과 대화와 토론을 하다 보면 "아직도 우리나라에서는...."  라는 극단적 이야기를 많이 듣곤 합니다. 그럴땐 소주 몇잔으로 서로에게 위로를 하곤 하지만...

오늘 끝으로 읽은 『소프트웨어 프로젝트에서의 리스크 관리』를 보면서 두가지 생각이 들더군요. 하나는  어떻게 이들은 지금 내 처지를 정확하게 말하고 있을까? 둘째는 외국도 우리나라와 비슷한 고민들을 하고 있는 듯 하구나....

"아직도 우리나라에서는.... " 이라는 말보다... "IT 개발 일은... " 이라고 생각하면 소주 몇잔 가지고는 안될까요?

  소프트웨어 프로젝트에서의 리스크 관리  

톰 디마르코 외 지음, 김준식 옮김
2004년 졸트상(Jolt Winner) 수상작. 피플웨어의 저자 톰 디마르코와 티모시 리스터가 제안하는 소프트웨어 프로젝트 리스크 관리를 위한 가이드라인. 프로젝트의 불확정성을 반영한 리스크 계량화 방법을 제시한다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Project Management 관련 책의 대부분이 그들의 방법론 중심을 책을 저술하는 것이 사실입니다. 읽다보면 자신이 알는 것과는 다른 내용과 이해하기 어려운 프로세스에 대한 이야기로 일괄하다 결국 반도 못보고 책을 덮어 버리는 경우가 많았습니다.

블로그에 담아두고 있다가... 이번 프로젝트를 수행하면 꼭 읽어야 겠구나 싶어 1년 가까이 북마크만 해 놓았던 책을 구매를 하고야 말았습니다. (강팀장의 책 수집 블로그 http://blog.yes24.com/hanjum)

프로젝트 관리자 또는 리더(매니저)라면 한번 읽어 시길 추천합니다. 기술적인 방법론을 익힌기 위한 분도 괜찮겠지만 요즘 들어 왠지 답답한 분이나... 변명이 필요한 분이라면 재미있게 읽을 수 있을 것 같습니다. (^^ 제 경험일까요?? )

불확실성과 관련된 보다 중요한 원인들은 다음과 같다.

 

모든 소프트웨어 프로젝트에 공통적인 리스크

 

우리에 대한 농담

우리 IT 사람들이 리스크 수용에 접근하는 방식이 다른 사람들과 다르다는 것에 대한 농담을 만든다면, 아마 이렇지 않을까?

IT 관리자와 보통 사람이 수요일 오후에 시카고에서 일을 하고 있고, 둘다 금요일 정오에 샌프란시스코에서 미팅에 참석해야 하며 시간을 지키는 것이 매우 중요한 것을 안다.
보통 사람은-다이안이라고 하자- 목요일 밤 비행기를 타고 샌프란시스코 사무실에서 한 블록 떨어진 조그만 호텔에 방을 잡는다.
허남이라는 식당에서 한가로이 식사를 하고 영화를 보고 유니온 스트리트 쪽으로 향한다. 다음날 여유 있는 아침식사를 하고 노트북 컴퓨터로 11시까지 작업을 한다.
11시 30분 체크아웃을 하고는 걸어서 10분 일찍 사무실에 도착한다.

반명 IT 관련자인 잭은 금요일 아침 8시 40분 비행기를 예약한다.
미드타운에서 7시 5분에 택시를 잡아타고 아이젠하워의 교통체증 속으로 들어간다. 오하라 공항까지 가는 내내 택시 운전사에게 화가 나서 불만을 토로한다.
멍청한 택시 운전사는 잭이 이 비행기를 타는 일이 얼마나 중요한지 이해하지 못하는 것 같다.
유나이티드 에어에 체크인을 하면서 직원에게 비행기가 정시에 출발해야 하고 변명은 통하지 않는다고 이야기한다.
그녀에게 어떤 이유로 인한 지연도 '매우, 매우 실망스러울 것'이라고 말한다. 탑승이 지연될 것이라는 말에 펄쩍 뛰며 반발한다.
조정된 시간이 방송되는 순간 그가 가지고 있는 관리도구들을 뒤져서 최후의 통첩을 전달한다.
"만약 내가 12시 미팅에 참석할 수 있도록 당신들이 샌프란시스코에 제때 데려다 주지 않는다면, 모자기자 날아갈 줄 아시오"

납기일자가 중요한 프로젝트는 일찍 시작하는 것이 진정한 리스크 완화다.
이는 아마도 거의 모든 프로젝트에서 지연이라는 리스크를 수용하는 가장 효과적인 방법일 것이다.
좋다. 프로젝트를 일찍 시작하기에는 너무 늦었다는 것을 알고 있다. 시작할 때 시작을 했고 이미 곤경에 빠져 있는 것이다. 그리고 어떻게 하면 곤경에 빠져 들지 않을 수 있었나를 알기 위해 이 책을 읽고 있지는 않을 것이다. 어떻게 하면 무사히 빠져 나올 수 있을지 알고 싶은 것이다. 모두 맞는 말이다. 그러나 아래에서 설명하는 것처럼 일찍 시작하는 선택은 어쨌든 가치 있는 일이다.

- 17장 궁극적인 리스크 완화 전략(202p)

  소프트웨어 프로젝트에서의 리스크 관리  

톰 디마르코 외 지음, 김준식 옮김
2004년 졸트상(Jolt Winner) 수상작. 피플웨어의 저자 톰 디마르코와 티모시 리스터가 제안하는 소프트웨어 프로젝트 리스크 관리를 위한 가이드라인. 프로젝트의 불확정성을 반영한 리스크 계량화 방법을 제시한다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

IT프로젝트 성공율은 30%도 체 도달하지 못하는 경우가 많습니다.
(CHAOSR보고서를 보면 시간이 지날수록 성공율은 올라가긴 하지만, 30%를 넘지 못하는 경우가 많다고 보고하고 있습니다.)

이런 현상은 프로젝트의 규모가 클수록  (성공률) 더 낮게 나오고 있습니다.




프로젝트 실패의 원인에 대해서 우리는 흔히 인력에 대한 부분이 가장 높다고 생각하는 경우가 많습니다.
인력관리는 프로젝트 성공을 위한 중요한 활동임에 틀림이 없습니다.
투입시기 및 일정, 외주관리, 스킬함양등등 인력활동이 중요한 요건이라고 생각하고 있으며 특히 인력 투입시기와 기술적 요건을 실패를 가져오는 직접적인 요인이라고 말하곤 합니다.

하지만 인력에 의한 프로젝트 실패는 큰 비율을 차지 하지 않습니다. 오히려 팀원보다 Manager의 역량에 의한 실패는 더 큰 이유입니다.


팀원이 제대로 움직이도록 하는 것은 매니저에 있습니다.

팀원의 숫자가 생산성에 비례한다는 것은 잘못된 생각 입니다.

어느 회사의 임원급 사람이 자신의 회사가 가지고 있는 힘은 직원이 많다는 것이라며 공공연하게 말하곤 했습니다. "수행하고 있는 많은 프로젝트중 문제가 발생하면 회사내 가용할 수 있는 인력을 많이 넣어 반드시 수행한다."

얼핏 듣기로는 맞는 말 같지만, 프로젝트 관리라는 차원으로 본다면 얼마나 위험한 생각을 가지고 있는지 금방 알 수 있습니다.
시간은 한정되어 있고, 프로젝트 일정에 따라 또는 팀원의 경험 혹 스킬 부족의 해석으로, 밀어 붙이면 된다는 판단은 어리석은 생각입니다.

일 정이 지연되는 것은 팀원의 스킬이나 경험 부족이 잘못된 것이 아니라, 잘못된 일정계획과 그런 상황에 대한 무감각한 결정권자들의 무능력함이 더 큰 이유일 것입니다. - 물론 팀원의 스킬이나, 경험부족이 원인이 될 수 있을지 모르나, 그런 팀원을 적정하게 배정하지 못하는 매니저의 능력부족이 더 큰 원인인 것입니다. -
일정의 지연은 팀원(능력이 되던 안되던, 경험이나 스킬이 부족하던 탁월하던)에 따란 제대로된 일정 계산과 계획의 문제가 원천적인 이유라고 봐야 할 것입니다.

그래도 아직 매니저는 할 말이 있습니다. 제대로 된 인력만 준다면 문제 없이 프로젝트를 순조롭게 할 수 있다.

로버트 바인더는 오히려 팀의 진화를 말하고 있습니다.



팀원과 기술적 구현은 프로젝트 실패의 큰 원인은 아니다.






freepower님께서 강팀장의 글을 읽고 "인력이 제때 들어오지 않으면 결국 프로젝트에는 큰 위험이 발생하게 되는 것 아닙