서비스 기획자, PM, PO는 왜 필요한가

챕터 02
- 인터넷 서비스의 역사와 기획자의 역할은?
- PM, PO, 서비스 기획자의 차이
- 서비스 기획자가 하는 일
- 목표를 잡고, 우선순위를 정하는 일

---

포털 서비스가 발전하면서 비즈니스와 개발팀도 발전하기 시작했는데, 이 둘은 서로의 영역과 언어가 다르기 때문에 충돌이 잦았음. 이에 따라 이들 중간에서 소통할 역할이 필요해 지면서 '기획자'를 뽑게 되었다.
* 기획자는 포털(다음, 네이버, 프리챌 등)의 성장과 함께 한국에서 만들어진 직무

>> IT 산업의 성장과 고도화 시기인 1990년대 ~ 2010년대엔 서비스 기획자의 탄생기이자 암흑기
>> 2009년 말, 아이폰과 안드로이드 스마트폰이 출시되면서 IT업계에도 큰 변화가 일어남.

 

 

[PM, PO, 서비스 기획자의 차이]

 

다른 회사들은
- 서비스 기획자
- PM
- PO
이 세 가지 직무를 어떻게 구분하고 있을까?

예시 1) 네이버 서비스 기획자
>> 담당 업무: User Scenario 발굴/개선. 지역별 요구사항 파악 후 우선순위 및 feature 정의

예시 2) 네이버 PM
>> 제페토(메타버스) 서비스의 문제를 정의하고 제품에 반영하는 역할, 어떤 상황에서도 프로덕트를 성공시킬 수 있는 의지와 역량이 있는 인재를 자격요건으로 둠

예시 3) 토스 PO
>> 제품을 주도하는 역할이며, 업무의 우선순위를 결정하는 사람. 

 

**결론: PM, PO, 서비스 기획자는 기업들이 각자 가지고 있는 서비스 형태나 성향에 따라 용어만 달라질 뿐 업무의 내용은 크게 다르지 않다!

---

[서비스 기획자가 하는 일]
　　　　서비스 기획자 = 영화감독 ?  (⊙_⊙)？
** 영화감독이 직접 연기를 하거나, 촬영을 하거나, 음악을 만들거나 하진 않지만 이 모든 일을 조율하는 사람이라면
** 서비스 기획자가 어떠한 의도를 가지고, 어떠한 목적을 달성하기 위해 어떻게 하고싶다 라는 내용을 디자이너 및 개발자 분들과 이야기하고 만들어가는 것과 비슷하다.

서비스 기획자는 서비스 발전을 위해
1) 서비스 목표를 정의하고
2) 이것을 프로젝트 구성원들과 우선순위를 잡아 어떻게 구현할지 고민하고,
3) 구현 후 이에 대한 피드백을 받는
이 1~3번 과정을 계속해서 반복하는 역할이다.

 

👉 고객에게 좋은 제품을 제공하기 위해 어떤 일들을 해야할까?
1) 문제인식(목표정의): 시스템 자체의 이유, 정부의 규제 등 외부 요인에 의해 만들어진 이유, 고객의 요구사항이거나 우리가 스스로 인식한 문제
2) 시장조사 & 벤치마킹: 사업계획, 전략계획 / 사용자 및 환경분석
3) 정책 결정 & 요구사항 정의: 정책서 및 요구사항 정의서
4) 서비스 기획: 기획서(스토리보드)
5) 커뮤니케이션 & 매니징: 칸반보드 회의록
6) QA: QA 시나리오 버그 리포트
7) 매뉴얼 & 가이드 작성: 매뉴얼
8) 서비스 운영(지표확인): 분석환경 설계 매뉴얼 / 지표 통계 리포트
9) 그로스 해킹: A/B 테스트 결과 리포트 

 

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

OKR에서 가장 중요한 것
>> 모든 조직 구성원이 하나의 큰 목표를 일치시켜서, '내가 하는 일은 모두 그 목표를 이루기 위해서다'라는 방향성과 목표를 공유

 

OKR의 특징
1) 전사적 목표 일치
2) 도전적 목표 설정
3) 투명한 목표 공유 

** 가장 중요한 것은 OKR로 인사평가를 하면 안 된다는 것. 그렇게 될 경우 목표를 낮게 잡게 될 수밖에 없다!

목표를 이루기 위해 우선순위를 정할 때 활용하는 대표적인 세 가지 방법론

1. RICE
- Reach: 도달범위, 특정기간에 해당 기능을 사용할 수 있는 사용자 수 
- Impact: 고객에게 줄 수 있는 영향력 (매우 큰, 적당히 높음 등)
- Confidence: 신뢰도 기획자가 생각하는 해당 기능에 자신감
- Effort: 개발, 기획, 디자인, 리소스

** (Reach+Impact+Confidence) / Effort

2. MoSCoW
- Must Have: 꼭 만들어야 하는 기능으로 법적, 보안적 이슈 및 서비스의 핵심을 위해 꼭 구현해야만 하는 기능
- Shoule Have: 우선순위는 높지만 이게 없어도 큰 문제는 아닌 기능
- Could Have: 있으면 좋은 기능
- Won't Have: 이번엔 만들지 않을 기능

 

 

 

---

 

 

 

---