단순히 생각해 보면 RPG 게임은 대부분 지루해 보인다. 몹 잡으려고 던전 도는것도 하루 이틀이고 퀘스트도 사실 거기서 거기다. 하지만 그 게임을 하는 사람들은 재미있어 하고 중독 되는 사람도 있다. 몇시간만 접속 하지 않아도 금단현상을 일으키기도 한다. 왜 그럴까? RPG 게임의 몹 사냥이나 퀘스트깨기는 단순히 그 행위자체에서 오는 즐거움도 어느정도 있겠지만 사실 그 행위로 인해서 일어나는 캐릭터의 레벨업이 더 중요한 관심사이기 때문이다. 레벨업이 관심 없는데 몹은 잡아서 뭐할꺼며 퀘스트가 왠말이겠는가..
그렇다면 PM은 어떤가. 사실 IT 프로젝트에서 처음에 단순히 개발자로 참여해서 PL이 되고 그 이후에 PM이 되고 나면 더 이상 레벨이 올라가지 않는것 같은 느낌이 든다. 어려운 프로젝트도 있고 비교적 쉬운 프로젝트도 있지만 결국 PM이 하는 일은 앞서서 이야기한 몹잡고 퀘스트 깨는것과 같이 프로젝트 사이클에 따른 반복이기도 하기 때문이다. 그런데 게임에서와 마찮가지로 그 단위 작업이 좀 지겨운 경향이 있더라고 자신의 레벨이 뭔가 올라 간다면 좀 더 즐겁게 작업 할 수 있고 즐겁게 작업 하면 성과도 좋아 질 수 있게 된다.
그렇다면 자신의 레벨이 올라가는 프로젝트는 어떤것이 있으며 그런 프로젝트를 맡으려면 어떻게 해야 할까? 이른바 PM으로서의 캐리어를 관리 하려면 어떻게 해야 할까하는 이야기를 한번 해보도록 하자
첫번째 회사에서 가장 큰 프로젝트를 맡아라.
흔히 사람들이 잘못 생각하는 것이 규모가 큰 프로젝트는 어렵고 규모가 좀 작은 프로젝트는 쉬울꺼라는 느낌이 든다. 그리고 규모가 작은 프로젝트를 해보면 생각보다는 쉽지가 않다. 그러면 아 이렇게 작은 프로젝트도 어려운데 더 큰 프로젝트는 얼마나 더 어려울까.. 하는 생각이 들면서 위축되기도 한다.
하지만 내 경험상 프로젝트의 난이도는 결코 프로젝트의 규모에 비래하지 않는다. 하지만 프로젝트의 이슈나 리스크는 확실히 프로젝트의 규모에 비래하는 경향성이 있다. 그런데 왜 프로젝트 규모와 난이도가 비래하지 않는다고 하는걸까?
프로젝트가 크면 그만큼의 지원과 여유가 생기기 때문이다. 예를 들면 프로젝트가 크면 기술적인 이슈가 생길 가능성도 크지만 투입된 프로젝트 인력을 좀 더 핵심 개발자들로 구성할 수 있다. 금액적으로도 어느정도 여유가 생기기 때문에 리스크에 대한 예비비도 생각할 수 있게 되고 본사의 지원을 받기가 비교적 쉽기 때문이다. 따라서 자신이 할 수 있는 가장 큰 프로젝트를 맡으려고 노력하고 될 수 있으면 회사에게 가장 큰 프로젝트를 맡을 수 있도록 노력 하는 자세가 필요하다. 결국 PM은 어느정도모의 프로젝트를 관리해 봤느냐로 판단되기 때문이다.
두번째 금융권 프로젝트를 맡아라.
IT 프로젝트중 가장 보수적인 프로젝트는 금융권 프로젝트다. 금융권 프로젝트는 대부분 수주금액도 크고 요구되는 기술수준도 높다. 게다가 금융권 프로젝트의 경험이 없는 사람은 참여하기가 무척 까다롷다. 그래서 자신의 이력서에 금융권 프로젝트가 있느냐 없느냐는 PM은 물론이고 개발자의 몸값이나 역량판단에 중요한 잣대라 될 수 있다. 따라서 될 수 있으면 금융권 프로젝트에 참여할 수 있도록 노력 하는 것이 좋다.
세번째 다수의 협력업체를 관리하는 프로젝트를 맡아라.
같은 규모의 프로젝트라도 다수의 협력사를 관리하는 프로젝트와 그렇지 못한 프로젝트는 관리 난이도가 확연하게 차이가 나고 요구되는 스킬셋도 다르다. 따라서 PM으로서 다수의 협력사들과 협업해서 휼룡하게 프로젝트를 진행해본 경험은 역량을 판단하는데 중요한 객관적 지표가 될 수 있다.
네번째 정식 감리가 포함된 프로젝트를 맡아라
일반적으로 규모가 크면 감리가 포함된다. 공공분야에서는 프로젝트 규모가 5억이 넘어가면 감리를 필수적으로 포함해야 한다. 물론 IT감리는 사후적이고 문서 꼬투리 잡기에 치우치는 등 프로젝트를 진행 하다 보면 왜 돈 주고 이런 뻘짓을 해야 하나 회의감이 들때도 있지만 프로젝트 방법론에 따른 정식적인 진행을 외부에서 체크해주는 것과 그렇지 않은것은 아무래도 차이가 있다. 그리고 감리에 대한 대응이나 감리에 필요한 산출물을 제출하는 것도 한번 경험해 보지 않으면 대응하기가 상당히 까다로울 수 있기 때문에 감리가 포함된 프로젝트를 경험해 보는것도 PM으로서 꼭 필요한 경험이라고 할 수 있다.
마지막으로 하드웨어를 포함한 프로젝트를 맡아라.
프로젝트에 하드웨어가 포함 되면 고려해야 할 사항과 프로젝트 진행이 많이 달라진다. 따라서 하드웨어가 포함된 프로젝트를 해보는것이 PM으로서의 능력 향상에 도움이 된다.
자 PM의 레벨을 올리는 퀘스트가 5개 제시 되었다. 뭐 꼭 이 퀘스트를 다 거쳐야 좋은 PM이 될 수 있는것은 아니고 이것 이외에도 많은 요소들이 필요하다. 하지만 운전을 아무리 잘해도 운전면허가 없으면 차를 살 수 없듯이 자신이 아무리 능력이 좋은 PM이라 하더라도 외부에서 자신을 인정 받으려면 객관적인 지표가 필요하기 마련이기 때문에 PM으로서 능력을 인정 받기 위해서는 위에서 언급한 프로젝트는 다소 힘들고 피곤하더라도 본인이 적극적으로 움직여서 경험을 쌓을 필요가 있다.
그렇다면 PM은 어떤가. 사실 IT 프로젝트에서 처음에 단순히 개발자로 참여해서 PL이 되고 그 이후에 PM이 되고 나면 더 이상 레벨이 올라가지 않는것 같은 느낌이 든다. 어려운 프로젝트도 있고 비교적 쉬운 프로젝트도 있지만 결국 PM이 하는 일은 앞서서 이야기한 몹잡고 퀘스트 깨는것과 같이 프로젝트 사이클에 따른 반복이기도 하기 때문이다. 그런데 게임에서와 마찮가지로 그 단위 작업이 좀 지겨운 경향이 있더라고 자신의 레벨이 뭔가 올라 간다면 좀 더 즐겁게 작업 할 수 있고 즐겁게 작업 하면 성과도 좋아 질 수 있게 된다.
그렇다면 자신의 레벨이 올라가는 프로젝트는 어떤것이 있으며 그런 프로젝트를 맡으려면 어떻게 해야 할까? 이른바 PM으로서의 캐리어를 관리 하려면 어떻게 해야 할까하는 이야기를 한번 해보도록 하자
첫번째 회사에서 가장 큰 프로젝트를 맡아라.
흔히 사람들이 잘못 생각하는 것이 규모가 큰 프로젝트는 어렵고 규모가 좀 작은 프로젝트는 쉬울꺼라는 느낌이 든다. 그리고 규모가 작은 프로젝트를 해보면 생각보다는 쉽지가 않다. 그러면 아 이렇게 작은 프로젝트도 어려운데 더 큰 프로젝트는 얼마나 더 어려울까.. 하는 생각이 들면서 위축되기도 한다.
하지만 내 경험상 프로젝트의 난이도는 결코 프로젝트의 규모에 비래하지 않는다. 하지만 프로젝트의 이슈나 리스크는 확실히 프로젝트의 규모에 비래하는 경향성이 있다. 그런데 왜 프로젝트 규모와 난이도가 비래하지 않는다고 하는걸까?
프로젝트가 크면 그만큼의 지원과 여유가 생기기 때문이다. 예를 들면 프로젝트가 크면 기술적인 이슈가 생길 가능성도 크지만 투입된 프로젝트 인력을 좀 더 핵심 개발자들로 구성할 수 있다. 금액적으로도 어느정도 여유가 생기기 때문에 리스크에 대한 예비비도 생각할 수 있게 되고 본사의 지원을 받기가 비교적 쉽기 때문이다. 따라서 자신이 할 수 있는 가장 큰 프로젝트를 맡으려고 노력하고 될 수 있으면 회사에게 가장 큰 프로젝트를 맡을 수 있도록 노력 하는 자세가 필요하다. 결국 PM은 어느정도모의 프로젝트를 관리해 봤느냐로 판단되기 때문이다.
두번째 금융권 프로젝트를 맡아라.
IT 프로젝트중 가장 보수적인 프로젝트는 금융권 프로젝트다. 금융권 프로젝트는 대부분 수주금액도 크고 요구되는 기술수준도 높다. 게다가 금융권 프로젝트의 경험이 없는 사람은 참여하기가 무척 까다롷다. 그래서 자신의 이력서에 금융권 프로젝트가 있느냐 없느냐는 PM은 물론이고 개발자의 몸값이나 역량판단에 중요한 잣대라 될 수 있다. 따라서 될 수 있으면 금융권 프로젝트에 참여할 수 있도록 노력 하는 것이 좋다.
세번째 다수의 협력업체를 관리하는 프로젝트를 맡아라.
같은 규모의 프로젝트라도 다수의 협력사를 관리하는 프로젝트와 그렇지 못한 프로젝트는 관리 난이도가 확연하게 차이가 나고 요구되는 스킬셋도 다르다. 따라서 PM으로서 다수의 협력사들과 협업해서 휼룡하게 프로젝트를 진행해본 경험은 역량을 판단하는데 중요한 객관적 지표가 될 수 있다.
네번째 정식 감리가 포함된 프로젝트를 맡아라
일반적으로 규모가 크면 감리가 포함된다. 공공분야에서는 프로젝트 규모가 5억이 넘어가면 감리를 필수적으로 포함해야 한다. 물론 IT감리는 사후적이고 문서 꼬투리 잡기에 치우치는 등 프로젝트를 진행 하다 보면 왜 돈 주고 이런 뻘짓을 해야 하나 회의감이 들때도 있지만 프로젝트 방법론에 따른 정식적인 진행을 외부에서 체크해주는 것과 그렇지 않은것은 아무래도 차이가 있다. 그리고 감리에 대한 대응이나 감리에 필요한 산출물을 제출하는 것도 한번 경험해 보지 않으면 대응하기가 상당히 까다로울 수 있기 때문에 감리가 포함된 프로젝트를 경험해 보는것도 PM으로서 꼭 필요한 경험이라고 할 수 있다.
마지막으로 하드웨어를 포함한 프로젝트를 맡아라.
프로젝트에 하드웨어가 포함 되면 고려해야 할 사항과 프로젝트 진행이 많이 달라진다. 따라서 하드웨어가 포함된 프로젝트를 해보는것이 PM으로서의 능력 향상에 도움이 된다.
자 PM의 레벨을 올리는 퀘스트가 5개 제시 되었다. 뭐 꼭 이 퀘스트를 다 거쳐야 좋은 PM이 될 수 있는것은 아니고 이것 이외에도 많은 요소들이 필요하다. 하지만 운전을 아무리 잘해도 운전면허가 없으면 차를 살 수 없듯이 자신이 아무리 능력이 좋은 PM이라 하더라도 외부에서 자신을 인정 받으려면 객관적인 지표가 필요하기 마련이기 때문에 PM으로서 능력을 인정 받기 위해서는 위에서 언급한 프로젝트는 다소 힘들고 피곤하더라도 본인이 적극적으로 움직여서 경험을 쌓을 필요가 있다.
'나는 PM(Project Manager)이다 ' 카테고리의 다른 글
나는 PM(Project Manager)이다 - 6. Show must go on (0) | 2018.03.13 |
---|---|
나는 PM(Project Manager)이다 - 5. 섀도우스트라이커의 역할 (0) | 2016.07.06 |
나는 PM(Project Manager)이다 - 3. PM은 고스톱쳐서 되는게 아니다. (0) | 2011.10.19 |
나는 PM(Project Manager)이다 - 2. 쇠고기만 등급이 있는것은 아니다. (0) | 2011.09.29 |
나는 PM(Project Manager)이다 - 1. PM으로 태어 나는 사람은 없다 (0) | 2011.09.16 |