하루일문

[Chapter 02] 서비스 기획자, PM, PO는 왜 필요한가? 본문

pm/TIL

[Chapter 02] 서비스 기획자, PM, PO는 왜 필요한가?

support_u 2023. 9. 5. 19:04

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

한국에서 웹 서비스의 변화

  게시판 시대
(~1990)
포탈 시대
(~2010)
모바일 시대
(~2020)
포스트 코로나 시대
(~현재)
등장 배경 IT 산업의 등장 IT 산업의 고도화 스타트업 등장
Warerfall의 실패
스타트업 성장
Agile 한계
개발 방법론 - Waterfall Agile & Scrum 비즈니스 및 의사결정 - Waterfall
개발 - Agile
기획자 R&R All in one A - Z 프로덕트 매니징 Mini CEO 의사결정
기획자 명칭 Web master 서비스 기획자 PM PO
대표 산출물 - 스토리 보드 칸반보트, 회의록, UI 목업 데이터 분석 결과, 정책서, PRD
주 역량 - 스토리 보드(UX, UI) 매니지먼트 데이터분석

 


2️⃣ PM, PO, 서비스 기획자의 차이

더보기

1. 서비스 기획자 : 유저 시나리오 발굴, 기능 정의 및 개선, 서비스의 상세 설계 작성, 와이어프레임 작성, 이해관계자 커뮤니케이션

2. PM : 문제를 정의하고 문제를 반영하여 성공시킬 수 있는 역략

3. PO : 제품을 주도하고 업무의 우선순위를 결정하고 제품 주도와 제품 고도화

 


3️⃣ 서비스 기획자가 하는일

.IT 기술을 통해서 사용자의 문제를 해결하는 일

서비스의 발전을 위해 서비스 목표를 정의 → 팀원들과 우선순위 정함  어떻게 구현할지 고민하여 고민 피드백을 받고 다른 목표를 세움를 반복

 

🔹 문제 인식(목표 정의) 및 우선 사항 정리

🔹 시장 조사 & 벤치마킹 : 사업계획(신사업, 확장의 경우) & 전략기획(인프라 개선의 경우), 사용자 및 환경 분석

🔹  정책 결정 요구사항 정의 : 정책의 이슈   정책서, 사용자의 입장 & 현재 보유 리소스 & 시스탬적 이슈를 고려    요구사항 정의서

🔹 서비스 기획 : 와이어프레임을 포함한 스토리보드 작업(정책, 기능적 포함)

🔹 커뮤니케이션 & 매니징 : 개발자 디자이너와 현재 상황 보고 및 요구사항 수정을 위해 칸반보드 회의록

🔹 QA : 시나리오 버그리포트

🔹 메뉴얼 & 가이드 작성 

🔹 서비스 운영(지표 확인) : 분석 환경 설계 메뉴얼, 지표 통쳬 리포트

🔹 그로스 해킹 : A/B 테스트 결과 리포트를 보고 목표가 맞았는지 보고 발전

 

 ➕ 체계를 없다면 반복되는 작업을 위키에 저장하여 새로운 사람이 와도 적용을 쉽게하기 위해 작성하는 것도 좋은 자세

 


4️⃣ OKR(Objective:목표, Key:성과, Result:지표) 대한 이해

 

OKR KPI
개인, 팀 및 모든 조직과 자유롭게 연결된 전략
모든 구성원이 공감할 수 있는 목표가 중요
개인, 팀 간의 상하위로 일치된 전략
회사의 목표를 달성하기 위해 무엇이 중요한지 모두에게 알림 전체 전략을 각 부서의 운영 활동 및 접근방법을 모색
나타난 결과치 보다 결과의 이유에 집중 나타난 결과치에 보다 집중
공격적인 목표치를 설정 달성가능한 목표치 설정
역할에 맟게 명확한 커뮤니케이션을 할 수 있는 프레임워크 조직 성과와 연계
상향식 + 하향힉 리더십 주도 & 하향식
성장 지향 성과관리 중점

 ➕ 인사 평가는 OKR로 하면 안됨(너무 도전적인 목표기 때문)

 

🔹 OKR 방법론

🅰 R.I.C.E

적은 리소스로 많은 영향력을 줄 수 있는 서비스를 우선 개발

Reach : 도달 범위, 특정 기간에 해당 기능을 사용할 이용자 수
Impact : 고객에게 줄 수 있는 영향력
Confidence : 신뢰도 기확자가 생각하는 기능에대한 자신감
Effort : 개발, 기획, 디자인 리소스

Reach + Impact + Confidence / Effort

 

 

🅱 MoSCoW

보안적 이슈가 더 탄탄한 방법론

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