경력직 PM의 3개월간의 온보딩 회고

11월에 서비스 출시해요

(이전 글)을 보신분들은 아시겠지만, 10년 가까이 운영되던 여행 플랫폼 서비스의 레저 주문 시스템 PO로 약 2년6개월간 업무를 끝내고 최근 이직을 했다.

다행히, 3개월간의 검증기간은 넘어갔지만, 다른 PM 분들은 (또는 필자가 나중에라도) 비슷한 실수를 줄이시는데 도움이 되고자 글을 적게 되었다

온보딩은 왜 중요한가?

아무리 오랫동안 일은 해온 사림이라고 하더라도, 생판 모르는 새로운 조직에 가게 된다는 것은 어려운 일 인것 같다. 오랫동안 손 발 맞추어 왔던 환경을 버리고 가게 되는 것이다. 새롭게 들어가게 되는 사람이나, 기존에 있던 사람이나, 일을 하던 스타일이 다를텐데, 기대치와 업무 스타일을 맞추지 않으면 누구라도 본인의 100%의 아웃풋을 내기가 힘든 것이다. 오랫동안 사귀던 사람과의 결혼해도 맞춰야 할 것이 많은데, 갑자기 새로운 조직에 들어가서 하루의 1/3 이상을 같은 목표를 향해 나아가는것이 쉬울 수가 없다.

기존 조직들의 온보딩 프로세스

생각해보면 지금까지 일했던 대부분의 조직은 온보딩이라는 프로세스가 굳이 없었다. 너무 작은 회사에서 창업 또는 초기 멤버로 일을 했었다. 직전 회사는 나름 큰 회사였지으나 가자마자 완전 신규 프로젝트를 PO인 필자와, 개발자분 한분, 딱 둘이 붙여놓고 '우리가 이런 비지니스를 신규로 출시 할려고 하니까 이제부터 시작 해보세요'라는 요구사항만 있어서 당황했던 경험도 기억이 났다. 

이번에 새롭게 합류한 팀은 팀 자체가 만들어진지 약 1년정도가 되었으며, 이제야 새롭게 제품의 방향성을 설정하고 만들어가고 있었던 것이다.(면접 때 들었던 제품의 방향성이 입사 할 때는 또 조금 달라져 있었다)

회사 자체의 온보딩 프로세스

현재 온 조직은 상장 게임사의 신규 프로젝트 팀으로써, 딥러닝 기술 중 하나인 TTS 기술을 활용하여 새로운서비스를 만드는 팀으로써 약 1년간 다양한 피봇과 시도로 MVP를 만들어서 테스트를 하면서 최종적으로, TTS를 기반으로 한 UGC 서비스를 정식으로 만들어보기로 하고 이를 위한 다양한 조직원을 추가 채용하고 있는 상황이었다.

해당 주의 첫 출근자는 매주 월요일에 입사를 시켜서, 해당 주 사람들을 모아서 약 반나절동안 온보딩 프로세스를 거치고, 점심먹고는 실무팀으로 합류하는 프로세스가 존재했고,이후  3개월 동안 중간중간 교육 훈련이 있었다. 별건 아니지만, 회사의 핵심가치등을 알려주고, 같이 입사한 사람들끼리의 나름의 유대감을 가지게 하는것이 목표였던것 같다. 대부분 사람들은 이제 지나가도 얼굴이 기억 안 날 정도로 까먹었지만, 집이 가깝거나, 출퇴근시간이 겹치거나, 업무가 조금 겹치는 분들은 지나가면서 인사를 하면서 약간의 심리적인 안정감을 주었다.

내가 맡은 서비스는 어떻게 진행되고 있었나?

해당 서비스의 핵심인 TTS 툴은 상당히 많이 만들어져서 이미 사내에서 테스트를 하는데 문제 없는 정도로 만들어져 있었으며, 이렇게 만들어낸 콘텐츠를 다양한 감상자와 콘텐츠 크리에이터가 모여서 콘텐츠를 감상하고 커뮤니케이션 할 수 있는 UGC 앱 서비스는 기존에는 노션으로 만들어서 MVP만 맛 본 상태였다.  필자는 가자마자 거의 스프린트 1 느낌으로 개발 계획을 세우고 만들려고 하던 중이었다. 필자가 합류한게 7월 중순이었는데, 그때 출시 목표는 9월말로 잡혀져 있었다.(현재는 11월 초로 변경했다) 나름 지금까지의 개발 경험으로 보아, 2달동안 정식적인 서비스를 만든다는 것은 아주 어려울것 같다고 생각을 했지만, 그때는 9월말 출시가 어렵다는것에 대한 근거를 찾기가 어려웠다(너무 오래전 경험이었다)

