😤 개발자가 말하는 좋은 PM 나쁜 PM

PM으로서 팀 멤버들의 적극적인 참여를 유도하기 위해서는 꼭 필요한 마법의 단어가 있다. 그건 바로 ‘고민이 있어요’라는 것이다. 프로젝트를 진행할 때는 개발자, 디자이너와 함께 개발하는데 이 두 직군은 문제 해결을 위해서 존재하는 직군이고 그렇게 교육받고 훈련받아왔기에 답정너처럼 요구사항 및 자세한 내용을 정해서 그냥 던지기보다 PM은 어느 정도 머릿속에 정리한 상태더라도 일단 고민이 있다면서 개발자와 디자이너의 의견을 들어보고 수렴하고 그렇게 작성된 문서를 공유해서 또 피드백을 받고 하면 모두가 함께 만들어가는 프로젝트가 되어 서로 오너십을 가질 수 있게 된다. 이것을 잘하기 위해서는 경험을 쌓아갈 수밖에 없다고 생각하는다. 경력이 낮을 때는 내가 제안하고 정리하는게 완벽해 보이고 그렇게 움직여주는게 좋아 보이는 적이 있어서 때로는 동료가 아닌 부하같은 느낌으로 일을 맡기는 경우가 있었다. 지금 생각하면 큰 실수였고 그렇게 진행된 프로젝트가 성공했을 리가 없다. 경력과 경험이 쌓이다 보니 함께 만들어가는 결과물이 얼마나 훌륭한지 알게 되었고 시야도 넓어져서 회사의 입장, 고객의 관점, 시스템에 대한 구조 등 이해가 깊어지면 깊어질수록 겸손해지고 협력의 힘을 믿게 되었던 것 같다. 아직도 모르는게 많은 PM이지만 성공적인 프로젝트를 하나둘 쌓아가는 맛에 PM을 계속해서 하는 것 같다. 📝 이하 영상 내용 메모 개발자가 생각하는 좋은 PM 나쁜 PM 1. 동기 유발하는 PM - 인간이 어떤 목표의 달성을 위해서 노력하게 하는 어떤 계기를 마련해 주는 것 - 개발자의 능력을 100퍼센트 끌어내기 위해서 필요. - 나쁜 PM - PM은 프로젝트 고민에 시간을 많이 써서 나의 일이 된 상황 → 개발자에 업무 요청 → 단순하게 요구사항 던진다. - 누구든지 단순히 시키는 업무를 나의 일로 받아들이기는 쉽지 않다. - 기획자는 업무를 준비하면서 자연스럽게 나의 일이 된다. - 좋은 PM - 업무 고민 → 나의 일이 됨 → 개발자에게 그냥 이걸 해요! 가 아니고 이걸 왜 해야 되는지 집요하게 설명한다. - 데이터 및 고객 관점, 회사의 가치 관점에서 잘 설명해준다. - 피드백을 받을 수 있는 창구를 마련해둔다. - 개발자도 나의 일로 인지하고 결국 우리의 일로 된다. - 완전 좋은 PM - 우리는 이런 문제가 있다고 먼저 이야기한다. 이 문제를 해결하면 사용자의 5%가 증가하고, 비즈니스 가치가 증가한다. (문제→해결 포인트로 접근) 2. 정책을 깊이있게 이해하는 PM - 나쁜 PM - 레거시라 잘 모르겠어요, 코드보면 안되나요? - UI 화면 기반의 기획서 만들고 끝 - 좋은 PM - 본인 도메인에 대해서 물으면 줄줄줄 설명 - 업무 프로세스, 데이터 흐름 등등 모든것을 정리 - 본인이 온전하게 서비스 정책을 깊이있게 이해하고 있어야만 깊이 있는 서비스 개선이 가능 - 회사가 커질 수록 나머지 전체에 대해서도 얇고 넓게 이해 3.대충이라도 개발적인 시스템을 이해하는 PM - 나쁜 PM - 개발자가 알아서 - 좋은 PM - 전체조직과 R&R, 큰 시스템 관점에서 프로세스와 데이터 흐름을 이해한다. - 각 시스템들이 어떤 역할을 담당하는지 네모 박스를 그려서 이해만 해도 된다. - 개발자의 도움을 받아서 이런 지도를 완성한다. PM이 개발자를 움직이는 마법의 단어 “고민이 있어요” 고민이 있어요 = 문제+인정+겸손