Project Manager으로서 첫 프로젝트인 'mintRedmine'이 끝이 보이고 있다.
PM 이라는 직책을 맡고 팀이 셋업되면서 '좋은 PM'을 구체화시키고자 책도 읽어보고, 여러 선배들의 글을 읽으며 '좋은 PM, 혹은 잘하는 PM은 대체 어떤 사람일까?'라는 것에 대해 참 고민을 많이 했다.
좋은 PM은 어떻게 될 수 있을까? 라는 질문에 수학공식처럼 딱 맞아 떨어지는 답은 없겠지만, 그리고 누구나 할 수 있는 당연한 말일지 몰라도 프로젝트들을 앞으로 진행하며 고민했던 부분을 정리하고 반성하다보면 조금 더 '좋은 PM'이 될 수 있지 않을까 하는 생각을 해 본다.
지난 시간 동안 나에게 가장 중요한 것은, '일정 관리'였다.
물론 PM이라는 사람이 해야하고 보여주여야 할 모습은 정해져 있지 않다. 상황에 따라서는 PL의 역활을 소화하기도 해야하며, 팀의 덩치, 그리고 목적에 따라 180도 달라지게 된다. 하지만 그 중에서도 기본적으로 중요하고 잘 진행해야 할 부분은 '일정 관리'다. '일정 관리'에는 Project를 진행하는 Sprint를 잘 나누고, 기간 내에 정확히 이루고자 하는 목표설정, 각종 회의와 회고에 대한 일정, 그리고 목표했던 일정에 지키는 것을 통합해서 이야기 할 수 있을 것 같다. 애초에 불가능한 일정을 잡지 않아야 하는 것은 당연하며, 그렇다고 해서 목적했던 날짜를 넘겨버릴 정도의 느슨함은 안 된다. 실제로 구현할 수 있는 일정을 잡고 끊임없이 팀원들과 현재 진행되고 있는 사항에 대해 공유하고 일정 안에 목표를 이뤄내도록 팀원들을 독려해야 하는 부분도 꼭 필요하다. 내 나름대로의 '일정관리'에서 가장 중요시 했던 부분은 'Aggressive'였다. 더욱 더 적극적이고 공격적으로 일정 보다 좀 더 빠르게 일을 처리하고 아웃풋을 내며, 항상 조금의 여유를 남겨놓아야 변화에 대해 받아들이는 것이 수월하기 떄문이다.
다음으로 중요하게 생각한 부분은 '사람'이다, '일하고 싶게 만든다.'
정해진 일정 안에 목표를 이루기 위해서는, 팀원들에게 채찍을 들어야 하는 경우가 많다. 이런 상황에서도 '일하고 싶게' 만드는 것은 분명히 어려운 일이다. 좀 더 구체적으로 이야길하면, 예를 들어 나의 경우에는 개발자가 원래 포지션이였기에 충분히 팀원들에게 기술 구현에 대한 부분에 대한 도움을 줄 수 있었다. 하지만 모든 일에 대해 애초에 도움을 주는 것이 아니라, (정확히 말하면, 이 역활을 PL이 하는 역활이지만, 우리 팀에는 따로 PL이 없었다. 그리고 PM이라 하더라도 개발적인 지식이 많으면 많을 수록 하는 소화할 수 있는 역활에 굉장히 큰 차이가 있는 듯 하다) 팀원들에게 역량에 맞는, 혹은 살짝 부담스러운 일감을 주고 스스로 최대한 해결을 하도록 한 뒤, 도움을 주었다. (팀원 중 대다수가 오랜 시간 개발을 한 개발자가 아니라서 가능한 방법이라고도 생각이 된다.) 그런 부분에서 일정과 관련 된 부분을 제외하면, PM이 해야하는 모든 것은 '사람'에 대한 부분이란 생각이 든다. 몇십, 몇백명이 되는 팀이 아니라면, 팀원에 대해 성격적인 부분부터 일을 처리하는 방식, 현재 회사생활이 어떠며 프로젝트에 대한 생각 등 다양한 부분에서 그 사람에 대해 잘 알아야 한다. 개개인마다 '일을 하고 싶어지게 하는' 동기 부여에 대한 방법이 모두 다 다르며, 어떤 식으로 일을 맡기고 어떤 식으로 이끌어야 내가 진행하는 방식에 익숙해질지 끊임 없이 고민을 했던 것 같다.
프로젝트를 진행하며 PM은 '선장'같다는 상상을 많이 했다. 내 배에 바다를 항해 할 선원들과 함께 바다로 나선다. 선장이 키를 항상 잡고 방향을 잘 잡아 나아가야 하며, 선장인만큼 그 배에서 가장 열심히 하는 사람이 되어야 한다. 선장이 매일 선실에서 잠만 자고 있으면, 장담하건대 선원들은 절대 뱃일을 열심히 하지 않는다. 일을 시켜야 하는 입장에서 일을 시키는 사람이 나보다 열심히 한다는 생각이 들지 않으면, 모두가 다같이 일을 하는 환경은 구축되지 않는다. 그런 부분에서 '큰 책임은 큰 힘을 가지지만, 더 큰 책임감을 안겨준다'라는 말을 몸으로 많이 느꼈던 것 같다.
셋째, 좋은 사람이 되어라.
일을 시키는데, 어떻게 좋은 사람이 되라거지? '좋은 사람'은 '착한 사람'이 아니다. 일을 하며 팀원들에게서 사람(PM)에 대한 불만을 최대한 갖지 않게 해야 한다. 팀원들에게는 PM은 '매력적'인 사람이 되어야 한다. 물론 어느 직장이든, 사람이 모여사는 사회라는 것이 자신에게 일을 시키는 사람에 대해 '좋지 않은' 이야기를 하게 되기 마련이지만, 최소한 '이 사람과는 정말 일 못하겠다. 일이 짜증나는 것이 아니라 저 사람이 짜증나서 일을 하기 싫다'라는 생각이 들면 안 된다는 것이다. 팀원들이 최고의 컨디션으로 일에 최대한 집중을 했을 때 프로젝트의 성공률은 높아진다. PM이 '나는, 나만 잘했어'라고 생각하는 것은 아무런 의미가 없다. 프로젝트를 하며 일을 팀원에게 줄 때에는 엄하게(?) 일을 시키고 일정을 진행하더라도 그 속에서 나오는 (설득, 칭찬, 독려 등 사람에 따라 다양한 방법을 통해) 불만을 최대한 없애주며 팀원이 하는 이야기에 귀를 기울이며, 상황에 따라 어느 정도의 '유도리'가 필요하다. 최소한 채찍과 당근 중 하나 만을 들고 팀원들을 이끄는 사람은 되지 않아야 한다. 당장 내가 일이 많고 일이 많아 스트레스를 받아 예민해져 있는데 언제 팀원들 이야길 듣고, 고민을 하느냐 라고 물을 수도 있지만, PM이기 때문에 팀원들보다는 좀 더 고생하고 좀 더 궂은 일을 해야 하는 부분은 감수해야 될 부분이다. 한 문장의 말처럼 분명 쉬운 부분은 아니다.
'이렇게 하면 좋은 PM이 될 수 있어'라는 글을 읽어도 당장에 답이 나오지 않고, '그래서 내가 뭘해야 하지?'라는 생각이 자주 드는 것은 어쩌면 이렇게 '사람'과 관련되어 있기 때문이지 않을까?
'옛글 > 프로그래밍이야기' 카테고리의 다른 글
객체지향 프로그래밍 도대체 무엇인가? (4) | 2014.07.16 |
---|---|
레드마인 안드로이드 앱 추천! 'mintRedmine' (5) | 2014.02.19 |
PM의 자질과 갖춰야할 것 (0) | 2014.02.08 |
초보 PM 이 갖춰야 할 '여섯가지 조건' (0) | 2013.12.19 |
Generic in java, what is the raw type? (0) | 2013.10.18 |