훗날 커리어를 재개하기 위한 기본 과제
나는 PM이란 직무를 사랑한다. 내 커리어를 발전시킬 더 좋은 방법을 고민하다 퇴사를 선택했지만 환경을 바꾸기 위한 시도였일 뿐 이 직무를 그만둘 생각은 없다. 내가 원하는 길을 확실히 알기에 여행하면서 틈틈이 공부를 지속하고 있다.
전 회사의 직원들과 사장과의 관계도 이상적으로 좋았다고 당당하게 말할 수 이유는 회사의 팀 문화와 애자일 정신을 높게 평가하며 좋아하기 때문이다. 회사와 좋은 인연으로 남는 게 쉬운 일이 아니라고 들었지만, 내게는 참 많은 도움과 상처를 동시에 주고받다가 정이 들어버린 소중한 공동체라 지금도 모두와 연락하고 지낸다. 같은 마음에 회사를 떠나며 마무리도 훌륭하게 잘하고 싶었다.
인수인계 파일을 몇 주에 걸쳐 만들고 깨끗이 잊고 있었는데, 태국에 있으면서도 전 직장 동료들과 자주 연락하다 보니 꽤 유용하게 파일이 사용되고 있다는 걸 알았다. 내가 했던 일이 가치 있었다고 느껴지니 '아, 시간 낭비한 게 아니었어. 내 시간이 소중하게 쓰였어' 하는 생각이 들어 희열이 컸다.
나 하나 없어도 회사는 굴러간다. 그래도 인수인계를 최대한 부드럽게 진행하여 조금의 차질도 없길 바랬다. 정이 들어서일 수도 리더들과의 친분이 두터워서이기보다는 내가 그동안 했던 일을 간단히 정리하는 동시에 회사가 '내가 원하는 긍정적인 방향'으로 잘 커지기를 내심 바랬다.
인수인계 파일뿐만 아니라 개인의 포트폴리오에도 써먹을 수 있는 형식을 고민했었다. 유튜브로 [퇴사한 이형]에서 자세한 방법을 10분 동안 설명해주는데 이거다 싶었다. PPT든, 에세이든, 프린트한 책이든 어느 포맷이라도 좋으니 아래의 카테고리로 나누라고 했다. (영어는 내가 붙이고 싶은데로 번역했다)
업무 리스트 (Work list)
성과 리스트 (Achievement list)
실패 리스트 (Failure list)
사람 리스트 (Communication API)
이렇게 크게만 나누고 그 안에는 내가 전달하고 싶은 부분을 세분화해서 넣으며 된다.
맨 첫 장을 통해 PM 팀의 업무가 두 카테고리로 나뉨을 표현한다. 첫째는 '팀 매니징', 둘째는 '프로젝트 매니징'이다. 이후 각 매니징 카테고리에서 정확하게 어떤 부분을 이행해야 하는지 서술한다. 회사마다 구조가 다르니, 참고만 하길 바란다.
Team managing은 박스가 세 개 있다. 각 박스에 해당하는 부분은 리소스 매니징, 온보딩 절차 관리, 플랫폼 관리 이렇게 세 부분으로 나눴다. 그대로 다음 장에 하나씩 서술해서 자세히 쓰면 된다. 또 각 팀 멤버가 관리하는 것은 무엇이고, PM팀이 어떤 업무를 할 때 다른 팀이 정확히 어떤 도움을 받는지도 썼다.
PM으로 맞닥뜨릴 수 있는 어려움, 헷갈릴 만한 부분이 뭔지도 넣었다. 특히 첫째, 어떤 프로젝트가 배포되었는데 버그가 생길 때 문제 해결을 위해 나서야 하지만 절대 자신의 책임이라 생각하고 자책하지 말라는 점. 둘째. 기획은 처음에 해놔도 이행 중에 바뀌니 Scope(범위), User story(유저 스토리)만 확실하게 정의하고 개발 기획은 개발 팀에게 맡기라는 점 등을 서술해서 넣었다. 새로 오신 PM 분들이 많은 부담감을 갖고 나처럼 번아웃에 휘말리지 않기를 바라는 마음에서다.
뜻하지 않은 버그, 개발팀에게 줄 업무 생성 시 분류법을 도식화해서 전달했다.
지표가 정리된 엑셀 파일, 기획 문서들, 그동안 참고했던 모든 파일들이 여기 포함된다. 위의 스크린숏은 기밀 내용이 숨겨진 아주 일부분의 내용이다.
이 부분은 딱히 아무것도 쓰지 않았다. "이 파일 전체가 내가 해왔던 업무를 서술하니 빈 공간으로 남겨놓겠습니다"라는 한 줄 썼다. 원래는 써야 하는데 시간이 없었다. 인수인계 파일이나 성과 정리하시는 분들은 꼭 채워 넣으면 좋을 듯하다.
주니어 PM으로 한동안 사수 없이 힘들게 버틴 결과 깨달은 점 몇 가지를 정리했다. 별 내용이 다 있는데 이 부분만 공개한다. 생각하면 부끄러운 기억이 참 많은데, 이렇게 공유하는 게 다른 PM들과 함께 성장하는데 도움이 될 것이라 믿는다.
한 일곱 가지를 정리해서 공유했는데 대표적으로 아래가 있었다.
배포 내용을 마케터들과 공유 시 개발 용어를 사용해 문서 작성 > 마케터들이 유저에게 전달 불가
아이디어를 다 받아들여 백로그에 올려놔 개발팀을 부담스럽게 한 점 > PM팀에서 필터링 필요
리더들과만 우선순위 체크 > 개발/디자인/QA 팀과도 이행 가능성 체크 필요
기획 '목적' 없이 일을 개발팀에게 전달 > 개발팀 동기 저하 > 마감일이 늦어질 수 있음
할까 말까 정말 고민했는데 결국 각 팀원 다 썼다. 1년 6개월 동안 모든 팀원들과 일했는데 친하지 않은 이들이 있더라도 모두의 업무 스타일은 대충 알고 있었다.
또 그동안 나를 팀에서 챙겨준 모든 분들에 대한 서프라이즈 선물, 감사 표시이기도 했다. 읽으면서 해당 팀원들이 웃기를 바라는 마음에서, 친했던 분들과는 사소한 얘기도 집어넣었다. "명상을 좋아하고, 주말에는 밖에 잘 안 나오신다" 등 특징도 썼다.
각 팀원이 선호하는 소통법도 다르기에, 맞든 아니든 내 주관적인 시선에서 써냈다. 어떤 분은 즉각 미팅을 좋아하고, 어떤 분은 업무용 메신저로 소통을 좋아한다. 그래서 Efficient to 부분을 가장 첫 열로 넣었다.
페이스북에서도 Communication API를 PM이 작성해서 각 팀원을 챙긴다. 전 직장 회사 구조는 PM이 모든 팀원을 챙기기에는 조직이 급격히 팽창하고 있는 상황이라 어려울 수 있다. 전체 팀이 완벽히 세팅되기 전까지는 이 정도만 알면 되겠다, 싶은 중요한 부분만 써냈다.
잘 만든 인수인계 파일 자체가 내 성과 리스트가 될 수 있다. 덕분인지는 몰라도 회사와의 마무리도 좋았고, 지금도 리더들과 카톡으로 소소하게 안부를 물어가며 잘 지낸다. 아마 다음 직장에서는 더 훌륭하게 잘 작성할 수 있을 것 같다.
소프트웨어 회사 PM으로 일하다가, 고된 커리어의 길에서 잠시 쉬고 있는 스물다섯입니다. 세계를 여행하는 디지털 노매드 인생으로 잠시 살렵니다
인스타그램: @babylion.eun