[패스트캠퍼스 부트캠프 : PM 2기] Day 14

필수 1 강의가 끝났다.

감기는 끝나지 않는다 'ㅆ'

---

능력있는 PM

PM이 하면 안되는 4가지

 

요청사항을 애매하게 말하는 PM

-> 진짜 문제는 무엇인지 중요하고 우선순위가 중요하며 작업이 성공했는지 어떻게 알 수 있는지를 알아야한다

 

선 넘는 PM

-> 개발자 출신의 PM은 지금의 위치가 PM이므로 개발영역에 선을 넘지말자 지시를 내리는 사람이 아닌 제안을 하는 사람이다

 

일을 복잡하게 만드는 PM

-> 백로그가 정해진 상태에서 기능을 추가하는 PM

-> 릴리즈 하기 위해 구체적으로 무엇이 필요한지 알아봐야함

 

데드라인을 정하지 않는 PM

-> 이거 내일까지 가능하죠? 

 

엔지니어(개발자와 디자이너)가 신뢰하는 PM

1. 문제점/개선점//고객의 애로점만 설명하고 그 해결책/솔루션을 이야기 하지 않는 PM

2. 프로젝트의 초기 단계부터 엔지니어들을 프로세스에 포함시키는 PM

3. 엔지니어들이 경험하는 어려움에 적극적으로 공감을 표현하는 PM

4. 데이터 기반 결정과 투명한 커뮤니케이션을 하는 PM

5. 실수를 인정하는 PM

 

---

개발자에서 PM

개발자가 이미 갖고 있는 장점 5가지

 

테스크 주도형

시스템간 인터렉션에 익숙

해결 주도형

디테일에 강함

평생 배우고 익힘

 

개발자가 PM이 되기 위한 추가 덕목 5가지 

 

사용자, 고객 그들의 비즈니스를 이해

프로덕트를 함께 만드는 관계자들과 비전을 공유

유용성에 대한 끊임없는 탐구

생활밀착형 사고가 아닌 전략적 사고

업무 우선순위

 

---

오류

 

확증 편향

기존의 수많은 기능 중에서 사용자님이 원하는 특정 기능 X를 찾는 것은 얼마나 어려운가 

"사용자 님은 특정 기능 X를 찾는데 어려움이 있었나요? 있다면 그 이유는 무엇일까요?"

 

확증편향을 피해보려는 연습

1. 편향을 가지고 있다는 사실을 늘 인식하고 받아드림

2. 사용자리서치/서베이/피드백 질문 시 반드시 대답의 범위를 제한하는 유도 질문을 철저하게 제한

3. 여러 계층을 대표하는 고객/사용자/동료/관계자로부터 균형된 피드백을 받자. 확증편향은 수집데이터가 많으면 많을수록 약해지는 경향을 갖는다

4. 목표치 설정을 팀 리더들과 함께 셋팅을 하거나 PM이 직접 리더들에게 왜?에 대한 배경을 꼭 설명하고 의견을 구하자

5. 매 결정시 무엇이 아닌 이 결정이 필요했던 배경 왜?를 충분히 만족하는지 리뷰해야 한다

 

매몰비용 오류

본전 찾으려다 망함

 

매몰비용 오류를 피하는 방법

1. 만약 지금 이 제품/서비스에 팀원이 목숨을 걸어야 하는 상황이어도 이런 결정을 할 것인가?

2. 기존의 코드가 모두 날라가서 없어졌음에도 이런 방법으로 코드를 유지보수 할 것인가?

3. 내 동료가 진행하는 프로젝트임에도 내가 옳다고 해 줄 수 있는가?

 

이케아 효과

일반적으로 사람들은 본인이 직접 만든 제품에 대해서는 실제보다 더욱 큰 가치를 부여한다

 

이케아 효과 피하는 법

1. PM으로서 개발/디자인/지원 팀간 적절한 조율을 하고 있는지 항상 체크

2. 올바른 성과지표를 프로젝트 시작에 맞춰 준비하고 지속적으로 리뷰

3. 팀 전체가 팀 간의 우위를 경쟁하는 것이 아닌 제품/서비스를 성공시킨다는 공통의 목표를 꾸준히 자주 인식 시킨다

4. 우리 팀위 결과물을 다른 팀에 제공하고 크로스 레퍼런스를 적극 활용하고 타사의 경쟁 제품/서비스에 대한 분석을 본인의 고객/사용자의 관점에서 진행

 

오류 합의 편향

 

오류 합의  편향 피하는 방법

1. PM 본인의 목표를 항상 명확히 리뷰하고 팀멤버들과 함께 리뷰

2. 이 제품/서비스/기능은 고객/사용자에게 과연 합당한 것인가?

3. 고객/사용자에게 내 목표를 설명하고 그것이 맞는지 확인하는 절차를 갖는다

4. 제품/서비스가 만들어지는 과정에 다양한 사용자군과 프로덕트팀 간의 피드백 프로세스를 명확하게 디자인하여 서로 간의 생각의 오차를 줄인다