성공하는 프로젝트에는 항상 좋은 PM이 있었습니다.
그리고, 계속 다니고 싶은 회사에도 좋은 PM이 있었습니다.
1. 동기유발
•
인간이 어떤 목표의 달성을 위해 노력하게 하는 어떤 계기를 마련 해 주는 것
→ PM이 어느정도 해 주어야 함
•
why? PM은 개발에게 업무를 요청하는 일을 많이 함
→ 개발자의 능력을 100% 끌어내는 것이 PM의 중요한 역량
•
(나쁜 PM의 예시)
1.
PM이 업무를 시작함 > 업무 고민을 엄청 함
2.
자연스럽게 '나의 일'이 됨 > 내가 고민을 하고 시간을 썼기 때문에
3.
내가 잘 정리하고 개발자에게 툭 던지게 됨
4.
개발자 입장에서는 PM이 단순하게 시키는 일이 되어버림
5.
누군가 다 정리해주기 때문에 개발자 입장에서는 재미 없음
•
(좋은 PM의 예시)
1.
고민을 하고 '나의 일'이 되는 과정까지는 똑같음
2.
"이걸 왜 해야하는지" 정말 **집요하게** 설명함
3.
데이터 + 고객관점 + 회사의 가치 관점에서 설명함
4.
개발자가 충분히 납득할 수 있도록
5.
그리고, 피드백을 받을 수 있는 창구를 열어놓음
6.
개발자가 왠지... 피드백을 해 줘야할 것만 같은 느낌을 잘 만들어냄
→ 피드백 사이클을 잘 만들어 냄
7.
결과적으로, 여기 프로젝트에 참여하는 모든 사람들이 이것을 우리의 일로 만드는 PM이 진짜 훌륭한 PM
8.
기획자는 스스로 업무를 준비하면서 자연스럽게 '나의 일'이 되는데, 일을 받아서 하는 입장은 (개발자) 나의 업무로 받아들이기 쉽지 않음
→ 개발자는, 문제라는 이야기를 듣는 순간 내가 왠지 풀어야 될 것 같은 사람으로 만들어 졌다고 함 (ㅋㅋㅋ)
→ 따라서, 문제를 해결하는 포인트로 개발자에게 접근하는 것이 좋음.
→ 좋은 개발자도, 기획서에서 조금만 방향을 틀면 리소스를 확 줄일 수 있음을 캐치할 수 있음
→ 이런 피드백들을 하면, 개발자 입장에서 의견을 많이 내는 것 > 개발자도 '나의 일'이 됨
→ 인간적인 유대 = 개발자와 기획자간의 상호 커뮤니케이션 벽이 낮아짐
→ 결과적으로, 개발자가 더욱 쉽게 피드백을 줄 수 있는 찬스가 늘어나게 됨
개발자를 움직이는 마법의 단어?
이게 다 좋은 PM을 만나야 가능한 일 ...
2. 깊이있는 정책 이해
•
개발자가 느끼는 좋은 PM = 정책을 잘 이해하는 PM
•
(나쁜 PM의 예시)
1.
레거시라 잘 모르겠어요.. 코드 보면 안되나요? -> 직무유기, 개발자가 코드 안짜는 것과 비슷
2.
UI 화면 기반의 기획서만 만들고 끝
•
(좋은 PM의 예시)
1. 본인 도메인 버튼 누르면 줄줄줄 설명 -> 서비스에 대한 애정과 본인 프로덕트임을 느낄 수 있음
2. 업무 프로세스, 데이터 흐름 등등 모든 것을 정리
3. 본인이 온전히 서비스 정책을 이해하고 있어야 깊이있는 서비스 개선도 가능
->그렇지 않으면 고치더라도 어떤 문제가 생길지 알지 못함
4. UI만 만지면 큰 변화를 만들지 못한다. (디자이너의 생각과는 다를 수 있음!!)
5. (깊이) 본인이 담당하는 업무 도메인은 매우 깊이 있게 이해
6. (넓이) 회사가 커질수록, 나머지 전체에 대해서도 얇고 넓게 이해
