성공하는 프로젝트에는 항상 좋은 PM/PO
성공하는 프로젝트에는 좋은 PM이 있었습니다. 그리고 계속 다니고 싶은 회사에도 좋은 PM이 있었습니다.
개발자가 생각하는 좋은 PM이란? 어떤 특징을 가지고 있을까요? 크게 동기유발, 서비스의 정책, 개발 지식의 흐름 3가지가 있습니다.
큰 3가지의 틀을 듣다보니, PM은 기획이라는 일을 하지만, 결국 사람과의 소통이 정말 중요함을 깨닫게 됐었습니다.
기획한 프로젝트를 만들어줄 수 있는 개발자와 디자이너와 어떻게 소통하고 협업하는지에 따라 성공하는 프로덕트의 결과값이 달라질 것입니다.
이번 글에서는 개발자와의 커뮤니케이션을 어떻게 해야하는지 대략적으로 정리해 보았습니다.
Part 1 | 동기유발
1. 동기
👍 좋은 PM
- 인간이 어떤 목표의 달성을 위해 노력하게 하는 계기를 마련해 주는 것
- 개발자의 역량을 100% 끌어내 줄 수 있는
- 왜 해야하는지 집요하게 설명하는
- 데이터, 고객관점, 회사의 가치 관점에서 설명하는
- 피드백 사이클을 잘 만들어내는
- 개발자도 프로젝트 기획에 참여하는 거 같은 느낌을 주는
- 현재의 문제를 해결 하는 포인트를 주는
👎나쁜 PM
- 단순하게 시키는 일, 받는 입장에서 개발자 입장에서 재미가 없음
나의 일 OWN
- 내 마음을 쓰는 일
- 어떤 일을 더 많이 신경쓰고 고민할 때 더욱 own
- 기획자는 스스로 업무를 준비하면서 own
- 누구든지 단순히 시키는 업무를 나의 일로 받아들이기는 쉽지 않다.
2. 인간적인 유대
👍 좋은 PM
- 신뢰
- 상호 커뮤니케이션의 벽이 낮아짐
- 개발자 스스로 더 쉽게 피드백을 얘기함
- 개발자 스스로 참여를 많이 하게 됨
- 개발자가 업무를 own할 가능성이 높아짐
3. 고민이 있어요, 고민이 있습니다.
👍 좋은 PM
- 고민이 있어요 (문제가 있다) 는 문제점과 인정의 2가지 핵심 요소를 개발자에게 전달 하는 것.
- 프로그래머는 문제를 풀어야하고, 인정을 받고 싶어 한다.
- Solving the problem
- 프로그래머 = 문제 해결사
4. 일정 관리
👍 좋은 PM
- 개발자가 참여하게 한다.
- 우리가 다 같이 이 일을 만들어간다는 느낌을 만든다.
👎 나쁜 PM
- 우선순위를 혼자 결정한다
5. 고수는 이미 답을 알고 있어도 물어본다.
- 이미 대안과 일정이 정리되어 있지만, 개발자에게 굳이 물어본다.
Part 2 | 깊이있는 정책의 이해
1. 정책
👍 좋은 PM
- 깊이있는 담당 도메인에 대한 이해
- 업무 프로세스, 주요 데이터에 흐름의 정리
- 완벽한 서비스 정책의 이해가 있어야 서비스 개선이 가능하다
- 회사의 규모가 커지면 시야를 넓게 볼 수 있어야 큰 일을 해결 가능하다
👎 나쁜 PM
- 레거시라 잘 모르겠어요, 코드보면 안되나요?
- UI 화면 기반의 기획서만 만들고 끝
part 3 | 개발
👍좋은 PM
- 전체 조직과 R&R, 큰 시스템 관점에서 프로세스와 데이터 흐름을 이해한다.
- 그냥 네모 박스를 그리고 각 시스템들이 어떤 역할을 담당하는지 이해하자
- 업무 프로세스와 데이터가 시스넴과 어떻게 엮어서 돌아가는지 이해
- 개발자의 도움을 받아서 큰 지도를 완성한다
👎 나쁜 PM
- 개발자가 알아서