이직 2년차 회고: Global 게임 회사의 Product manager - (2)
Previously on Gi's retro
"회사에 필요한 일이면서, 내가 잘할 수 있는 일, 그리고 회사도 나도 내가 하면 좋을 것 같다는 일을 맡아볼 수 있는 기회가 인생에 몇번이나 있을까? 그런 의미에서, 지난 2년은 행복했고 지금도 행복합니다."
요약
예전에는 우선순위 조정이라는 것이 Agile 교과서에나 나오는 환상속의 동물이 아닐까 생각했다. 이 회사로 옮겨 보니, 우선순위 조정은 이견이 따로 없을 정도로 쉬웠다. (늘 P0급 업무가 줄을 서있었으니.) 그럼에도 불구하고, 바쁘게 업무들을 쳐낸 만큼, 올해는 백로그에 쌓아두었던 대규모 개편을 준비할 수 있어 기쁘다.
말 뿐인 우선순위 조정
이전 회사에 속해 있을 때의 이야기를 다시 잠깐 가져오자면, 대부분의 요구사항은 Top-down으로 이루어지는 경우가 많았다. 물론, Top-down의 장점도 분명 있고, 때로는 올바른 방향으로 이끄는 리더의 Top-down은 그 결과물과 속도가 매우 아름다운 경우도 있다. (누구나 선망하는 테슬라의 자동차라던가, Apple의 iPhone 4라던가.)
대기업 8년차, 대부분의 요구사항은 보통 일정과 함께 하늘에서 떨어지는 경우가 많았다. 그러다 보니 자연스럽게,
- 기존에 세워두었던 Roadmap은 쉽게 흔들리기 마련이고,
- 그나마 이번 Iteration에서 예정해 두었던 아이템을 하늘에서 떨어진 친구가 다음 Sprint로 넘어가 주면 다행이었다.
- 하늘에서 떨어진 친구를 우선 Iteration 안에 배치하고, 다음 Iteration으로 도저히 넘길 수 없는 친구들을 이번 일정에 킵하는 경우가 많았다.
그리고 따라오는 결과는 제법 자주, 이랬다.
- 개발자는 야근을 하고,
- 기획자는 미안하고,
- QA는 일정이 모자라니 OK 도장을 찍을 수 없다며 울부짖지만,
- 전략팀 또는 홍보팀은 예정된 일정이 있으니, (제대로) 나올지 안나올지 모르는 기능을 가지고 Biz dev도 하고, 기사도 준비하고, 때로는 상품(요금제라던가, 번들링이라던가)도 출시한다.
대기업 8년차, 위와 같은 경험을 자주 겪다 보니, 다른 회사 App을 사용하면서 어딘가 모르는 불편함이 느껴질 때 "여기는 왜 이정도 밖에 하지 못할까?" 에서, "여기도 뭔가 사정이 있었겠지." 라는 생각을 먼저 하게 되었다고 할까.
작은 조직은 Nice-to-Have만 진행해도 바쁘다.
반면, 이 회사에 와서 진행했던 대부분의 프로젝트는 사실 대부분이 P0 였다. Priority 0, 혹은 Blocker. 용어가 익숙하지 않은 분들을 위해 한마디로 설명하자면 이거다.
모든 다른 업무를 내려놓고 지금 당장 해야 할 일
실제 사례로 보자면 다음과 같다. (날짜는 많이 과장했지만, 실제로 19년에 월급을 받을 수 있었던 이유들이다.)
- 내일 모레 게임이 출시되어야 한다. 그런데 갑자기 회원가입이 안된다.
- 다음주에 신작 게임이 출시되어야 한다. 그런데 '기존 우리 고객'이 로그인을 시도하면 무조건 새 아이디를 만들어야 한다고 한다.
우리 조직은 개발자 3명 (백엔드 2, 프론트엔드 1명)과 디자이너 1명, 그리고 정책/운영을 담당하는 기획자 1명, PM 1명으로 구성된 조촐한 팀이다. 그나마, 백엔드 2명 중 한명은 개발팀장 (Tech Lead)이시기 때문에, 1.0을 우리 팀에 할애하고 있다고 보기도 어렵다. 이 작은 조직으로, 2019년에 신작 출시를 위한 회원 시스템 개편 (모바일 대응, Social 계정 연동, 게임 규제 준수를 위한 실명인증)을 단 한번의 큰 펑크 없이 이뤄냈다는 것이 정말 지금 생각해도 놀랍다.
날짜는 의외로 늘 박혀있다.
사실 생각해 보면 날짜가 하늘에서 내려오는 건 동일하다. 회사의 사활이 걸린 프로젝트가 출시일이 정해져서 내려오는데, 메인 Product인 '게임'도 아니고 '회원' 때문에 출시를 미루자고 할 수는 없다. (사이버펑크 2077에 CDPR 계정 로그인이 안붙었다고 출시를 미루자고 하면, 그날 바로 짐싸서 회사를 나가야 하지 않을까.)
이 부분은 내가 작은 조직으로 옮기기 전에는 느끼지 못햇는데 결국 제품을 개발한다는 건, 큰 조직이던 작은 조직이던 날짜를 Product Owner, Product manager 마음대로 정하기는 거의 불가능에 가까운 것 같다. 내 돈 100%를 태워서 만드는 나만을 위한 제품이 아닌 이상, 늘 Stakeholder가 있고 Product team은 주로 일정에 맞춰야 하는 쪽인 경우가 많다. Biz dev에서 100억원 규모의 공동 마케팅을 따왔다고 하는데 Product가 준비가 안된다고 말할 수 있는 경우가 얼마나 있을까. (그러니까 사이버펑크 2077이 그렇게 출시된 거 아니겠는가.)
그렇기 때문에 작은 조직, 즉 '리소스가 부족한 조직'에서 우선순위 조정은 어찌보면 그다지 어려운 일은 아니다.
늘 P0의 업무로 캘린더가 가득가득 하기 때문에, P0 중에서도 도저히 이번 Iteration에 못할 것들을 고민하는 경우가 오히려 많다. 모든 부서에서 P0라고 생각하고 들고 온 일들을, 갖은 꼼수나 운영 땜빵으로 P1 (반드시 있어야 함. 없어도 죽지는 않음.) 수준으로 낮춰서 다음 출시일로 미루고, P0 인 업무들도 최대한 규모를 줄여 아래와 같은 상태라도 '출시' 도장을 찍자고 이야기를 해야한다. 그래도 다행인 것은 이러한 의사결정이 매우 신속하고 빠르게 일어날 수 있다는 것이다.
(그리고 그 의사결정을 못하는 조직은 결국 망하는게 아닐까.)
PO, 그리고 Product team이 우선순위를 조정할 수 있는 조직이라 가능했다.
우리 회사는 다행히, Product Owner이면서 Project manager인 나에게 의사결정에 대한 많은 부분의 위임이 이뤄져 있다. 우리 Product team이 최종적으로 결정한 우선순위 조정과 관련하여, 회사 내에서 의사결정이 매우 빠르다.
'어차피 날짜가 박혀서 내려오는데 무슨 Roadmap인가?' 라고 생각할 수도 있겠지만, P0와 P1을 나누고, 'MVP는 여기까지고, 나머지는 출시 후에 고칩니다.' 라는 것을 설득하는데도 그리 큰 비용이 들지 않는다.
이 회사로 옮긴 뒤에, 그 이유에 대해서 많이 생각을 해보았는데, 내가 생각하는 이유는 크게 다음과 같다.
구성원부터 리더십까지, 조직이 모두 같은 방향을 바라보고 있다. 100명 남짓한 직원이 있는 회사가 이렇게 한 방향으로 Align 되기도 매우 쉽지 않은데, 다들 하나의 명확한 목표와 가치관을 공유한다. 그렇기 때문에 의사결정 과정에서 우리의 '안'이 저 가치와 목표에 부합하는지만 서로 점검하면 된다.
또 한가지, 어차피 사람이 없다. 사람이 많다면 조금이라도 더 기능을 많이 우겨넣어 보겠지만, 어차피 개발자 2.5명이 전부다. (아무리 Agile이라 해도, 사실 기획/디자인은 먼저 일하고 빠진다. 늘 일정에 가장 큰 영향은 개발자다.) 애초에 리소스가 적으면, 그다지 고민할 여유는 없다. (물론, 경우에 따라 "그럼 외주 2명을 더 투입하면 어때요??" 라는 질문을 받을 가능성은 있지만, 다음 기회에 다뤄보기로 하자.)
마지막으로, 대신 사람 하나하나가 모두 뛰어나다. 앞서 '수퍼 개발자' 라는 말을 했는데, 사실 코드 리뷰를 PM인 내가 직접 하는 것이 아닌 만큼, 코드의 퀄리티는 나는 모른다고 하는 것이 맞다. 하지만 나는 Ownership을 가지고, 일정에 맞추어 꾸준한 Quality를 담보하는 디자이너/개발자가 가장 뛰어난 사람들이라고 생각한다. 결국 구성원 하나 하나에 대한 신뢰가 깔려있으니, 굳이 이 사람들의 일정에 Challenge를 하거나 의문을 가질 필요가 없다.
결론적으로, 위의 이유들 덕분에 하늘에서 '당장 모든 일을 멈추고 이것부터 해야한다'는 과제가 내려와도, 우리 조직이 잘 버틸 수 있었던 것이 아닐까.
그리고 팀과 사용자 모두를 기쁘게 할 프로젝트 준비하기
사실 작년에 신작 출시를 위해 많은 프로젝트를 수행했고, 엄청 바쁜 시간을 보내면서도 우리 팀의 가슴을 뛰게 하는 일이 한가지 더 있었다. 바로, 계정 관리 페이지의 대대적인 개편이다.
PC 게임만 10년 넘게 서비스 해온 회사이고, 19년 갑작스럽게 신작을 4개나 출시하시는 바람에 이 일정들을 맞추느라 우리 시스템엔 아직도 많은 헬리콥터 비둘기들이 존재한다.
올해의 첫 농사는, 비둘기들이 제대로 양날개로 날게 하면서도, 사실은 비둘기가 아니라 독수리였습니다! 하는 수준의 개편을 준비하고 있다. 개인적으로 PM에게 반드시 여유가 필요한 이유가 여기에 있다고 생각하는데, 현장 최전선에서 열심히 일을 쳐내는 디자이너/개발자와 한발짝 떨어져서, 우리 팀에도 의미가 있고, 고객에게도 좋은 아이템을 발굴해 내는 것이 꼭 필요하다. 아무리 돈받고 일하는 거라고 하지만, 개발자도 디자이너도 (그리고 나도) 공장의 기계부품이 아닌 만큼, 우리에게도 보람이 매우 중요하니까.
사실, 이게 Roadmap 관리의 중요성 중 하나라고도 생각한다.
- 우리가 지금 하고 있는, '당장 치워야 할 과제'는 언제 끝나는 것인지,
- 그리고 왜 지금은 헬리콥터 비둘기가 출시되어야 하는지,
- 우리의 비둘기는 언제 날개를 펴게 되는지,
- 그리고 언제쯤이면 이 비둘기들이 독수리처럼 날아오르는지.
나에게도, 나와 일하는 동료들에게도, 그리고 우리 제품을 기다리는 사내 Stakeholder 들에게도 머리속에 최대한 같은 그림이 그려지도록 하는 일. 그게 Roadmap 관리인 것 같고, (참으로 다행이도) 우리 회사는 그러한 Roadmap 관리가 가능한 조직인 것 같다.
'Retro' 카테고리의 다른 글
| 이직 2년차 회고: Global 게임 회사의 Product manager - (1) (4) | 2021.02.01 |
|---|---|
| 이직 2년차 회고 -1 : 대기업 Product manager 생활 (0) | 2021.01.13 |