# 동네북PM이 미움받는 이유
얼마 전 직장인 커뮤니티에서 누군가 질문을 올렸다. PM/PO일을 더 잘하고싶은데 어떤 책을 읽어야하냐는 내용이었다. 누군가 단 댓글에는 “미움받을 용기"책이 있었고, 크게 공감했다. PM으로서의 업무스킬나 역량보다 사실 가장 본질적이고 필요한 마인드셋이 바로 ”미움받을 용기“라는 키워드로 잘 표현되는 것 같다.
PM에게만 필요한 건 아닐지도 모른다. 모든 직장인, 모든 세상사람들에게는 미움받을 용기가 필요할지도 모른다. 그러나 유독 PM일을 할 때 이 용기가 더필요한 이유는 무얼지 고찰해보았다.
멤버들의 얽히고 얽힌 이해관계
프론트엔드와 백엔드의 R&R부터 ux는 좀더 섬세한 설계를 원하지만 프로젝트 일정 상 오픈스펙으로는 힘들다든지 여러가지 입장의 차이가 발생한다. PM으로서 이러한 입장 차를 조율하고 의사결정을 하다보면 어느 편은 불만이 생갈 수도 있다. 그 불만이 일이기에 크게 거슬리지않는 멤버가 있을수도 있고 그럼에도 거슬릴 수 있어서 PM에 대한 원망으로 번질 수도 있다. 멤버의 이런 불편한 감정을 PM이 느끼게 되는 순간이 올 수 있다. 나도 처음에는 이러한 감정들이 불편했는데 이건 어쩔 수 없는 부분임을 인정하고 그러려니 하는 것이 서로의 정신건강에 좋다고 본다. 그러나 내가 결정한 방향은 보편적으로 상식적이고 대다수에게 납득이 가능해야 한다는 철칙을 지키려고 한다.
책임 소재를 지울 수 있는 유일한 대상
역할이 명확한 업무는 아니지만 그레이한 영역들이 생기게 마련인데 이 부분들은 PM이 챙겨야할 업무로써 자리잡는다. 물론 이런 그레이한 일들을 모른체하고 두는 PM이 있을 수도 있다. 모른체하고 그냥 두어도 멤버들이 본인들 작업을 완수하기 위해 나서서 이슈잉하고 처리할 수도 있다. 그러나 병목을 없애고 정해진 기한 내에 완수를 하려면 모른체하는 것이 좋은 관리방법은 아니라고 본다.
그레이한 영역들의 예시는 이것이다. BE-FE간 API 협의 (어떤 값은 BE가 주고, 어떤 스펙은 FE가 직접 개발할지 등을 결정)를 시작해야하는데 이 논의 시작의 포문을 여는 작업. QA진행할 때 BE가 테스트 데이터 셋을 어느 범위까지 만들어줄 수 있고, 만들어줘야하는지를 정리하는 작업 등이다. 물론 개발, QA 멤버들이 오너십을 갖고 위 요건들을 정해서 진행할 수도 있다. 그러나 해당 아젠다들을 이슈잉하고, 이것이 과업임을 알게 해주는 역할은 PM이 시작하는 것이 맞다고 본다. 이러다보니, 이슈잉이 일찍이 되지 않은 아젠다가 시기를 조금 늦추어 발견됐을 때 그 책임 소재는 PM에게 돌아가기 쉽다. 모든 작업과제와 연결돼있는 유일한 사람은 PM이기 때문에, 프로젝트 진행 중 홀이 발견되면 책임에서 자유롭지 않은 주체는 PM이다.
내가 만들지 않은 대내/외 변수도 다뤄야하는 상황
위의 내용과 일맥상통하기도 하다. 이 프로젝트를 시작한 것은 PM 개인 사업이 아닌 회사의 의사결정에 따른 것이긴 하지만, 이 프로젝트를 총괄하는 주체인 PM이므로 대내적, 대외적인 변수로 인해 프로젝트 일정이나 서비스 스펙에 변경이 발생하게 되어도 프로젝트의 총괄인 PM이 100% 화살을 피하는 것은 어려울 수 있다. 물론 객관적으로 들여다보면 PM의 잘못이 0이라고 하여도, PM으로서의 책임에 부담이 실리는 것은 어쩔 수 없다.
일을 준 사람, 프로젝트를 책임지는 사람
PM은 회사로부터 리소스를 할당받아서 그 리소스를 활용해 내가 기획한 프로젝트를 완수하라는 오더를 받은 사람이다. 난 항상 1개의 프로젝트는 1개의 스타트업과 같다고 생각한다. 따라서 이 프로젝트의 사장이 PM이므로 요건을 정해주고 프로젝트를 운영하는 방식은 PM이 선호하는 방식으로 진행되게 마련이고, 모든 절차를 모든 멤버가 만족하는 것은 현실적으로 불가능에 가깝다.
그러나 PM에게 미움받는 상황만 있는 것은 아니다. 프로젝트 기간 내내 PM이 애써줌에 멤버들은 고마운 마음을 갖고 있고, 동분서주 불철주야 애쓰는 노력으로 프로젝트가 무사히 완료되면 그만큼의 성취감도 선물로 받을수 있다. 미움받는 것 같다고 느끼는 상황을 잘 견딜수 있게 해주는 것도 커리어적으로, 인간적으로 성장할 수 있는 요소가 되기도 한다.