[제로베이스 pm스쿨] 매일학습일지 Week 1-2

✍🏻 오늘의 할 일 

- 케이스 스터디 1개 

- 챕터 2. 강의 듣기

- 매일학습일지

- 1주차 블로그 미션

---

오늘의 강의는 "서비스 기획자, PM, PO는 왜 필요한가"의 주제였다.

 

✔️ 인터넷 서비스의 역사와 기획자의 역할
✔️ PM, PO 서비스 기획자의 차이
✔️ 서비스 기획자가 하는 일
✔️ OKR에 대한 이해
✔️ 우선순위 정하는 법

---

인터넷 서비스의 역사와 기획자의 역할

우리나라의 경우 IT시장이 1990년대 ~ 2010년대 사이 IT산업의 성장과 고도화로 급성장하였다. 

초기의 대표 IT 회사는 포털 회사로 이루어져 있고, 대부분의 개발 방식은 Waterfall 방법론으로 개발되었다.

 

2009년 이후 다양한 스타트업이 등장하면서 Product Manager의 개념이 등장하고, Agile 개발방법론으로 개발되기 시작하였다. 

 

2020년대가 되면서 스타트업의 성장과 Agile의 한계가 보이기 시작했다. 

그 때, 국내 쿠팡에서 처음으로 Product Owner라는 직무가 등장했다. 

 

Product Owner란

큰 앱을 각각의 단위로 쪼개서 프로덕트 오너라는 사람이 해당 프로덕트에 대한 권한과 책임을 위임받아서 그 프로덕트 오너가 해당제품에 대한 비즈니스와 개발방향성을 결정하면서 운영을 한다. 

 

ex) 프론트 서비스 담당 PO - 고객 데이터 분석, UX/UI 강점

ex) 백엔드 서비스 담당 PO - 제품 정책을 정하고, 해당 제품에 대한 PRD 작성

 

채용공고 살펴보기

1. 서비스 기획자

기획자 업무 - 유저 시나리오 발굴, 상세설계, 와이어프레임, 협업 부서와의 커뮤니케이션 

 

2. PM

PM 업무 - 문제 정의와 그 문제를 제품에 반영한다. 어떤 상황에서도 프로덕트를 성공시킬 수 있는 의지와 역량

"어떻게든 제품을 성공시키게 하는 것이 중요하다."

 

3. PO

PO업무 - 제품 주도하는 역할, 업무의 우선순위 결정, 끊임없는 Iteration을 통해서 PMF를 찾고, 제품을 고도화

-> 제품 주도와 업무의 우선순위 결정, 외/내부의 다양한 요구사항을 잘 정리해서 우리 제품을 어떻게 발전시킬까 고민

장기적인 형태를 고민하고, 목표를 위해 지금 가장 중요한 일이 무엇을 하는지 논의한다.

 

서비스 기획자가 하는 일

 

문제 인식(목표 정의)

- 우리 제품에 대한 정의

- 우선 순위를 정하는 것이 중요하다.

 

시장조사 & 벤치마킹

- 배경조사

- 사용자 인터뷰

 

정책 결정 요구사항 정의

- 법적요건

-사용자, 사내 리소스, 시스템 고려

 

서비스 기획

-와이어프레임, 프로토타입, 스토리보드

 

커뮤니케이션 & 매니징

- 데일리 스크럼(매일 아침 진행과정 공유하는 과정)

 

QA

- 대부 환경에서의 테스트: 테스트를 기획자도 같이 한다.

- QA 환경에서의 테스트: 기획자가 해당정책에 맞는 테스트 케이스는 QA팀에 전달

- 큰 규모 기능 업데이트 or 시스템 인프라가 바뀌는 업데이트라면 모든 팀이 달라붙어서 QA를 하게 된다.

 

매뉴얼 & 가이드 작성

- 배포시 사내 관련부서 공지

- 사용자 팝업 공지

 

OKR에 대한 이해

OKR(Objective, Key Result): 목표, 성과 지표

1. 전사적 목표 일치

2. 도전적 목표 설정

3. 투명한 목표 공유

 

인사평가를 OKR로 하면 안됨! 그러면 모두가 목표를 낮게 잡기 때문!

 

우선순위 정하는 법

OKR로 목표성과지표를 잡았으면 그 목표를 이루기 위해 우선순위를 잡는 일도 기획자가 하는 일이다.

Reach: 도달 범위, 특정 기간에 해당 기능을 사용할 수 있는 사용자 수

Impact: 고객에게 줄 수 있는 영향력(매우 큰, 적당히 높음 등)

Confidence: 신뢰도 기획자가 생각하는 해당 기능에 자신감

Effort: 개발, 기획, 디자인 리소스

 

Must Have: 꼭 만들어야 하는 기능으로 법적, 보안적 이슈 및 서비스의 핵심을 위해서 꼭 구현해야 하는 기능

Should have: 우선순위는 높지만, 이것이 없어도 큰 문제는 아닌 기능

Could have: 있으면 좋은 기능

Won't have: 이번에는 만들지 않을 기능

 

---

케이스 스터디는 아직 초창기라 시간이 많이 소요되는 것 같다🥲

서비스 조사하고, 화면캡쳐하고, 정리하고, 생각 정리하고 무한 반복의 굴레

익숙해지면 속도가 더 붙겠지..!라는 생각으로 버텨야겠다.

 

오늘의 강의는 업무별 개념과 하는 일을 배웠는데 멘토님이 자신의 경험을 예시로 설명해주셔서 이해하기 쉬웠다.

 

이제 블로그 미션하러 갑니다~