2008. 6. 17. 09:22

한국형 프로젝트???는 없다.

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

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

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

한국형 프로젝트????

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

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

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


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

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

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

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

The Standish Group CHAOS Report 에 따르면,  전세계적으로 프로젝트의 성공율이 올라가고 있지만, 아직도, 체 30%수준에 못미치는 프로젝트만이 성공하고 있으며, 그 부분도, 프로젝트 규모가 커질 수록 실퍠확률은 더 높아진다고 하고 있습니다.

개발 일정에 대해서도 전체 프로젝트 중 2/3정도가 일정을 심각하게 초과한다고 말하고 있으며.. (Lederer and Prasad 1992, Gibbs 1994, Standish Group 1994) 이 또한 대형 프로젝트는 평균 25%~50%까지 완료일정을 놓쳤고, 프로젝트 크기가 클수록 일정 지연은 더욱 심각해진다(Jones 1994)라고 보고 하고 있습니다.


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

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

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

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


  소프트웨어 프로젝트에서의 리스크 관리  톰 디마르코 외 지음, 김준식 옮김
2004년 졸트상(Jolt Winner) 수상작. 피플웨어의 저자 톰 디마르코와 티모시 리스터가 제안하는 소프트웨어 프로젝트 리스크 관리를 위한 가이드라인. 프로젝트의 불확정성을 반영한 리스크 계량화 방법을 제시한다.
  Rapid Development - 프로젝트 쾌속 개발 전략  스티브 맥코넬 지음, 이해영 외 옮김
실제 최전방에서 싸우는 개발자와 관리자들에게 구체적인 사례와 문제 해결 방법을 제시하는 실탄을 제공한다. 풍부한 배경 자료, 다양한 사례 연구, 수백편의 논문과 책을 토대로 분석한 성공 사례를 바탕으로 프로젝트를 일정에 맞추는 동시에 고품질을 유지할 수 있는 방법을 소개한다. 1996년 JoltAward 수상작.


[search]프로젝트|10|date|desc|T[/search]
2008. 5. 30. 10:04

기술관리자는 기술이 아니라 사람을 다룬다

최근 1~2년 사이에 PM에 대해서 많은 생각을 해 보게 됩니다.

과연 PM이란 무엇인가?

아주 최근의 일입니다. 어떤 사람이 PM의 업무를 잘 할 수 있는가에 대해서 2시간 가량 토론을 한적이 있었습니다.
전직 기획자, 개발자, PM전문 교육을 받은 사람, 경험자.... 많은 의견이 어떻게 보면 당연한 답변에서 세부 명제들에 대한 애기들이 결국 일반화된... 당연한 답변으로 끝나버렸지만.. (기획/개발/디자인 전직에 대해서 상관없이 이전 프로젝트 경험이 많은 경험자로 쳬계적인 관리 기법을 적용할 수 있는 사람) 아직도 풀리지 않은 것들이 많습니다.

강팀장도 초기에는 개발자 출신에서 시작해서 지금은... PM을 하고 있지만, 그동안 많은 일들이 있었습니다.

최근 1~2년 사이의 최근 프로젝트에서 스스로 짊어볼 수 있는 기회가 많았습니다.

PM은 이전의 담당업무가 어떤일이든(기획/개발/디자인/코더......) 상관이 없는 것 같습니다. 분명 PM이라는 업무자체가 이전에 해오던 업무 방법과 성격이 틀리기 때문입니다.

기술자로써가 아니라, 말그대로 관리자로써의 능력을 만들어 가야 되기 때문입니다.


기술관리자는 기술이 아니라 사람을 다룬다 라는 칼럼을 보면서... PM에게 필요한 Skill은 무엇인지 되물어보게 합니다.

"기술관리자는 기술이 아니라 사람을 다룬다"
류한석 (IT 컬럼니스트) ( ZDNet Korea )   2008/05/26
 
훌륭한 관리를 한번도 받아보지 못한 사람이 훌륭한 관리자가 될 수 있을까? 글쎄, 아마도 훌륭한 관리자가 되기는 어려울 것이다. 마치 어린 시절에 사랑을 받고 자라지 못한 사람이 성인이 되어서 제대로 사랑을 하기 힘든 것처럼.
그것은 심리학을 통해 검증된 통계적 사실이다. 왜 그럴까? 아는 것이 그것 밖에는 없기 때문이다. 맞아본 사람이 때릴 줄 안다. 학대를 받아본 사람이 학대할 줄 안다. 간혹 예외가 있을 뿐이다.
안타까운 사실은, 조직 생활에서도 이와 같은 원리가 그대로 적용된다는 사실이다. 관리 업무는 눈에 잘 보이지 않는다. 좋은 관리, 나쁜 관리는 그 행위 자체보다는 결과로서 판단된다. 또한 관리 활동의 대부분은 소프트 스킬에 속하므로, 학습에 의해 습득 가능한 하드 스킬과는 달리 역량을 키우는 것이 쉽지 않다.
그런데 현실을 보면, 조직(회사)은 아무 준비도 없이 기술자를 관리자로 만들어 버린다. 좋은 관리를 받아본 적이 없고, 그렇다고 해서 딱히 관리 교육을 받은 적도 없는데(물론 교육을 받더라도 효과가 별로 없지만), 어느 날 갑자기 조직은 팀 또는 프로젝트 관리를 기술자에게 맡겨 버린다.
■기술자와 기술관리자는 다르다
기술자와 기술관리자는 다르다. 기술관리자는 기술이 아니라 사람을 다룬다. 그래서 기술자 시절에 PC를 붙잡고 씨름하던 것과는 완전히 다른 관점과 방식과 필요하다. 하지만 좋은 관리를 받아 본 적이 없고 더군다나 준비도 안된 상태에서 좋은 관리자가 되는 것은 거의 불가능하다. 어쩔 줄 몰라 하다가, 자기가 정말 닮고 싶지 않았던 그런 관리자와 유사한 행동을 반복하게 된다.
한때 기술자였으나 실패한 관리자의 사례를 하나 살펴보자. 실제 사례를 바탕으로 재구성해 보았다.
개발자 K는 뛰어난 개발자였다. 그는 개발 능력이 뛰어났기에 조직에서 인정을 받고 있었다. 대개의 조직은 일정 경력을 갖춘 우수한 개발자에게 관리자를 맡기고 싶어한다. 그 뛰어난 능력을 단지 개발에만 쏟지 말고 여러 개발자들을 관리하는데  ..... - 중략 -

2008. 3. 14. 21:46

깨어있는 리더의 기본 덕목...

첫째. 리더는 성과에 대해 책임을 져야 한다.

둘째. 성과는 혼자 이뤄낼 수 없다. 함께 집중해야 한다.

셋째. 부서원의 단결을 이끌어 내려면 확실한 목표를 제시해야 한다.

다섯째. 모든 업무를 파악하고 부서원들의 인정과 존경을 받을 수 있어야 한다.

여섯째. 늘 부하직원에게 열심히 일해야 하는 이유와 동기를 부여해야 한다.



요즘들이 마음이 더더욱 무겁습니다...

스스로 짚어 봐야할 부분도 너무 많고,....



사무실에 잘생긴.. 최대리가... 가져다 준... 주간 잡지중에서


사용자 삽입 이미지