개발 프로세스는 마일스톤을 4개로 나누어서, 스토리를 점검하는것으로 진행했고, M1= 우리 서비스 만의 핵심 가치 기능인 콘텐츠를 확인하고 플레이 할 수 있는 스토리 점검,  M2= 회원가입, 프로필, 댓글 등 커뮤니티 서비스의 기본 기능에 대한 스토리 점검, M3= 각 기능을 고도화 하여 우리가 생각하는 페르소나 들이 잘 사용할 수 있는 스토리 점검 M4 = 어드민, GUI 디테일, 로깅 등 서비스를 운영하기 위한 준비 완료하기로 목표를 세웠고 조금씩 업무를 구체화 시키면서 현재는 11월 초로 목표를 잡은 상태이다.

<마일스톤 진행 과정>

나의 입사 초기의 실수

1. 문서 관리툴의 통일화

이전 조직에서는 화면에 대한 모든 상세 정책을 Confluence 문서에 쓰면서 화면은 첨부하는 형태로 진행을 했었기 때문에, 현 조직에서도 그렇게 할 것이라고 생각하고 Confluence 문서에 모든 세부 정책을 썻었는데, 현재 조직에서는 각 화면에 대한 상세정책은 디자이너 분들이 화면을 만드시면서, Figma에 모두 쓰고 있었어서 작은 헤프닝이지만, 이에 대한 씽크를 맞추는 작업을 한번 진행했었다. 생각해보니 예전에 필자가 맡은 프로덕트는 백엔드 플로우와 어드민이기 떄문에 API와 어드민 정책이 중요했기떄문에 대부분의 정책은 문서로 보고 진행을 했기 때문에 그게 가능했던것 같다. 이것은 작은 헤프닝으로 끝났었다.

2, 조직원과의 1on1의 부재로 인한 커뮤니케이션의 부재

현 조직은 1on1을 중요하게 여기고 있다. 매주 랜덤으로 조직 내 구성원을 1명씩 뽑아서 의무적으로 1on1을 하는 시간을 가지게 하고, 입사후 3개월동안은 조직장과 매주 1시간씩 1on1을 하는것이 필수였다. 조직장과 1on1을 매주 하면서 다양한 이야기를 했었고, 이 때 조직장이 시간 나면 조직의 모든 사람과 1on1을 하라는 피드백을 주셨지만, '시간'이 나지 않는다고 판단해서 1on1을 먼저 제안하고 진행한 적은 없었었다

왜냐하면 합류하자마자 바로 앱서비스의 첫번째 마일스톤의 리딩을 했어야 했는데, 조직에 합류 한지 얼마 안 되어서, 프로덕트 및 방향성에 대해서도 필자가 알고 있는것이 많지 않았기 떄문에 뭐 하나 하는데도 초기에는 오래 걸렸고, 또 아직은 먼저 티타임을 가지자고 이야기 하는것 자체가 민망했었다. - 아마 조금 안정 되면 해야겠다고 생각했으며, 어쩌면 그 날은 안왔을지도 모를것이다.

스펙 공유 일정의 지연

그러는 사이에 M1과 M2에 대한 리딩을 필자가 하는것으로 이야기를 했고, 프로덕트 팀과 스프린트 일정과 계획을 세우게 되었었다. 사실 오자마자 누가 개발자고 누가 디자이너인지 얼굴도 헷갈리고 또 기존에 어떤 프로세스로 일을 했는지 잘 모르는 과정에서 서비스 정책을 세우고 리딩을 하려니 어려움이 많았다. 정책을 세우기 전에 이것저것 확인을 해야 할 것이 많은데 아직 누구에게 확인해야 하는지 몰라서, 문서 작업하다가 모르면 혼자 엄청 고민하다가 은글슬쩍 눈치 보다가 안바쁠거 같은 사람에게 물어보고 그러다가 하루이틀 지나가게 되었고, 결국 해당 정책에 대한 kick-off를 할 때는 이미 일정도 예정보다 며칠 늦어지게 되었다.

R&R에 대한 논의가 안되었던 부분

정책이 늦어지니, 화면 작업도 일정이 늦어지게 되었고, 당연히 개발 일정도 늦어질 것이 걱정되어, 디자이너 분께 혹시 해당 와이어프레임 작업이 너무 많으면 일부 화면을 필자가 진행하겠다고 말씀을 드렸으나, 이것 자체를 이상하게 생각하셨다는것을 알게 되었다. 예전 조직에서는 PM이 와이어프레임 작업까지 했던 경우가 있었는데, 현 조직에서는 와이어프레임은 디자이너의 고유 영역으로 정의되어 있었던것을 필자는 몰랐었다.

