'매니저'에 해당되는 글 3건

  1. 2007.12.03 관리자의 책임을 벗어날 수 없다.!!
  2. 2007.11.20 [프로젝트 실패의 원인] 프로젝트 실패 인적자원 때문인 경우는 작다. 2
  3. 2007.11.19 프로젝트 매니저와 아키텍트를 혼동하는 사람들 3
2007. 12. 3. 15:03

관리자의 책임을 벗어날 수 없다.!!

믿음의 윤리


한 선주가 이민선을 보내려고 한다. 그는 배가 낡았고, 처음부터 그렇게 잘 만들어지지 않았다는 것을 안다. 그 배는 여러 바다와 나라를 향해했으며, 종종 수리를 요했다. 그런 의구심으로 인해 항해에 적합하지 않다는 생각을 해 왔다. 의구심이 그를 괴롭히고, 기분을 좋지 않게 했다. 비록 많은 돈이 들더라도 배를 철저히 검사하고 수리해야겠다고 생각했다. 그러나 배가 출항하기 전 그는 이런 우울한 감삼을 극복하는데 성공했다. 스스로에게 '이 배는 정말 수많은 항해를 무사히 마쳤고 폭풍우를 견뎌 왔어. 따라서 이번 여행을 무사히 마치지 못할 거라는 생각은 부질 없는 짓이야.' 하고 말한다.
그는 자신의 믿음을 '신의 섭리(Providence)'로 간주했다. 신의 섭리는 좋은 삶을 영위하기 위해 고국을 떠나온 많은 불행한 가족들을 저버릴 리가 없다. 배를 만든 사람들과 계약자들에 대해 마음 속에 있는 모든 옹졸한 의구심을 떨쳐 버렸다. 그런 식으로 배가 완벽하게 안전해서 항해가 가능하다는 진실하고 만족할 만한 확신을 얻게 되었다.
그는 가벼운 마음으로 배를 떠나 보내며, 새로운 고향으로 떠나는 이주에 대해 자비로운 은총을 기원했다. 그러다가 배가 바다 중간에서 좌초되어 아무런 소식도 들리지 않았을때 그는 보험료를 챙길 수 있었다.
그에 대해 어덯게 이야기할 수 있을까? 여기서는 확실히, 사람들의 죽음에 대해 선주에게 죄가 있다. 그가 진정으로 배에 문제가 없다고 믿었다는 것을 인정한다고 해도, 그의 확신에 대한 진실성 자체가 결코 그의 행위를 정당화할 수 없다. 왜냐하면 그는 앞에 놓인 그런 증거를 믿을 권리가 없기 때문이다. 그는 세밀한 조사에 따른 결과를 통해서가 아니라 단순히 자신의 의구심을 교살함으로써 믿음을 얻은 것이다. 비록 마침내 그가 다른 식으로 생각할 수 없을 정도로 확실한 믿음을 갖게 되었을 수도 있으나, 여전히 그는 문제를 인지하고도 의도적으로 그런 생각의 틀로 자신을 몰아갔으므로, 책임을 져야만 한다.


- 윌리엄 킹돈 클리포드

이글을 읽고 어떤 생각이 나는 가요?

강팀장은 PM의 책임에 대해 벗어날 수 없는 굴레 같은 것이 느껴지더군요....
슬픈 현실이라고 하기엔 그렇고.... 그렇다고 스스로 방어를 하면서 살 수 없는 것 같습니다.
2007. 11. 20. 13:54

[프로젝트 실패의 원인] 프로젝트 실패 인적자원 때문인 경우는 작다.


많은 통계와 사례를  IT프로젝트 성공율에 대한 평가가 좋지 못한 것이 사실입니다.

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

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

사용자 삽입 이미지



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

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

“무능력한매니저밑에서는외계인으로부터인류를구하는것이프로젝트의목표라고하여도팀원들은노력하려고애쓰지않는다.”–에드워드요든

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

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

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

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

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

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

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

● 팀의진화과정
    –포밍(forming) 단계
      • 목표, 역할, 팀의방향을정의한다
    –스토밍(storming) 단계
      • 규칙과프로세스를정의하고종종팀원의역할을재조정한다
    –노밍(norming) 단계
      • 표준, 절차, 여러가지기준에대해합의한다
    –퍼포밍(performing) 단계
      • 팀이하나의시스템처럼기능을수행한다
                                                                                     - 로버트 바인더


