[독서 기록📚] 오늘부터 프로덕트 매니저(1): 스프린트와 프로덕트 매니저의 역할

01 스프린트와 프로덕트 매니저의 역할 

- 스프린트: 스프린트(Sprint)는 제품을 만드는 만듦에 있어 주기를 지칭한다. 배포가 기점이 되기 때문에 대개 스프린트의 시작은 이전 배포 직후이며 스프린트의 종료는 이번 배포와 배포 이후의 모니터링까지이다. 비유를 하자면 학사 일정에서의 학기가 스프린트가 되는 셈이다. 

- 프로젝트, 마일스톤: 작업의 규모가 커서 여러 스프린트에 거쳐 작업해야 하는 경우, 별도 프로젝트(Project) 또는 마일스톤(Milestone)으로 구분하는 것이 일반적이다. 이 두 명칭 모두 일의 단위라고 이해하면 쉽다.

---

무엇을 만들까?

1. 제품에 대한 요구사항을 수집하고 정의한다 

 그래서 프로덕트 매니저는 수많은 요구사항 중 제품 또는 조직의 목표를 가장 효율적으로 달성할 수 있는 요구사항을 선별함으로써 ‘무엇을 만들까’라는 질문에 답한다.

2. 백로그의 우선순위를 파악하여 이번 스프린트에 작업할 기능을 정한다 

프로덕트 매니저의 가장 중요한 역할은 백로그에 있는 요구사항의 우선순위를 결정하여 이번 스프린트에 작업할 대상을 선정하는 일이다.

⚠️한 가지 기억할 점은 제품이 가지고 있는 모든 문제를 새로운 기능을 구현하여 해결할 필요는 없다는 점이다. 상대적으로 비용이 비싼 기능 구현이라는 방식 이외에 다른 방식을 찾을 수 있다면 그것이 최고의 해법이라고 생각한다. 

(ex. 스타트업 채용공고 : 노션에 업로드) 

 

작업 대상 선정시 사용할 프레임워크: ICE 프레임워크 

* Impact: 얼마나 큰 영향력 

* Confidence: 성공할 것이라는 확신

* Ease: 배포하기 위해 소요되는 시간

---

어떻게 만들까?

1. 담당자 협의를 통하여 구체적으로 어떻게 만들지를 결정한다 (기획서) 

- 제목 

- 목차

- 히스토리(변경 이력)

- 참고자료

- 요약

- 업무요청체크리스트

- 배경/현황

- 목표/목적

- 정책사항 

- 화면설계서 

- 통계지표: 제품 성공을 판단할 정량적인 기준 

애자일	Pm, PD, 개발자 모두가 문제를 해결하기 위한 방법을 진행
워터폴	서비스기획자가 요건 정의 - 디자이너 화면 설계 - 개발자 작업
애자일+워터폴 타협지점	통상적으로 워터폴로 진행하되, 문제해결방법 구상에 있어 초기단계에 제품팀과 함께 고민

 

애자일방법론과 워터폴방법론, 도그냥식 설명법

 

2. 기획서는 촘촘하면 좋지만 반드시 그래야만 하는 것은 아니다 

- 꼼꼼하게 하려는 것보다 완성의 빈도와 횟수를 높이자. 

- 이 기능이 잘 만들어졌는지 평가할 기준을 잘 잡는 것이 중요하다. 교훈을 얻을 수 있을때야 비로소 쓸모가 있다. 

---

만들자!

스프린트 단위로 일을 할 때의 중요한 약속 중 하나는 정해진 날짜에 합의한 대로 제품을 구현하는 것이다.

 

1. 담당자 간 구현 작업을 조율한다 

- 디자이너와 협업시 유의

: 맥락에서 벗어난 피드백을 하거나 모순된 동시에 구체적이지 않은 요청사항을 지양하자 

: 내가 사용자라면 이상할 것 같다’와 같이 논리적인 근거 없이 의견을 개진하는 일은 지양해야 한다.

 

2. 요구사항을 충족하였는지 출시 이전에 테스트한다 

: QA담당자는 테스트케이스를 작성한다 

: 정책 또는 기획의도에 대한 문의사항이 있을 수도 있으며 QA 완료를 위해 모든 오류를 수정하기 보다 사소한 오류라면 백로그에 쌓아 두고 다음 스프린트에서 작업하기를 결정할 수도 있다

 

3. 출시를 위한 준비를 한다 

: 각 부서(마케팅/운영/사업) 문의사항에 대응하며 필요할 경우 업무 협조, 커뮤니케이션

: 각 OS별 앱스토어 스크린샷 업데이트, 키워드

 

---

잘 만들었나?

1. 제품이 목표를 달성하였는지 확인한다 & 목표 달성 여부를 팀 모두에게 전파해야 한다 

- 이 과정을 거쳐서 내놓는 리포트가 모두 목표를 달성하기만 했다면 좋으련만 그런 일은 거의 없으므로 마음을 단단히 먹는 것이 좋다

- 기능에 대한 통계지표 확인이 단시일 내에 이루어지지 않기 때문에 이번 스프린트에 배포한 기능은 다다음 스프린트 즈음에 작업하는 것이 일반적이다 

프로덕트 매니저는 한번의 기획으로 판세를 뒤집는다기보다 포기하지 않음으로 지표를 쌓아 올리는 사람이라고 생각한다. 원하는 지표가 나오지 않았다면 어디서 이탈이 발생했는지 그리고 그것을 방지할 수 있는지를 살펴보고 다시 백로그에 쌓아 보자. 내일은 내일의 스프린트가 있으니까

 

2. 개선사항을 도출하고 백로그로 쌓아둔다 

- 왜 목표를 달성하지 못했는지 그리고 그것을 달성하려면 무엇을 보강하면 좋을지에 대한 아이디어를 백로그로 옮긴다. 이 때 회고를 하면 많은 도움이 된다

- 목표 중심으로 회고하는 것은 중요하다 

---

프로덕트 매니저 역할 FAQ

 

Q1. 현업에서 쓰는 기획서는 어떻게 생겼나요?

- 회바회다. 단, 잘 쓴 기획서의 특징은 다음과 같다. 

1. 내용 구분이 잘 되어있고, 아무나 업데이트를 할 수 있는 문서이다. 

2. 설득력이 있는 기획서이다. 각 담당자의 전문 영역을 존중하고 그 분야에 대한 고민은 각 담당자가 할 수 있도록 유도하는 것이 시간을 아끼는 방법이다.

Q2. 저는 데이터 분석을 할 줄 모르는데요?

- (SQL) 데이터의 추출과 가공은 동료에게 부탁할 수 있고 일반적으로 현업에서도 백엔드 개발자 또는 데이터 분석가에게 요청하는 경우가 많다.

- 프로덕트 매니저가 중요하게 생각할 것은 그 데이터로 어떤 가설을 세울지에 대한 부분이다.

>> 어떤 것이 문제이고, 그래서 어떤 결론을 낼 것인지가 더 중요하다.

Q3. 서비스 기획자는 한국에만 있는 직무라던데요?

- 프로덕트 매니저의 역할에 관해 설명한 것과 같이 조직 내 각 구성원의 역할은 유기적으로 결정된다. 이는 조직의 문화와 닿아있고 나아가서는 지역 특색도 반영한다.

- 한국 IT 업계가 일하는 방식이 여타의 IT 업계와 무엇이 달라 서비스 기획자가 필요한지를 살펴봐야 한다. 그리고 그 방식에서 개선이 필요한 부분이 있다면 이에 대한 논의를 펼치는 것이 보다 생산성이 있는 논의가 될 것이다.