개발자가 말하는 같이 일하기 좋은 PM
좋은 PM이 되는 4가지 방법
배민 전 CTO의 개발자가 말하는 좋은 피엠영상을 보고 요약+생각+지인 개발자 피드백이 담긴 글입니다.
팀원 모두가 ‘나의 일’이라고 생각하게 만드는 PM이 좋은 PM같다.
PM이 먼저 프로덕트에 많이 고민한 상태이기에 ‘나의 일’ 즉, 주체의식을 가지고 있는 상태이다. 하지만 처음에 개발자는 기획을 리뷰받고, 수행하는 입장이기에 처음부터 ‘나의 일’이라고 생각하지 않는다.
좋은 PM은 팀원 모두 나의 일로 생각하게 만들더라.
그렇다면 개발자 입장에서 좋은 피엠은 무엇을 잘할까?
1. 좋은 PM들은 동기부여를 잘한다.
"고객 가치가 무엇인지/회사관점에서 어떤 가치가 있는지/데이터 기반으로 왜 해야 하는지? 잘 이야기 해준다."
이 내용은 당연한 이야기일지도 모른다. 나 또한 왜 이 서비스를 만들어야 하는지 납득된 상태여만 일을 진행할 수 있는 성향이기 때문에 팀원들도 같은 레벨로 왜? 에 대한 질문의 답변을 이해하기 위한 시간을 많이 같는다.
예를들어 1) 기획 리뷰 전에 서비스 진행하게 된 배경, 계기 등을 이야기한다. 통보가 아닌, 서로 궁금한 점이나 의견을 주고받으며 "논의"를 한다.
2) 가설을 공유하고 mvp의 결과 데이터를 데일리로 공유한다. 개발자분들이 다른 관점의 의 데이터 지표 궁금하다며 피드백을 주신다. 데이터로 답변을 공유한다.
3) UT 결과도 데일리로 공유한다.
모든 팀원들이 '이 서비스는 되는구나. 정말 고객이 가치를 느끼고 내가 만든 게 워킹하는구나!'를 인지할 수 있을 것이다. 서비스가 잘 된다는 가정이겠지만 말이다.
2. 좋은 PM은 피드백을 받을 수 있는 창구/ 사이클을 잘 만들어 낸다
- 기획 리뷰를 하는 게 개발자가 피드백을 해야 할 것 같은 환경을 만든다.
- 따라서 개발자는 기획에 참여하고 있다는 느낌을 받을 수 있다.
- 피드백을 더 적극적으로 받을 수 있는 팁!
“고민이 있어요…”라고 시작해 보라. 개발자는 문제 푸는 사람이기게 문제 해결하는 걸로 인정받고 싶어 한다.
다 정리해 둔 거 개발하는 거 재미없어한다.
초고수는 답을 아는데 굳이 물어보는 PM이다.
개발자랑 일정을 같이 논의한다.
프로젝 우선순위를 같이 설정한다. 피엠이 잡아 와야 하지만 굳이 같이 이야기한다.
3. 좋은 PM은 깊이 있게 정책 파악하고 있다.
- 도메인 지식/정책 잘 알아야 깊이 있는 서비스 개선을 할 수 있다.
- 단순 유아이는 크게 변화시킬 수 없다.
- 내 팀 서비스뿐만 아니라 엮여있는 서비스를 다 알아야 큰 문제점을 해결하고 변화를 줄 수 있다.
- 주니어는 본인 서비스만 안다.
결론: 훌륭한 PM은 모든 팀원이 ‘나의 일’이라고 주체의식을 가지게 하여 몰입하게 만든다.
-배민 기술이사 김영한-
+ 4. 좋은 PM은 개발에만 집중할 수 있는 환경을 만들어준다.
위에 내용을 같이 일했던 개발자에게 공유했다.
"OO님이 생각하는 좋은 PM은?" 질문을 하니, 개발에만 집중할 수 있는 환경을 만들어주는 PM이라고 했다.
시니어 개발자라면 동기부여를 할 필요 없을지도 모른다.
개발하는데 방해가 되지 않게 전문성을 발휘할 수 있는 환경을 만들어 주는 게 중요할 수 있다.
그렇게 하러면 정책 정리, 싱크가 맞지 않은 부분을 정확하게 질문하는 능력 즉 커뮤니케이션 능력이 뒷받침해야 한다고 생각한다.
당연히 갖추어야하는 기본 항목이라고 생각할 수 있지만, 실무 생각해보면 저 기본을 지키고 실행하기 쉽지 않다. 특히나 커뮤니케이션은 모든 것에 기본으로 요구되는 역량인데, 잘하기 참 어렵다.
커뮤니케이션을 잘하려면 도메인 지식 레벨도 높아야하고, 상대가 헷갈려하는 지점을 명확히 파악해야하며 글로도 명료하게 잘 전달할 수 있어야 하기 때문이다. 원래 하는 것보다 조금 더, 한다면 기본 역량을 성장시킬 수 있지 않을까 생각된다.
영상도 보고 글로 요약하면서 23년 하반기에 나는 어떤 PM이었는지 회고한 시간이었다.
그렇다면 PM이 생각하는 같이 일하고 싶은 개발자는?
다음 글에 계속..
참고:
https://youtu.be/WVvFRh1vGv8?feature=shared
