어쩌다 PM
코딩은 너무 재미없는데...
어쩌다 보니 PM으로 일한 지 벌써 3년이 넘었다.
그리고 특이하게도 PM으로 3번째 회사를 다니고 있다. (a.k.a 프로이직러...)
그리고 보통의 PM이 그렇듯 PM이전에 개발을 해봤다. (PM은 회피성 선택이랄까. 먹고는 살아야지.)
지금 다시 돌아보면 "개발자였습니다"라고 하기 무색할 만큼 모르는 주니어 중에서도 주니어였지만 그때의 경험이 생각보다 많이 도움 되는듯하다.
내가 PM을 처음 선택했을 땐 단순히 '서비스 기획' 이 하고 싶어서였다.
사실 PM이 뭔지도 몰랐다. (그냥 Project Manager라고 경력 높으신 분들이나 하는 건 줄 알았지...)
개발이 너무 재미없고 IT는 계속하고 싶고 그래서 잘할 수 있는 게 뭐가 있을까 고민하다 '기획'을 찾아보다 정신 차려보니 PM이 되어있었다.
요즘은 PM에 대한 소개자료도, 일하는 방식, 책 등등이 다양하게 있는데 그 당시에는 이렇게까지 유명하지 않았던 걸로 기억한다. 지금처럼 부트캠프가 생기고 각종 PM들의 강의와 커뮤니티는 정말 소수의 사람들에게만 해당됐던 내용이랄까
요즘은 pm만 입력하면 Product Manager 캠프가 많이 보인다"누군간 해야지..."
곧 4년차가 되어가는 지금의 나는 '어쩌다 보니' 팀 전체를 매니징하는 역할을 임시로 맡아버렸다.
기존의 팀원들은 PM의 역할도 몰랐고 스타트업에서의 업무 방식을 전혀 이해하지 못하는 상황으로 방치되어 있었다.
덕분에 개발팀과 기획팀(현재는 이름이 바뀌었다)의 사이는 하늘과 땅을 넘어선 우주 끝까지 멀어져 있었고 기획팀은 하나를 질문할 때도 '요청해도 될까?', '혼나면 어떡하지?' 라는 생각을 항상 기본으로 갖고 업무를 진행하고 있었다.(이러니 일이 될 리가 있나...)
회사가 이렇게 극단적인 상황이었을 줄은 합류 전까지 꿈에도 상상 못 했다.
제안을 받을 당시만 해도 "기획팀과 개발팀 사이가 좋지는 않아 가면 할 일이 많을 거다"라고는 들었는데 이 정도일 줄은 아주 꿈에도 몰랐지...
합류 후 일주일 간 업무 진행방식을 지켜본 뒤 바로 행동에 옮겼다. 내버려두었다간 도저히 돌아올 수 없는 강을 건널 수도 있겠다는 생각이 들어 주제넘었지만 끼어들어서 교통정리를 시작했다.
나 : "OO님 이 기획에 대한 본래 목적이 뭔가요?"
B : "아 그건 원래 대표님이랑 협의했던 거라 그냥 하면 돼요"
나 : "지금 scope에서 이게 꼭 필요한 건가요? Case별 flow는 어디 있나요?"
B : "간단한 거라 그냥 하면 되지 않나요? 이거 이거만 추가하면 되는 건데..."
나 : "이 이후에 OO도 필요할듯한데 화면은 어디 있나요? 어떤 경우에 이걸 동작시킬 거죠?"
B : "아... 그러네요"
이렇게는 되지 말자.되게 충격적인 첫 회의였다. 그 어디에도 회의록도 과거 히스토리도 이 기획을 통해 얻고자 했던 목표도 정의된 바가 하나도 없었기 때문이다. 경력이 나보다 한참 많음에도 불구하고 이런 식의 기획을 해왔다는 게 이해할 수 없었고 이런 기획서를 계속 받아서 개발했을 개발팀이 오히려 안쓰러워지기 시작했다.
그 이후 관련 회의는 모두 참석하여 옵저빙을 하기 시작했고 기획서를 개발팀에 넘기기 전에 직접 하나둘씩 검토를 하여 시간이 걸리더라도 피드백을 주며 수정하도록 했다. 정말 '어쩌다 보니' 매니징의 역할을 하고 있는데 아마 R&R을 따지고 내가 지원해서 간 회사였으면 안 했을지도 모르고 또 기존의 팀원들이 나의 피드백을 무시하거나 받아들이지 않을 수도 있는데 다행히(?) 그런 상황은 벌어지지 않고 있다. (물론 아직까지는)
정말 '어쩌다 보니' 매니징을 하고 있고 '어쩌다 보니' 신입 아닌 신입들을 가르쳐주는 듯한 상황을 겪고 있는데 그러다 보니 나도 완전 주니어 때 알았으면 했던 것이 생각났다.
"PM이 되기 위해 가장 필요한 게 무엇일까요?"
이 질문에 대해 명확하게 답변을 내릴 만큼의 경험은 나에게 아직 많이 부족하다고 생각한다.
하지만 지금의 경험에서 정의 내려본다면
1. 상대방의 입장에서 생각하기
어떻게 보면 가장 쉬우면서도 어려운, 마치 따뜻한 아이스 아메리카노 같은 문장이다.
가장 많이 실수하는 것 중 하나가 기획을 하는 입장이 되면 사용자의 입장이 아니라 기획하는 사람의 입장에서 생각하는 것이다.
일단 사용자는 아무것도 모른다.
'PM이 왜 그렇게 만들었는지'에 대한 궁금증이나, '사용자가 왜 그렇게 행동했는지' 세세한 이유는 없다.
그냥, 단순히 그냥 그럴 것 같아서가 대다수이다.
그래서 PM은 항상 사용자의 입장에서 그들이 어떻게 행동할지, 버튼 하나, 글자 하나에도 어떻게 받아들일지를 지속적으로 고민하는 게 중요하다.
그리고 사용자들 중 이것저것 많이 눌러보거나 예외 케이스를 찾아보겠다고 별에 별짓을 다하는 이상한 사람(나처럼)이 있으니 모든 케이스를 꼼꼼하게 챙겨야 한다.
또한 문서를 작성할 때도 내 의식의 흐름대로 작성하는 게 아니라 읽을 사람을 배려해서 작성하는 능력이 필요하다.
글은 말을 하는 것보다 정리가 가능하기 때문에 한 문장을 작성하더라도 여러 번 읽고 또 읽어 불필요한 문장을 제거하고 핵심만 간결하게 전달하는 것이 가장 좋다.
2. 솔직한 자세
PM은 만능이자 천재가 아니다. (극소수는 제외하고...)
스페셜리스트와 제너럴리스트 듀얼 코어가 될 수 없고 각자가 살아온 인생과 경험이 다르기 때문에 모든 것을 다 알 수 없다.
그래서 모르면 모른다고 솔직하게 말하고 도와달라고 하는 게 백배 낫다.(너무 무지성은 좀 어려울지도...?)
몰라서 대충 얼버무리고 질질 끌고 가다가 나중에 딴소리하면 결국 신뢰를 잃어 앞으로의 모든 행동과 문서에 신뢰가 사라질 수 있다.
그리고 모른다고 하면 대다수(특히나 개발자)는 친절하게 알려주시는 분들이 있으니 일단 시도를 해보는 것이 중요하다. 가끔 까칠한 분들도 계시지만 열심히 친한척하며 질문하다 보면 그래도 벽을 많이 허물 수 있다.
물론 그렇다고 핑프는 절대 금지다.
내가 알고자 하는 것에 최소한의 리서치는 해보고 질문하자.
3. 멀리 보는 시야
"나무를 보지 말고 숲을 봐야 한다"라고 많이 얘기한다.
하지만 문제 앞에 서게 되면 당장의 그 문제만 빠르게 해결하려는 욕심이 생긴다.
그 문제가 어디서부터 시작된 것이고 어떤 기능까지 연관되어있는지를 알아야 효율적으로 행동할 수 있다.
자칫하면 일을 2번 하게 되어 개발자에게 2번 욕먹는 사태를 만들 수도 있기 때문이다.
이건 하루아침에 얻을 수도 없고 책을 본다고 해서 얻을 수 있는 건 아니라고 생각한다.
좋은 사수를 만나면서 배우기도 하고, 때론 혼나기도 하고, 다른 사람의 경험을 간접적으로 경험하면서 차츰 쌓이고 쌓이다 보면 얻을 수 있는 것이라 생각한다. 필요한 역량이지만 '노력하는 자세'가 핵심이지 않을까 싶다.
그래서 결론은
물론 어쩌다 보니 아직도 모든 상황은 진행형이다.
어쩌다 보니 개발에서 PM으로 전향을 했고 어쩌다 보니 벌써 PM으로 3번째 회사에 재직 중이며 어쩌다 보니 팀원 전체를 매니징 하는 상황에 놓여버렸지만 이 상황에 대한 짜증이나 스트레스는 생각보다 별로 없다.
이 과정에서 내가 배워가는 것이 있고 언젠가는 팀 리드, 그 이상의 자리에서 해야 할 일이라 생각했으니까 '남들보다 빠른 경험을 하는 것이다'라고 생각하면 자기 위로를 하고 있다.
다만 이 과정에서 더 좋은 피드백을 하여 팀원들이 성장하고 나 또한 성장하기 위해 지속적으로 노력해야겠다는 생각이 들었다.
'일단 도전해서 나쁠 건 없다'
이건 스스로가 전부터 정했던 원칙이다.
'할까? 말까?' 고민하지 말고 일단 해보면 그것 또한 좋은 경험이었고 언젠간 도움이 되리라고 나는 미래의 나에게 오늘도 스스로 증명하고 있다.
컴공을 선택했던 것도, 개발에서 PM으로 전향했던 것도 고민만 했다면 지금까지 오지 않았을 일일지도 모르지만 일단 해보니까 더 다양한 경험을 할 수 있어 지금의 나에게 많은 도움이 되었던 것 같다.
어쩌다 PM이 되었지만 어쩌다 보니 일을 즐기게 되는 나를 만든 것 같아 뿌듯함을 느낀다.
세상의 모든 어쩌다 화이팅!