팀원과 기술적 구현은 프로젝트 실패의 큰 원인은 아니다.
사용자 삽입 이미지

프로젝트팀에나쁜영향을미치는요인들

1.비합리적인프로젝트범위와데드라인
2.끊임없이변경되는요구사항
3.나쁜프로젝트매니저
4.오버타임과일중독자
5.정치적혼란
6.비전문가들에의한부적절한작업
7.커뮤니케이션통로의부재
8.프로젝트목표와상관없는겉치레와같은몸짓들

팀빌딩 및 동기여부의 기술

– 팀원들이종결감을느끼게하라
– 엘리트의식을느끼게하라
– 이질성을허락하고격려하라
– 성공적인그룹을잘보호하고유지하라
– 전술적인것이아니라전략적인방향을제시하라
– 불완전한제품(싸구려제품)을만드는일에, 공동의만족감이란있을수
   없음을기억하라

동기부여와관련해서알아야할것

– 뛰어난개발자는평범한개발자에비해5~28배까지뛰어나다
   • 하지만급여는2배가되지못한다
– 개인간5배이상의생산성차이는일반적이다
– 소프트웨어개발에있어기술이부족한다수의사람보다뛰어난소수의사람이
   훨씬낫다
– 작업환경은생산성과품질에상당한영향을미친다
– 중요한점은“팀원의생산성을어떻게최대한이끌어내는가?”이다
- 자료출처 : PM관련 MS 세미나 TechNet_RC840_presentation



freepower님께서 강팀장의 글을 읽고 "인력이 제때 들어오지 않으면 결국 프로젝트에는 큰 위험이 발생하게 되는 것 아닙니까? 그 자체가 인적자원의 문제인것 같습니다" 라는 글을 보내 주셨습니다.

맞습니다. 이 글은 한가지 전제를 두고 있어야 합니다. "회사에서 인력투입을 프로젝트 진행 계획대로 투입을 시켰을때"의 상황을 말하는 것입니다.

넓 은 의미의 프로젝트를 본다면 적절한 인력투입 시기와 투입여부 또한 프로젝트의 인적자원관리라고 볼 수 있습니다만, 더 중요한 것은 투입시기 산출과 투입여부 또한 매니저의 역활중 하나 입니다.  회사가 인력을 투입해 주던 안 해주던 매니저는 그 역활을 위해 최선 다해 활동을 해 주어야하고 그에 따른 책임을 가져야 할 것입니다. 반면 회사는 매니저가 그런 활동을 하도록 매니저로써 권한을 명확히 해야 합니다.



우리는 2가지 고질적인 문제점을 가지고 있습니다.

1. 거의 대부분의 회사에서는 인적자원이 확보 여부와 관계 없이 프로젝트를 진행하고자 한다.
회 사는 간혹 이후 프로젝트를 위한 프로젝트를 하는 경우가 많습니다. 이런 경우는 주로 정치적인 프로젝트가 될 가능성이 높습니다.정치적 프로젝트는 그 자체가 많은 위험요소를 지니고 있는데 그중 가장 고질적인 부분이 최소로 최대한 이라는 생각을 가지고 있다는 것 입니다. 

2. 매니저에게 정확한 권한과 책임이 주어지지 않는다.
프 로젝트를 진행할때 매니저의 역활은 굉장히 중요합니다. 하지만 그에 따른 권한과 책임을 주지 않고 이중적 잣대를 가지고 본다는 것입니다.  간혹 권한은 없고 책임만 묻는 것이 거의 대부분 회사의 행태인 것 같습니다. 전 이 또한 매니저를 관리하는 윗 사람들의 자질에 문제가 있다고 봅니다.

1번째를 어느정도 완화시킬 수 있는 대안은 2번에 있습니다만.... 여전히 회사도 매니저도 할말이 많을 것 같습니다.
2007. 11. 19. 22:00

프로젝트 매니저와 아키텍트를 혼동하는 사람들

