PM이 되기 위해 이런 준비가 되어 있어야한다고 말씀 드리기는 어렵습니다만
적어도 그간 많은 PM님들과 협업하면서 몇가지 특징을 알려드리는 것이 도움이 되실 수도 있겠습니다.
[개발자 출신이다?]
틀린 말은 아닙니다.
그분들도 분명 '왕년에 개발을 끝내주게 했던' 분들임에는 분명합니다만
그분들이 경험한 개발 패러다임은 지금과는 다릅니다.
더우기 xper에서 생각하는 역할자들이나 실천 방법이나 기법이나 공정과는 거리가 먼 경험을 하신 분들이라 지금의 우리와 견주어 생각하긴 좀 무리가 있습니다.
고객사 정보 전략에는 개발 스펙이 아닌 분들이 관리 PM을 하거나
간혹 수행사 영업이 관리상의 이유로 PM을 하는 경우도 있긴 한데
문의하신 분이 생각하는 (일반적으로 이해하는) PM과는 거리가 있으므로 예외로 보셔도 무방합니다.
[온갖 관리 기법과 측정과 예측에 능해야한다?]
분명 필요한 부분입니다.
프로젝트 관리가 기본적으로 돈과 사람과 시간을 다루는 일이기 때문입니다.
그래서 사실 개발 스펙이 중요하냐는 것과 좀 거리가 생길 수 있습니다.
기본적인 원가 계산은 되어야 돈을 다룰 것이고
어느 정도 개발 경험이 있어야 시간을 예측할 수 있습니다.
남은 건 사람인데 이 사람을 다루는 스킬 때문에 젊어서는 하기 어려운 이유가 됩니다.
결국 경험이 중요한 것인데 이것이 부족할 때 보완하는 것이 각종 기법입니다.
각종 기법은 다행히도 전문적으로 교육 받은 이들의, 도움이 있을 경우 위임이 가능합니다.
정량적 품질관리에 능한 품질 관리자를 다행히 만난다거나
비용 산정과 네고에 능한 영업을 만난다거나
개발자와 커뮤니케이션이 잘되는 PL을 만나는 경우가 그러합니다.
이러한 일이 가능하기 위해서는 어떤 역량이 필요한지를 찾게 되는데 그 때 창준님이 말씀하신 PMBOK을 숙독하시면 될 것 같습니다.
[정리]
제 주변 얘기에 한정되긴 합니다만
대체로 훌륭한 PM이라고 존경 받는 분들의 특징을 나열하자면
- 개발자가 뻥치는 것을 경험으로 가려내어 적정한 공수를 잡을 수 있다.
- 개발자가 놓친 것을 사전에 인지하여 PL로 하여금 챙기도록 지시할 수 있다.
- 절대적으로 부족한 시간과 비용 내에 작업을 완료하기 위해 우선 순위를 조정하고 협상할 수 있다.
- 사람 간의 커뮤니케이션 오류로 유발되는 각종 논쟁에 휘말리지 않고 역할을 재분장하고 액션 플랜을 세워 지시할 수 있다.
- 상대적으로 IT 배경 지식이 약한 고객의 심기를 건드리지 않는 범위에서 말도 안되는 요구를 부러뜨릴 수 있다.
- 전체 상황을 보지 못하고 개발 이슈만 가지고 스스로 좌절하고 무너지는 개발 결벽증이 있거나 순진한 개발자를 설득할 수 있다.
- 등등...
결국 많은 분들이 말씀하시는
'개발하다 나이되니 관리하게되고 PM 하게 되더라'는 말도 다 맞고
'개발 보다는 관리 기법이 필요하더라'는 말도 다 맞습니다.
다만 왠만해선 안채워지는 것은 '사람 다루는 방법' 입니다.
이건 개인의 성향이나 인생 경험, 인간 관계인지라
타고나거나, 부단한 노력이 있을 수 밖에 없을 것 같습니다.
이제까지 모신 PM님들을 돌아봤을 때
'존경합니다'라고 말할 수 있는 분이 손에 꼽을 만한 것은
대학 졸업장으로는 취할 수 없는 군살 같은 경험 때문인 것 같습니다.
좋은 고민을 하시는 걸 보니
훌륭한 PM님이 되실 것 같습니다.
응원할께요.