오늘부터 프로덕트 매니저_Prod. 개점휴업
Product Manager?
O 프로덕트 매니저는 무엇을 만들까? 라고 자문 하는 사람이다.
또한, 회사 내부의 요구사항과 < 사용자의 요구사항을 조율
할 수 있어야 한다. (데이터 분석능력 요구)
◾ 요구사항의 이상적인 모습
- 명확한 문제 정의
- 이에 대한 대략의 해결방법
- 이를 통한 창출 (기대효과)
Product Manager의 중요한 능력
O 백로그의 우선사항을 정해 이번 스프린트에 작업할 대상을
선정할 수 있어야 한다.
◾ 우선사항을 정의하는 법 (ICE 프레임워크)
- 영향력 (Impact)
- 성공가능성 (Confidence)
- 배포시간 (Ease)
3개의 요소를 다 따져서 우선사항을 정하자.
어떻게 만들까
O 기획서를 작성하자(작성하는 이유)
- 팀원들간의 합의 & 의견에 동의를 얻을 수 있다.
- 오류나 문제가 생기면 생긴 단계로 바로 이동할 수 있다.
- 문맥의 파악이나, 누구나 이해할 수 있다(있어야 한다.)
- 제목 - 제품의 이름 / 개요를 담아 작성
- 목차 - 간결, 명확하게 구성
- 변경이력 - 팀원 모두가 빠르게 확인 가능
- 참고자료 - 모든 지식을 다 담기보단, 참고자료 위주
- 요약 - 두괄식으로 작성
- 업무요청 체크 리스트 - ex) "언제까지 처리 해주세요"
- 배경 / 현황 - 상세한 설명 필요 (이 과업이 왜 필요한지)
- 목표 / 목적 - 매출이 얼마나 상승, 방문 횟수는 얼마나 상승?
- 정책 - 전체적인 컨셉을 정의
- 화면 기획안 - 정책이 정의한 바가 화면에 반영(구체적)
- 통계지표 - 내외부 집계
책에서 설명하는 작성 방식은 위와 같다. 여기서
빼고, 더하며 나만의 기획서를 작성해보는 게 좋은
경험이 될 거 같다.
애자일(Agile), 워터폴(Water Fall)
애자일: 서비스 기획자, 개발자가 동시에 문제 해결한다.
장점: 배포횟수를 늘린다.
단점: 기능 구현이 부자연스럽다.
워터폴: 기획자가 요건을 정리, 정의 후에 개발자가 개발한다.
장점: 정확도를 높인다.
단점: 쓸데없는 시간낭비를 할 수 있다.
만드는 단계
A
기획자, 프로덕트 매니저
B
개발자, 프로덕트 디자이너
O 만드는 단계는 A와 B의 의견을 조율하고 결정하는 단계다.
◾ 주의할 점
- B에게 말을 할 때는, '~해서 ~이러면 좋을 거 같다' 와 같이 말하는 걸 삼가해야 한다. 디자인과 개발은 전문가의 영역이다.
- 모르는 부분은 모른다고 말할 수 있어야 한다. A는 스프린트를 이끌어 가야한다. 모든 과정, 지식을 다 아는 건 중요하지 않다. 문제의 원인, 해결방안, 소요시간 이 3개의 요소가 제일 중요하다.
Test Case 작성
O 버릴 수 있는 건 버리는 게 중요하다.
ㄴ 목적은 제품을 완성시키는 거다.
◾ Test Case - 제대로 작동하는가?
- Yes -> 배포
- No -> P.M : 잘못 작동한 이유(명시)
-> Dev : 수정
물론 잘 되지 않을 수 있다.
한번의 성공 < 꾸준한 지표를 얻도록 하자.
이상적인 계획서
- 내용구분이 명확하다.
- 다른 사람들도 편집할 수 있을 만큼 접근성이 좋다.
- 설득력이 있어야 한다.
- 데이터 검증을 통한 논리적인 연결로 시간을 효율적 관리
- 완벽주의 문서 < 제품에 대해 초점
일의 단순화 & 우선순위
'A' 에 집중 해야 한다. 백로그, 분석력, 관리
Product Manager Keyword
문제해결은 어렵다.
달성하는 것이 매우 쉽거나, 너무 어렵다면
현재 목표설정이 잘못됐을 가능성이 크다.
마치며
처음 직무를 시작하는 사람들에게
참고 할 수 있는 지침서 같다.
무겁지도, 가볍지도 않은 내용으로 술술 읽혔다.