소프트웨어 프로젝트가 실패하는 이유에는 수많은 원인들이 있다. 가장 고전적인 원인을 꼽는다면 ‘잘못 결정된 프로젝트 기간과 비용’일 것이다. 또는 요구사항을 제대로 파악하지 않았거나 빈번하게 수정했기 때문일 수도 있고, 주요 이해관계자의 참여 또는 경영층의 지원이 부족했거나, 제대로 된 프로젝트 계획을 작성하지 않았기 때문일 수도 있다. 그것도 아니면 프로젝트 또는 조직 내부의 정치적인 문제 때문일 수도 있다.

어떤 최악의 프로젝트에서는, 그 모든 요인들이 결합해서 나쁜 시너지를 만들어내고 그 결과로 참담한 상황을 맞이하기도 한다. 프로젝트에 나쁜 영향을 미치는 모든 요인들에 대해 살펴보려면 엄청난 지면이 필요할 것이다.

이번 컬럼에서는 가장 중요한 실패 원인 중 하나이지만 잘 거론되지 않는 사실을 하나 소개해 보겠다. 그것은 바로 프로젝트 매니저, 아키텍트의 역할을 혼동한 나머지, 잘못한 책임을 부여하는 것이다. 즉 관리 책임과 기술 책임을 구분하지 않는 문제인데, 가장 중요한 인적자원에 오류가 있는 것이어서 프로젝트의 근본적인 실패 원인으로 작용하게 된다.

현재의 상황을 살펴보자. 먼저, 지금 당장 아무 구인구직 사이트든 가서 확인해보라. 다음과 같은 글을 쉽게 만날 수 있을 것이다.

[PM 모집: 자격 요건은 다음과 같음]
C/C++, Java, DBMS를 능란하게 구사 가능해야 함
UML 등을 활용한 설계 능력이 뛰어나야 함
고객과의 원활한 의사소통 및 협상이 가능해야 함
교육 및 프레젠테이션 스킬이 뛰어나야 함
소프트웨어 프로젝트의 관리 능력이 능숙해야 함
기술사, PMP, CISA 등의 자격증 우대


위와 같은 사람을 구하려고 한다면 장담컨대 거의 확실하게 구할 수 없을 것이다. 우리 업계에 그런 스펙을 갖춘 사람도 드물지만, 그런 사람이 있다고 하더라도 구인 업체에서 어떻게 평가하고 판단할 수 있겠는가? 또한 충분한 대우는 가능할까?

멀티 플레이어에 대한 무지 또는 욕심
프로그래밍 능력의 경우 면접 시 테스트 프로그래밍을 통해 어느 정도 평가를 할 수도 있겠지만, 설계 능력과 관리 능력의 경우 테스트 자체가 거의 불가능하다.

위와 같은 사람을 구하는 것은 그저 업체의 욕심일 뿐이다. 프로그래밍 능력, 설계 능력, 관리 능력을 모두 갖춘 그런 자원이 거의 없는 것이 국내 업계의 현실이다. 개인 탓이 아니라 시대가 그렇다.

기술 쪽을 살펴보면, 지금은 코볼로 개발을 하던 1980년대가 아니다. 그때에는 코볼 하나만 알면 모든 것이 해결되었지만 지금은 알아야 할 것이 너무 많다. 관리 쪽도 만만치 않다. 비즈니스 환경을 전반적으로 이해해야 하고, 정치력도 필요하고, 문서 작성, 프레젠테이션을 잘 해야 하는 등 고도의 스킬이 필요해졌다. 그리고 관리와 기술은 서로 다른 분야이다.

하지만 주요 인적자원의 실제 업무를 이해하지 못한 채로, 멀티 플레이어(또는 업계 용어로 올라운드 플레이어)를 뽑으려고 노력하는 업체들이 참으로 많다. 그것은 무지 또는 욕심. 둘 중의 하나이다.

잘못된 역할 배정의 문제
위에 예를 든 구인 공고를 보면 알겠지만 그 제목은 어쨌거나 ‘PM 모집’이다. 즉 프로젝트 매니저를 뽑는 것이다. 그런데 세부 사항을 보면 도통 프로그래머를 뽑는 것인지, 설계자를 뽑는 것인지, 관리자를 뽑는 것인지 헷갈린다.

