좋은 PM은?!
1.동기유발
인간이 어떤 목표의 달성을 위해 노력하게 하는 계기를 마련해주는 것
pm은 개발에게 업무 요청하는 일이 많다. 개발자의 능력을 100% 끌어내는 역량이 있어야 한다.
나쁜PM) pm이 먼저 본인의 업무를 시작함. 업무 고민을 엄청 함. 그럼 잘 정리하고 개발자에게 던져준다.
그럼 개발자 입장에서 pm이 단순하게 시키는 일이 된다. 재미없고. (내가 개발자로 일 했을 때 이런 느낌을 많이 받았다. 시키는 것만 해라! 라는...)
OWN 나의 일
OWN : 내 마음을 쓰는 진짜 나의 일
어떤 일을 더 많이 신경쓰고 고민할 때 더욱 OWN
기획자는 스스로 업무를 준비하면서 OWN
누구든지 단순히 시키는 업무를 나의 일로 받아들이기는 쉽지 않다. (개발자도 마찬가지다)
-기획자 뿐만 아니라, 개발자도 나의 일로 만들어야 함
-그러면 어떻게? 개발자가 적극적으로 개입하게 상황을 만들어야 함.
-WHY, 피드백, 개선점, 질문하기 등등
-기획자가 보기에 기술적으로 어려워 보여도 기획을 조금만 틀면 더 적은 개발 리소스로 더 효과적인 것을 만들 수 있음. 좋은 개발자는 이런것을 잘 안다.
-개발자가 더 많이 개입할 수록, 개발자 본인의 일이 됨. 내가 의견을 내고 개선할 수 있다는 느낌이 중요함.
좋은PM) 그냥 이걸 하세요. 가 아니라 이걸 왜 해야하는지 정말 집요하게 설명을 한다.
데이터와 고객 관점과 회사의 가치라는 관점에서 설명을 잘 해준다. 개발자가 납득할 수 있도록.
이 프로젝트를 하면 고객 가치가 높아지고, 등등 설명을 잘 해준다. 특히 데이터 기반으로 이야기하면 효과적.
피드백을 받을 수 있는 창구를 열어놓는다. 피드백 사이클을 잘 만들어냄.
=> 기획서만 리뷰하고 기획서 설명을 하는데 굳이 개발자가 왠지 피드백을 해줘야할 것 같은 느낌을 주는 피엠이 있다.
=> 개발자로 하여금 왠지 내가 이 기획에 참여하고 있는거 같은데? (피드백 사이클을 잘 만들어 냄)
=> 개발자는 내가 이 프로젝트에 참여할 수 있는거 같은 느낌을 받음.
어느 순간 떠올려보면 내가 이 프로젝트에 진짜 참여하고 있구나. 라는 느낌을 받고,
이 일이 기획자에게 뿐만 아니라 우리 모두의 일로 만드는 것이 진짜 훌륭한 PM
why? 우리 이거 왜 하는데?
나쁜PM) 위에서 시켜서 해야 돼요. 다음주 까지 실장님이 하래요. 설명도 없이 이러고 오는 피엠이 있다. 최악.
좋은PM) 이 기능을 개발하면 사용자가 5% 증가하고 우리 비즈니스 가치가 이렇게 증가한다.
더 좋은 PM) 우리는 이런이런 문제가 있다. 이 문제를 해결하면 사용자의 5%가 증가하고, 우리 비즈니스 가치가 증가한다.
(문제 -> 해결 포인트로 접근) *개발자 특징 : '문제' 라는 말을 들으면 왠지 내가 풀어야 될 것 같은 느낌을 받음ㅋㅋ
인간적인 유대
-이것은 삶의 기본
-너를 믿는다. 서로 신뢰가 있어야 함.
-이런 인간적인 유대가 중요한 이유?
-> 상호 커뮤니케이션 장벽이 낮아짐
-> 개발자 스스로 더 쉽게 피드백, 이야기 함
-> 스스로 더 많이 참여하게 됨
-> 개발자가 업무를 OWN 할 가능성이 높아짐
프로그래머 == 문제 해결사
<프로그래머의 뇌 구조>
-문제는 풀어야 한다.
-인정 받고 싶다.
개발자를 움직이는 마법의 단어
"고민이 있어요"
단순해보이지만 개발자를 미묘하게 만드는 마법의 단어ㅋㅋㅋㅋ
고민이 있다(문제가 있다) --- 문제 + 당신을 인정함 ---> 프로그래머의 뇌 (문제는 풀어야 한다 / 인정 받고 싶다)
<프로젝트 우선순위>
나쁜PM)
-우선순위를 혼자 결정한다
-대안을 혼자 정해서 가져옴. 답정너. -> 개발자 입장에서 일이 재미가 없다.
좋은PM)
-개발자가 참여하게 한다. (사실 피엠이 일정을 다 잡아서 오는게 맞음. 하지만, 굳이 개발자가 참여하는 느낌을 만들어줘야 된다.)
-우리가 다 같이 이 일을 만들어간다는 느낌을 만든다.
느낌, 느낌!! 느낌을 주는 것이 중요하다. 그런 느~낌!
2.깊이있는 정책 이해
<서비스 정책 이해>
나쁜PM)
- UI 화면 기반의 기획서만 만들고 끝
- 레거시라 잘 모르겠어요, 코드 보면 안되나요?
좋은PM)
-프로덕트라는 것은 중량이 더 많다. 화면 UI에 보이는 것보다 그 기저에 훨씬 더 중요한 것들이 많다. 정책의 얼개 등..
-좋은 PM은 본인이 담당하고 있는 도메인은 매우 깊이있게 이해. 도메인 관련하여 물어보면 막힘없이 줄줄 나와야 함.
-업무 프로세스와 주요한 데이터 흐름에 대해서는 본이이 다 정리해서 머릿속에 가지고 있다.
-정책에 대해 깊이 있게 이해를 하고 있어야 깊이 있는 서비스 개선이 가능하다.
-회사가 커질수록 나머지 전체에 대해서도 얇고 넓게 이해하고 있어야 한다.
회사가 작을 때는 상관없지만 회사 규모가 커지면 기능을 하나씩 다 분리하게 된다.
화면과 관련 된 업무를 할 때 뭔가 바꾸고 싶어서 이런 데이터가 추가로 필요하고, 사장님한테 이런 데이터를 추가로 받아야 하겠는데? 그럼 어떤 시스템에서 데이터가 흘러 들어오고 이런걸 알아야 함. 이 시스템 저 시스템 등.
예시) 배민의 경우는 사장님이 가게 등록과 메뉴 등록도 해야되는데 그런다고 가게가 노출되지 않는다.
여기에 광고까지 등록 해줘야 가게가 노출이 되는 것. 이 3박자가 맞아야 하고 이 툴이 다 따로 있다.
기획자들은 이 툴을 다 써보면서 상품을 등록해보고 어떻게 가게가 노출 되는지 과정을 경험해봐야 함.
비록 나의 팀의 것은 아니지만 전체적으로 대략적인 얼개를 알고 있어야 큰 변화가 가능하다.
주니어 피엠들은 이런것들을 잘 못함. 내가 맡은 거만 보기 때문. 시야가 넓어야 좋은 기획을 할 수 있다.
-3.대충이라도 개발 시스템을 이해하고 있는 PM
<개발을 어디까지 알아야 하나?>
나쁜PM)
-개발자가 알아서
좋은PM)
-전체 조직과 R&R, 큰 시스템 관점에서 프로세스와 데이터 흐름을 이해한다.
-그냥 네모 박스를 그리고 각 시스템들이 어떤 역할을 담당하는지 이해하자
-> 개발 이해X
-> 업무 프로세스와 데이터가 시스템(네모 박스)드로가 어떻게 엮여서 돌아가는지 이해 필요.
-개발자의 도움을 받아서 이런 지도를 완성한다. (여기서 말하는 이런지도란 플로우 차트인가?)
오늘의 느낀 점
좋은 PM은 설명을 잘 하는게 아니라, 설득을 잘 한다.
설명하려고 하지 말고, 논리적으로 데이터에 기반하여 설득을 하자!
'PM > doc' 카테고리의 다른 글
| [아티클 스터디] 토스에서 요즘 '애자일'하는 방법(feat. EoA) (0) | 2023.09.01 |
|---|---|
| 프로토타입과 PMF (0) | 2023.09.01 |
| [우아한 형제들] PO미신, 파랑새를 찾아서 (0) | 2023.08.31 |
| 기업에서 원하는 PM/PO/서비스 기획자는?! (0) | 2023.08.31 |
| UI UX (0) | 2022.07.12 |
댓글