제로베이스 PM 파트타임 스쿨 7주차

Ch 10. 서비스 정책서와 요구사항 정의서(PRD)

 

1.정책서란 무엇인가

정책서: 서비스를 관장하는 용어와 운영정책과 원칙을 정의한 산출물

 

서비스 정책을 위한 고려대상: 법, 철학, 인지과학, 개발, 디자인, 역사, 인프라, 생태계

 

 

 

2. 문화, 역사, 인프라가 서비스 기획에 영향을 끼치는 이유

 

 

 

3.정책서 작성을 위해 고려해야 하는 법률

 

서비스 정책서 작성

불가항력적인 요소를 우선 고려하며 정책을 결정하고 문서로 작성,

작성된 정책 문서를 공유하며 합의를 이룰 때까지 수정 및 피드백을 반복한다.

 

관련 법령→외부 환경(생태계)→외부 환경(경쟁사)→내부환경 및 리소스 = 정책서

 

 

독일(프랑스) > 일본 > 한국 : 성문법 = 대륙법

 

영국 > 미국: 불문법 = 영미법

 

 

 

4. 커머스 서비스를 기획하기 위한 기본, 전자상거래법

 

5. 데이터 3법으로 바뀌는 미래와 서비스 기획

 

개인정보보호법

 

6. 큰 IT회사에서는 꼭 거쳐야 하는 관문, ISMS

 

7. 해외의 인증 사례 PCI-DSS, DGPR

 

8. 규제와 스타트업의 기획자의 역할

 

 

 

9. 규제샌드박스의 이해

 

10.서비스 약관과 정책서

11.정책서 작성사례

 

12.요구사항 정의서

 

신규서비스(기능포함) 업데이트 및 기존 서비스의 변경 등, 서비스의 변화를 가져오기 위해 변경 요구사항을 정의하는 것

 

 

 

---

Ch 11. 개발자와 디자이너와 협업하는 방법

 

1. 오늘의집 프로덕트 팀 구성소개

 

Cross Functional Product Team(목적조직)

Product Team = PDG + Tech Team

PDG (Product Design Group) = PO (Product %PDG leader) / PM / Product Designer

Tech Team - TL (Tech Leader) / Backend Developer / Frontend Developer

• 개발팀, 디자인팀, 기획팀 등으로 나눠진 기능조직과 비교하여 특정 목적을 이루기위해서 프로덕트 개발에 필요한 모든 인원이 하나의 팀으로 구성되어 있는 조직
• 자기 완결성을 띄어야 한다. 유저에게 피드백을 얻기 위한 최소한의 단위의 제품증분이나 MVP를 만들 수 없는 조직이라면 애자일 조직구성으로서 완벽하지 않다.
• 다양한 기능을 담당하는 팀원이 하나의 목적을 이루기 위해서 일하기 때문에, 시너지를 발휘할 수 있음

 

 

2. 서비스 기획직무(PO, PM)이 개발자 및 디자이너와 효과적으로 협업하는 방법

 

(1) 협업능력

1. 개발자와 디자이너의 업무 방식을 존중하고 효율적으로 일할 수 있도록 돕는다
2. 개발자와 디자이너가 절차상 필요한 존재라고 치부하지 않고, 중요한 파트너로 대한다.
3. 개발자와 디자이너가 제대로 일할 수 있도록 충분한 시간을 준다.
4. 프로젝트 초반부터 개발자와 디자이너가 참여하도록 독려한다.
5. 전문가에게 권한을 위임한다.

(2) 커뮤니케이션능력

1. 커뮤니케이션이 일관적이 명확하다.
2. 팀원의 의견을 경청하고, 다양한 의견을 실행방안으로 만들어 낼 수 있다.
3. 최대한 많은 정보를 자주 공유한다(오버커뮤니케이션 > 언더커뮤니케이션)
4. 지속적인 소통을 통해 팀원들이 무엇을 하고 있는지, 앞으로 무엇을 해야하는지 잘 알고 있다.

(3) 업무범위 및 리스트 관리 능력

1. 중요한 것에 집중한다
2. 무자비할 정도로 불필요한 것을 걸러낸다
3. 업무 범위 조정과 실험을 통해서 리스크를 관리한다

(4) 의사결정 능력

1. 사용자와 비즈니스 결과를 최우선으로 고려하여 일관적이고 투명한 결정을 내린다
2. 자신의 자존심이나 명성을 위해서가 아니라 소비자, 비즈니스, 팀을 위한 결정을 한다
3. 데이터에 기반한 결정을 내릴 줄 안다

(5) 업무지식

1. 정성적/정량적 리서치 방법에 대해서 이해한다
2. 데이터를 활용하고, 데이터를 이해하는 사람과 협업할 수 있다
3. 어떤 결정을 내릴 때 기술적으로 무엇을 의미하고 오래 걸릴지 이해하려고 노력한다
4. 최소한의 개발지식 및 디자인 지식을 보유하고 있다

(6) 목표와 비전 설정

1. 왜 이일을 해야하는지 그 비전과 목표를 제대로 설명할 수 있다
2. 지속해서 사용자, 경쟁사, 시장조사를 하고 이를 제품에 반영한다
3. 해결책보다는 문제가 무엇인지에 대해서 더 깊이 고민한다

(7) Biz Stakeholders와 건설적인 의견 교환 능력

1. 경영진에게서 오는 압박을 잘 수용하고 이를 해결하기 위해 어떤 업무를 해야하는지 알 수 있다
2. 제품을 더 좋게 만들기 위해서 회사 경영진에 이의를 제기할 수 있다

(8) 개방적 태도

1. 피드백을 사적인 감정으로 받아들이지 않는다
2. 자기 아이디어와 사랑에 빠지지 않는다
3. 팀원이 답변을 요구하면, 제때 제대로된 답변을 할 수 있다

 

이번 파트는 특히 법률적 지식에 관한 정보가 많았다.
그래서 사실.. 제일 집중하기가 힘들었다.
아직 구체적으로 이런 일을 겪어보지 않았다보니 이해도도 현저히 앉았고
법적지식들은 좀 지루하게 느껴졌다.
그래도 나중에 일할때는 꼭 필요한 지식들일테니 잘 메모하고 기억해두었다가 써먹어봐야겠다.