물론 척박한 국내의 IT 현실에 비추어 볼 때, 프로젝트에서 수많은 역할을 동시에 수행할 수 있는 그런 멀티 플레이어를 선호하는 상황을 인정하지 못하는 바는 아니다. 하지만 바로 그런 잘못된 판단 또는 욕심이 바로 프로젝트를 실패하게 만든다.

일단 프로그래머의 경우 모든 사람들이 익히 잘 아는 역할이므로 논외로 치고, 소프트웨어 아키텍트와 프로젝트 매니저의 역할을 생각해보자.

소프트웨어 아키텍트는 설계자이다. 개발을 위한 ‘소프트웨어 요구사항’을 파악하고, 큰 그림의 소프트웨어 아키텍처를 디자인하고, 개개의 프로그래머들이 작업해야 할 서브 시스템과 컴포넌트를 정의하는 사람이다. 또한 테스트 엔지니어들과 함께 테스트 요구사항을 수립하기도 하면서, 소프트웨어 개발의 전 과정에서 중요한 기술 책임자의 역할을 수행하는 사람이다.

프로젝트 매니저는 관리자이다. 프로젝트의 진행을 위한 ‘프로젝트 요구사항’을 파악하고, 프로젝트 계획을 수립하고, 개개의 팀원들이 작업해야 할 프로젝트 활동을 시간과 비용 개념을 갖고서 정의하는 사람이다. 또한 품질 담당자와 함께 품질 보증을 위한 활동을 수립하기도 하면서, 프로젝트의 전 과정에서 관리 책임자의 역할을 수행하는 사람이다.

소프트웨어 아키텍트는 소프트웨어 개발을 위한 높은 수준의 디자인을 계획하고 책임지는 사람이고, 프로젝트 매니저는 프로젝트 관리를 위한 여러 활동들을 계획하고 책임지는 사람이다. 기술 활동과 관리 활동은 분명히 다른 것이다.

하지만 많은 업체들이 그것을 혼동함으로써 재앙을 불러온다. 마치 프로젝트 매니저가 프로그래밍도 잘 알아야 하고, 설계도 잘 해야 하고, 관리도 잘 해야 한다고 생각한다. 물론 작은 규모의 프로젝트에서는 단 한 명이 모든 역할을 다 수행하는 경우도 있겠지만, 그것은 아주 예외적인 것이다.

기술 책임자와 관리 책임자는 구분되어야 한다
대부분의 소프트웨어 프로젝트에서 프로젝트 매니저의 역할과 아키텍트의 역할은 명확히 구분될 필요가 있다. 물론 두 사람이 상호 신뢰 하에 관리 책임자, 기술 책임자로서 긴밀하게 협조해야 하는 것은 자명하다.

그러므로 이 컬럼의 진지한 충고는, 프로젝트 매니저와 아키텍트의 역할을 제대로 구분하고 적합한 사람을 각각의 역할에 배정하라는 것이다. 그런 사람이 없어서 못 쓴다고 항변하는 업체들도 있을 것이다. 글쎄, 세상에 쉬운 일이 어디 있겠는가? 그것은 시간을 갖고 업체 스스로 양성을 하든, 경쟁 업체에서 스카우트를 하든, 해외에서 데려오든 해당 업체가 판단할 일이다.

프로젝트의 실패. 그것은 바로 소프트웨어와 프로젝트의 본질을 무시하고 인적자원의 중요성을 무시한 행동에 따른 필연적인 결과가 아닐까 필자는 생각한다. 그래서 필자는 다음의 주장을 명백히 강조하고 싶다.

“기술 책임자와 관리 책임자는 구분되어야 한다” 그것은 CEO와 CTO가 구분되어야 하는 것과 같은 개념이다. 만일 무지하여 그러한 구분을 제대로 해내지 못하거나, 또는 비용 절감의 욕심에 사로잡혀 고의적으로 그것을 행하지 않는다면, 프로젝트는 필히 재앙으로 보답할 것이다. 소프트웨어 프로젝트의 역사는 그것을 증명하고 있다. @
류한석(피플웨어 운영자)

오래전의 글 입니다.

요즘 이런 글에 더욱 관심이 가는 것은 앞으로 강팀장은 무엇을 해야 하는가에 대한 스스로에 대한 고찰이라고 할지도 모르겠습니다.

그러고 보면 요즘 참 많은 고민을 하고 사는 것 같습니다.