마음이 급했던것 같다

마일스톤 공유를 통해서 각각 개발을 진행하다가 보니 아무리 생각해봐도 필수 기능인거 같은데, 필자는 아예 놓치고 있었던 스펙을 깨닫게 된 경험이 있었다. 갑자기 마음이 급해져서 혼자 해당 기능에 대한 스펙을 어떻게 추가하고, 일정을 언제 잡아야 할지에 대해서 고민을 하면서 문서를 만들었는데, 조직장과의 피드백을 통해 필자 혼자 마음이 급했다는것을 알게 되었다. 스스로를 잘 하는 사람으로 증명해 보이기 위해서 이슈없이 잘 해결하는 사람이 되고 싶었는데, 놓친 것이 있다는것을 알게 되어 혼자 급하게 생각했던 것이었다. 돌이켜서 생각했을때 현 상황에서는 그보다 중요한 것이 더 많다고 판단했고, 이후로는 뭔가 해야 할 것 또는 내가 놓친 것이 생각나면 스스로 '이게 진짜 중요한 것인가?'를 먼저 생각해보고 이에 대한 근거를 하나씩 도입하는 습관을 들이게 되었다

이후 어떻게 했나

일단, 조직원들과의 신뢰쌓기가 우선이 되야 할것 같아서, 우선적으로 플랫폼 서비스의 프로덕트 팀(개발자,디자이너, 다른 PM)과 1on1을 다시 진행하면서 서로의 성향에 대해서 더 잘 알게 되었고, 지금까지 진행해왔던 업무 프로세스에 대해서도 확인하게 되는 자리를 가졌다. 이후에는 새로운 스펙 공유를 위해서 최대한 빠르게 초안을 공유하고, 그때그때 빠르게 해당 담당자분에게 논의하면서 정책을 정하는 형태로 진행을 하게 되었다. 그나마 다행인 점은 개발자분들은 이전 1년 동안 MVP를 찾아오면서 많은 시행착오를 해왔고, 그래도 최근에 프로세스가 많이 잡히고 있다고 생각하고 있으셨다. 또한, 요즘은 하루에 20-30분 동안은 실무를 하는 것보다, '지금내가 하는것이 정말 가장 중요한 것이 맞는지?'에 대한 근거를 찾는 데 시간을 쓰고 있다.

만약 내가 다른 조직에 새롭게 가게 된다면?

일단 모든 조직원들과 서로의 업무스타일과 기대치를 맞추는 것이 최우선이라고 생각한다

1. 나의 장점과 단점 2. 이를 통해 해당 조직에 어떻게 내가 기여 할 수 있는지 3. 업무 스타일을 어떻게 같이 맞춰 나갈것인지를 어필하면서, 기존 조직원들의 업무 스타일과 장점과 단점을 보는것이 가장 줗다고 생각한다. 그리고 모든 조직과 1on1을 통해서 더 좋은 업무방식을 같이 논의하는 형태로 진행하면 더 좋았을것이라 생각한다. - 대부분의 경우에 당장 스펙을 치는것보다는 서로에 대해서 알게 되는것이 오히려 더 빨리 가는 길이되는것 같다

기존 조직원들은 새로 들어온 사람에게 어떻게 해야 할까?

필자가 해당 내용을 현 조직원들에게 공유했더니, 같이 일하는 리서처분께서도 새로운 PM이 올 때 본인이 도와 줄 수 있는것이 있는지 고민을 하셨다고 하셨다. 돌이켜서 생각해보니 이분이 한번씩 와서 이분이 고민하는 포인트도 이야기 하시고 필자에게 어떤 고민이 있는지 살짝 살짝 물어보시는것이 필자에게 심리적으로 큰 도움이 되었었다. 새로 들어온 사람에게 2가지 정도를 하면 된다고 생각한다. 1. 1on1 티타임을 하면서 그사람이 어떤 사람이고 그동안 어떤 성과가 있었고, 자신있는것은 무엇인지 도움을 받을 만한 것은 무엇인지 물어보는 것이다. 2. 가끔 그사람에게 가서 본인이 고민하는 것에 대한 의견을 물어보는것도 충분히 도움이 된다.(사실 당신에게는 도움이 되지 않는 의견일지라도) 새로온 사람에게는 '내가 이사람에게 조금이라도 도움이 된거 같다'는 기분이 들어서 조직에 대한 만족감이 늘고 그사람과의 친분감도 더 들게 될 것이다.