프로덕트오너 – 김성한

사이드프로젝트에서 프로덕트를 리드하는 PM역할을 하겠다고 나섰지만, 

9명의 팀원을 이끌기에는 내 역량이 부족하다 라는것을 느끼던 와중에 만난 책.

사내에서 프로젝트를 할 때는 개발자, 기획자 대표 1명과 소통을 하면 되다보니,

사이드 프로젝트에서 다수의 개발자와 디자이너의 의견을 파악하고 제품에 적용하는 것에 어려움을 느꼈다.

 

그러던 중 유튜브로 김성한님의 인터뷰를 듣게 되었는데, 자연스레 이 책을 구매를 하는 나를 발견하게 되었다.

쿠팡의 프로덕트를 책임지는 PO 김성한님의 PO가 되는 법, 쿠팡에서 PO로 일하는 법 등 다양한 이야기들이 담겨있다. 

이렇게까지 상세하게 영업기밀을 알려줘도 되는 건가? 싶을 정도로 꿀팁들이 가득했다. 

 

당장 나에게 적용하고 싶은 부분은 3가지였다.

1. 스토리티켓 

신규 개발을 위해 스토리 티켓을 팀원들에게 공유하는 것
그 티켓에는 목적, 배경, 고객을 위해 어떤 일을 하는지, 원칙, 목표, 주요지표, 개발계획, 자주묻는 질문을 담아 공유한다.

2. 개발팀과의 협업을 성과로 이끄는 애자일 전략

디프만 10기의 PM을 하며 시작한 것은 일주일 단위의 스프린트 협업이다.

개발자가 아니다보니, 개발자의 현재 작업 상태를 파악하기 어렵다는 고민을 해결하기 위해 스프린트 보드를 적고 있었다.

하지만 팀원들에게 익숙하지 않은 방식이다보니 보드에 할 일을 적지 않거나, 3주간 보드가 똑같은 팀도 있었다.

이 책에서는 스프린트 회고에서 이전에 개발한 것과 개발완료하지 못한 것, 이번 스프린트에 개발해야하는 것을 회의하라고 말한다.
그래서 당장 저번주 모임부터 적용해서 스프린트 회고를 시작했다. 

Todo - Doing - Done 으로 나누어 팀· 담당자별로 개발이 완료된 것과 완료되지 못한 것, 해야할 것을 이야기했다.

3. UT 하는 방법

유저테스트 절차와 주의사항,  UT가 끝난 후 피드백 문서를 작성하는 법까지 나와있어서 유용했다.

저번주에 와이어프레임 단계에서 Maze를 활용한 UT가 진행되었는데, 방식은 달랐지만 쿠팡의 UT하는 방식을 따라해볼 수 있었다.

팀원들에게 공유한 'UT 사전준비' 예시

 

---

 

1장  프로덕트 오너는 미니 CEO다.

 

1.1  PO는 중심에 있다

프로덕트 오너는 특정서비스에 대한 책임을 지는 자다. PO는 실질적으로 고객이 무엇을 필요로 하는지 끊임없이 분석하고, 선보이려는 서비스가 사업목표에 부합하는지 검증한다. (고객-PO-회사 교집합)

 

1.2  독재자형 리더는 안된다

아무리 급해도 결정을 일방적으로 통보하는 태도로 임한다면, 장기적으로 다른 이들에게 존중받기 어렵다. 왜 우선순위가 급하게 변경되었는지, 무엇을 이루고자 하는지를 당연히 알려줘야 한다. PO는 늘 명확한 사실과 데이터를 가지고 설득해야 한다.

나는 늘 협업하는 개발자나 데이터 과학자의 상태를 살펴본다. 안좋은 상태를 방치하면, 고객에게 전하려고 하는 경험을 선보이는 과정이 점차 악영향을 받게 된다.

PO는 누군가에게 결정을 통보하고, 실행하는 CEO가 아니다. 오히려 그 누구보다 더 저자세로 임하고, 경청하며, 사실만을 토대로 설득을 거듭하는 고독한 자에 가깝다.

 

1.3  책임은 있지만 권한은 없다.

문제가 발생하면 PO에게 질문과 눈길이 쏠리지만, 큰 성공을 거두려면 PO는 함께 이룬 동료들에게 공을 돌린다. 그들이 직접 두 손으로 만든 서비스이기 때문이다. 부여된 책임감은 많지만, 권한이 없는 PO는 언제나 겸손해야 한다.

 

1.4  고객에 또 집착하고 또 집착하라

도요타 프로덕트 시스템 중 핵심 원칙 ‘현지 현물’은 “가서 직접 봐라”라고 풀이된다. 이 원칙은 어떤 현상을 이해하기 위해 직접 현장에 가서 관찰할 것을 제안한다.

고객에 집착하듯이 집중하고, 고객이 원하는 제품을 어떻게 만들어야 할지 고민하는 것이 성공으로 이어지는 원칙이다. PO가 이행해야 하는 가장 중요한 의무 중 하나는 고객에게 집착하는 것이다. 현장이 있으면 현장으로, 공장이 있으면 공장으로, 판매처가 있다면 판매처, 심지어 단순하게 고객센터에 가서 전화통화를 옆에서 들어도 도움이 된다. 그리고 각각의 고객이 무엇을 불편하게 여기는지, 어떤 경험을 원하는지 등을 데이터까지 분석하며 파악한다.

 

---

 

2장  고객의 목소리를 어디까지 반영할 것인가

 

2.1 고객은 제품을 사지 않는다, 고용한다

제품이 단순히 구매된다는 관점에서 벗어나, 고객이 무엇을 해결하기 위해 어떤 제품을 고용했는지 생각해봐야 한다. 모든 제품과 서비스를 고용의 대상으로 바라보면, 각각 어떤 일을 고객을 위해 해줘야 하는지 알 수 있다.

PO는 프로덕트를 기획하거나 개발 방향을 결정할 때, 어떤 고객이 왜 해당 프로덕트를 고용할지 철저하게 고민해야 한다.

 

2-2. 서비스는 하나라도 사용자 유형은 다양하다

“그 회사에서 만든 프로덕트는 어떤 고객에게 무슨 가치를 제공했죠? 목표가 무엇이었나요? 그 기능을 누구에게 왜 제공했나요? 어떻게 고객을 분류했나요?”

전자상거래 서비스를 고용하는 고객 분류

1) 구체적인 목적이 있는 고객 : 메인 - 서비스에 접속하자마자 자주 구매, 최근 구매 상품 보여주기,
   상품상세 –  빨리 가격, 장바구니 넣고 바로 구매 유도
2) 목적이 있지만 발견해야 하는 고객 : 키워드 검색, 카테고리 이동, 검색결과 - 맞춤 상품 추천
3) 발견을 원하는 고객

 

2-3. 모든 사람을 만족시킬 수는 없다

PO는 쉽고 간단하게 고쳐서 최대한 개선된 경험을 제공할 수 있도록 늘 살펴야 한다.

최소한의 노력으로 최대한의 결과를 내야 한다. 고객의 불편사항을 접하고 개선하는 것

이 PO의 몫인 것은 분명하지만, 모든 고객의 의견을 다 들어줄 수는 없다. 자원은 한정

적이기 때문이다. 그래서 나는 늘 얼마나 많은 고객에게 영향을 끼치는지 확인하려고 한

다.

PO는 언제나 우선순위를 정해야 한다. 그때마다 늘 한정된 자원을 어떻게 활용해야 가장

효과적일지 고민하도록 한다.

 

2-4. 식스페이저로 모두의 동의를 얻어 기록하라

쏟아들어오는 요청 중에서 당장 무엇부터 해야 할지 몰라 허덕일 수 있다. 유관 부서에

서 우선순위가 어떻게 정해졌는지 문의하면 대답을 최대한 논리적으로 해야 한다. 그래

서 원칙이 필요하다. PO라면 자신이 책임지고 있는 프로덕트에 대한 원칙을 반드시 정하

길 바란다.

 

2-5. 고객의 요청과 회사가 정한 목표가 충돌한다면

PO는 회사와 고객의 중심에 있는 존재다. 고객에게 더 나은 경험을 제공하기 위해 집착

하는 것도 중요하지만, 사업을 이행하는 회사를 잊지 않도록 한다. 회사 전체에 대한 유

기적인 고려 없이 독단적으로 고객을 위한다는 취지로 방향성을 잡는 건 옳지 않다. PO

가 사업적인 관점을 유지하고, 경영진의 시각을 이해하고 있어야 우선순위를 결정할 때

참고할 수 있다. 고객에게 계속 최상의 경험을 제공하려면, 회사가 건강한 상태여야 한다.

 

---

 

3장  데이터 속에서 진실을 찾는 법

 

3-1. 자신을 믿지 말고 데이터를 신뢰하라

PO는 직관에 의존하면 안된다고 생각한다. 자신이 바라보는 관점이 맞는지, 예상이 맞을지 확인하는 것도 데이터로 검증한다. 그리고 그 데이터가 제대로 된 방법으로 얻어진 것인지 검토하라.

PO라면 자신에게 주어진 데이터를 그대로 받아들여서는 안된다. 긍정적이라고 보이는 데이터일수록 거짓이라고 가정해본 후 철저하게 파고들어야 한다. 결과라고 여겨지는 데이터가 얼마나 유효한지 의심을 가져야 하는 이유는, 데이터 속에 거짓이 숨어 있기 때문이다.

데이터의 신뢰도를 실험하고, 노이즈를 파악하며, 전체적인 그림을 그릴 수 있게 된다면 PO는 더더욱 진실에 가까운 위치에서 프로덕트를 개선할 수 있게 된다.

 

3-2. 대시보드를 통해 정기적으로 확인하라

PO는 주기적으로 데이터를 확인해야 한다.

1)     주요 대시보드 만들기

매일 수시로 확인해야만 하는 지표를 정하고, 그걸 볼 수 있는 대시보드를 생성하라.

2)     WBR 만들기

주간실적분석(Weekly Business Review) 문서를 만들고 30분에서 한시간 정도 회의를 한다. 프로덕트와 관련된 최근 변동사항, 현재 문제점을 파악한다.

WBR에 포함해야 하는 내용
-  주요 요점 : 지난 WBR회의 후 일어난 주요 사항
-  프로덕트 목표 : 프로덕트를 통해 분기 또는 연간 달성하고자 하는 목표
-  주요지표 : 대시보드에서 꼭 중요한 것 선별. 주별 데이터 3주치, 월별 수치 최근 2~3개월 기재. 어느 영역에 문제가 있고 잘되고 있는지 확인

 

3-3. 행동을 부르지 않는 데이터는 버린다

데이터를 보며 계속 한가지 질문을 속으로 되묻는다. ‘그래서 뭐?’ ‘그래서 우리가 무엇을 할 수 있지?’ 같은 질문을 던진다.

 

3-4. 가설을 세우고 조직의 방향성 OKR까지 관리하라

가설은 PO의 생각을 증명하기 위해 꼭 필요한 수단이다. 론칭 전과 후를 비교하기 보다는, 고객 군을 최소 두 개로 나눈 후 동일한 기간 동안 한쪽에만 기능을 제공해서 각각의 상품 구매율을 비교해보는 것도 하나의 방법이다.

Objective & Key Results(목표와 핵심결과)의 줄임말인 OKR은 회사 전체의 목표와 직원 개개인의 목표를 맞추기에 효과적이다.

 

3-5. 리스크를 최소화하기 위한 데이터 검증법

동시에 테스트하는 다른 기능들과 분리해서 상관관계를 확인하는 방법 - 테스트 일정 변경, 테스트 대상 조정

고객을 대상으로 새로운 기능을 테스트할 때, 고객의 행동 변화를 트래킹 하는 건 상당히 중요하다.

 

---

 

4장  효율적인 일정 관리의 비밀

 

4-1. 스토리 티켓으로 누구에게 무엇을 알려야 하나?

회의 전후 문서화하여 지식 배포하는 ‘스토리티켓’에 포함해야 할 것

1) 목적 : 최대 2~3문장 이내로 문서의 목적
2) 배경 정보 : 2~3문단에서 반장 정도로 왜 이 신규기능이 필요한지 설명. 진행상황과 풀고자 하는 문제, 앞으로의 방향성
3) 고객을 위해 어떤 일을 하는가? : 목록 형태로 작성. 각 고객이 왜 해당 기능을 ‘고용’할지에 대해 짧고 명확하게 명시
4) 원칙 : 기능 개발 과정에서 결정을 내릴 때의 원칙 세우기. 6개 이내.
5) 목표 : 어떤 목표를 세울지 수치화. 2~3개로 한정
6) 주요지표 : 기능이 고객을 위해 목적을 수행하고 있는지 나타낼 수 있는 지표 3~4가지 선정.
7) 개발계획 : 1단계 MVP , 2단계, 3단계 개발사항 나열.  단기간(1달), 중장기(3달), 장기(6개월)로 나눠서 시기별로 무엇을 해야 하는지 설명. 개발 완료 예정시간과 상태 표기. 문제가 없을 경우 Green, 미완성 할 것 같을 때 Yellow, 개발 완료될 가능성이 없을 때 Red 로 표기
8) 자주 묻는 질문 : 목록 형태로 나열

신규 개발을 위해 티켓을 생성할 때 활용하는 세가지

1)  에픽 : 목적, 개발타당성, 목표, 주요수치
2)  스토리 : 구체적인 개발 요구사항. UX흐름 문서나 디자인 시안
3)  태스크 : 스토리가 완료되기 위해 개발되어야 하는 것들

 

 

4-2. PO가 해서는 안되는 일

PO의 임무는 개발과 디자인을 직접하는 게 아니다. PO는 개발자, 디자이너, 비즈니스 애널리스트 등이 각자의 임무를 잘 이행할 수 있도록 요구사항을 명확하게 하고 방향성을 제시하는 데 집중해야 한다.

 

4-3. 스크럼 회의 때 해야 할 일들

테스트 일정, 계획 변경사항 전달. 질의 과정으로 설명. 문서나 티켓을 미리 수정하지 못했을 경우 공유.

프로덕트 별 대시보드(PO의 개발 백로그) – 온라인 스프레드 시트 생성, 요청일자 , 요청자 이름 및 소속 팀, 요청사항 또는 기능 명칭, 간략한 설명, 우선순위, 티켓 링크, ETA, 개발상황, 기타/메모

우선순위 명시하는 방법

P0 : 최우선시 되어야 하는 개발물
P1 : 가급적 완료해야 하는 개발물
P2 : 완료되면 도움이 되는 개발물
P3 : 완료되지 않아도 지장 없는 개발물

 

---

 

5장  디자이너를 최고의 파트너로 삼는 법

 

5-1. 디자이너는 PO의 의도를 구현해주는 최고의 파트너다

최고의 프로덕트 디자인은 고객의 불편함을 덜어주는 것이다.

 

 

5-2. 과연 편리하고 직관적인 디자인인가?

PO는 사용자가 고민하지 않고 편하게 사용할 수 있는 프로덕트가 탄생하도록 질문해야 한다. 고객이 사용할 때 어떤 느낌이 들지 가정해보며, 조금이라도 모호한 점들을 찾아내려고 노력할 뿐이다.

디자인리뷰 원칙

1)  PO는 오로지 고객을 대변하는 입장이어야 한다. 감정, 관계 등을 일체 배제한다.
2)  개발하고자 하는 기능에 대해 정한 원칙에 기반하여 판단한다.
3)  디자이너에게는 질문의 형태로만 의견을 피력한다. 절대로 지시하지 않는다.
4)  질문한 후에는 디자이너의 의견을 경청한다. 모든 시안은 고심의 결정체다.
5)  구두로 거론된 내용을 회의 직후 기록하여 전달한다. 디자이너가 선호하는 방식을 따른다.
최고의 프로덕트를 만들기 위해서 때로는 비판이 필요하다. 개인적으로 함께 일하는 동료의 기분을 상하게 하고 싶지 않지만, 이런 원칙을 상기하며 중립적인 고객의 시각으로 생각하고 말하려고 한다.

PO는 고객 입장에서 대변해야 하기 때문에 고객이 느낄 불편함을 제거할 목적으로 질문해야 한다. 그 과정에서 동료의 기분이 상할 것을 크게 신경 쓰지 않도록 하라.

사용자 관점에서 생각하는 방식을 트레이닝하기 위해 매우 다양한 모바일 앱과 웹 사이트를 사용해보며 내가 느끼는 바를 되새기는 과정을 반복했다. 지금은 약 500개의 모바일 앱이 핸드폰에 설치되어 있는데, 한 때는 1,000개가 훨씬 넘는 앱이 상시 설치된 적도 있다.

 

5-3 동료 직원을 대상으로 캐주얼 UT를 하라

캐주얼 UT 진행 방식

1.     “이제부터 신규 서비스를 가입하려고 합니다. 어떻게 진행할지 보여주세요.”등의 간략한 설명으로 시작한다.

2.     대상자가 사용하는 모습을 지켜본다.

3.     만약 한 곳에서 오래 머물거나, 예상치 못한 행동을 보일 경우, “현재 한 곳에 오래 머물고 있는데, 무엇을 하려 하나요?”등의 질문으로 의도를 확인한다.

4.     일단 흐름을 최대한 끊지 말고, 처음부터 끝까지 사용하는 모습을 지켜보도록 한다.

5.     한번 완료하면, 다시 처음으로 돌아가 재시도를 요청한다.

6.     이때, “방금 버튼을 눌렀다가 다시 돌아갔습니다. 왜 그랬나요?’등의 질문을 하며 의도를 확인한다.

7.     대상자가 느끼는 점을 메모해둔다.

8.     마지막에는 대상자에게 질문할 기회를 주고, 설명할 수 있는 것들은 설명해준다.

모든 질문은 대상자의 의견을 얻는 형태로 물어봐야지, 절대로 힌트를 내포하고 있으면 안된다.

 

---

6장  개발팀과의 협업을 성과로 이끄는 애자일 전략

6-1. 확실한 프로젝트 수행법, 스프린트 플래닝

* 스프린트 플래닝 전에 개발 조직과 공유할 것

1. 이전 스프린트에 개발 완료한 것 : 기능 명칭, 에픽명, 티켓 링크, 담당자, 배포일자, 주요사항

예시

안드로이드 서비스 UX개편 UX Renewal
- Ticket-1000
- Owner : 담당 개발자
- 배포일자 : 04/15
- 7일간 테스트 후 100% 적용 완료

 

2. 이전 스프린트에서 개발을 완료하지 못한 것

스필오버Spillover : 한 스프린트 내에 끝내지 못해 그다음으로 넘어가는 것

iOS 서비스 UX개편 UX Renewal
- Ticket-1001
- Owner : 담당 개발자
- 배포일자 : 04/15
- QA도중 발견한 버그 수정을 위해 앱 스토어 등록 연기

한 스프린트 내에 완료하지 못했다고 비판할 필요가 없다. PO는 이렇게 완료하지 못한 것을 스프린트에 이어서 개발할지 명확하게 알려주면 된다.

 

3.이전 스프린트에 발생한 기술적 이슈 또는 버그

인시던트 리뷰 Incident Review : 에러나 버그이슈가 발생했을 때, 원인, 대응방식, 개선책 등을 심도 깊게 논의하는 자리

iOS 사진 5장 이상 등록 불가
- INCIDENT-2000
- 발생일 : 04/12
- 고객 임팩트 : 04/12 오전 8시부터 약 20분가량 iOS 사용자 중 다수의 사진 등록을 시도한 000,000명이 일시적 업로드 불가
- 04/16에 Incident Review 진행 완료

 

4. 이전 스프린트에 대한 회고

조직원 각자가 느꼈던 좋았던 점과 개선해야할 점

	조직원	잘한 점(Good)	개선해야할 점 (Need to Improve)
1	개발자 A 이름
2	개발자 B 이름
3	디자이너 이름
4	개발 매니저 이름
5	PO이름

 

5. 이번 분기 OKR 달성상황

OKR : Objectives and Key Results의 약자로 목표와 성과 지표

 

6. 이번 스프린트에 개발해야 하는 것

iOS 서비스 UX개편 UX Renewal
- Ticket-1001
- Owner : 담당 개발자
- ETA : 04/15

PC로그인 페이지 개편 Usability
- Ticket-1002 
- Owner : 담당 개발자
- ETA : 04/15

 

---

7장 고객 테스트 결과만큼 강력한 데이터는 없다

7-1. 사용자 테스트 UT로 문제점을 보완하라

PO는 테스트 도중 검증해야할 사항들을 미리 정리해놓는다.문서화해놓은 사항들을 보며 UT를 진행하는 중에 대상자가 주요 기능을 잘 이해하는지 확인한다.

	화면	검증해야 할 사항
1	홈 화면	- 사용자가 홈 화면에서 음식을 선택하는 방식을 이해한다. - 사용자가 홈 화면에서 특정 음식을 검색할 수 있다. - 사용자가 홈 화면에서 이전에 주문했던 음식을 불러올 수 있다.
2	벤더 목록	- 사용자가 수많은 업체 중 자신이 원하는 식당을 선택할 수 있다. - 사용자가 다양한 카테고리 중 하나를 선택하여 이동할 수 있다. - 사용자가 특정 식당 페이지로 진입하는 방법을 인지한다.
3	벤더 화면	- 사용자가 메뉴를 확인할 수 있다. - 사용자가 사진을 어떻게 확인하는지 안다 - 사용자가 신규 주문 버튼을 인지한다.
4	주문 화면	- 사용자가 주문하려는 음식과 가격을 확인할 수 있다. - 사용자가 주문 시 사용할 결제 정보를 알고있다. - 사용자가 주문 시 메모 남기는 방법을 인지한다.

 

온라인 UT 절차

1. 대상자에게 간략하게 인사한다.

2. 정답을 확인하려는 것이 아니라, 어떻게 사용하는지 보려는 것이니 편하게 행동하라고 당부한다.

3. 사용하는 동안 머릿 속에 떠오르는 생각 등을 자유롭게 말해달라고 부탁한다.

4. 궁금한 점은 모든 절차가 끝난 후 질문해도 된다고 말한다.

5. 소요 예상 시간을 안내한다.

6. "오늘은 음식 배달을 위해 서비스를 사용하는 모습을 확인하려고 한니, 음식을 주문해보세요"라고 간략하게 상황을 설명한 후 UT를 시작한다.

 

주의사항

- 대상자는 스마트폰에 설치된 프로토타입을 실제 앱인 것처럼 사용하고, PO와 디자이너는 화면을 통해 확인할 수 있다. 

- UT를 진행하면서 최대한 힌트를 주지 않고 전체 흐름을 스스로 경험해볼 수 있도록 관여하지 않는 게 좋다.

- PO는 질문을 통해 특정 행동이나 답변을 유도해서는 안된다. 

- 대상자가 보이는 행동은 관찰자가 메모해주는 것이 좋다.

 

질문 예시

- 방금 홈 화면에서 약 6초간 아무런 행동도 보이지 않고 "음"이라는 소리를 내셨어요. 무슨 생각을 하셨나요?

- 화면 하단으로 스크롤 했다가 다시 급하게 상단으로 이동하셨어요. 왜 그러셨나요?

- 진행하던 주문을 취소하고싶다고 가정해볼게요. 어떻게 취소하실 건가요?

- 방금 이 버튼을 누르려고 시도하셨어요. 버튼을 누르면 어떤 현상이 나타날 거라 예상하시나요?

 

UT가 끝난 후

- 디브리핑 : 관찰에 참여했던 사람이 모여 브리핑 회의

- 서로 관찰했던 점, 대상자가 보인 특이점, 시안에서 보완해야 할 사항 공유

 

UT 피드백 문서 예시

UT1 - 30대 여성, 최초 사용자
	화면	관찰 노트	수정 사항
1	홈 화면	- 홈 화면에 노출된 배너 때문에 헷갈려 함 - 타코를 주문하고 싶어하는데, 카테고리 확인에 시간이 걸림 - 검색 기능은 직관적으로 잘 이해함 - 스크롤할 필요가 없지만 스크롤을 시도함	- 배너 크게 수정 - 카테고리 아이콘
2	벤더 목록	- 식당이 정렬된 기준을 이해하지 못하지만, 개의치 않음 - 정렬 기준 변경을 위한 아이콘 인지 못 함 - 배달비가 저렴한 순으로 보고 싶어함	- 정렬 아이콘 변경 - 정렬 기준 표기
3	벤더 화면	- 메뉴 내 세부 카테고리가 구분되어 있길 희망함 - 특정 가격대의 음식만 필터링해서 보고 싶어함 - 메뉴 내 검색 기능이 있으면 편할거라고 느낌 - 최소 주문 금액은 인지 했음 - 음식 선택 후 최소 주문 기준과의 차액을 모름	- 세부 카테고리 구분 - 금액 차액 표기
4	주문 화면	- 주문 처리 과정에서는 막힘이 없었음 - 카드 주문 방식에 대한 이해도가 높음	없음

 

 

---

8장 프로덕트를 출시하는 최적의 시기

8-1. 배포 일정을 정할 때 플랫폼을 고려하라

PC 플랫폼 : 기관의 검증이 필요가 없으므로 배포 일정이 자유로움안드로이드 : 구글플레이에 새로운 버전 배포하면 바로 플레이스트로어에서 업데이트 가능iOS : 애플의 검토 및 승인이 필요함

배포 일정 원칙
- 개발 조직이 정한 배포 일정이나 절차가 있는지 먼저 확인한다.
- 다른 팀과의 협업이 필요한 상황이라면, 최대한 미리 배포 일자를 협의한다.
- 가급적이면 저녁 늦게 또는 금요일에는 배포하지 않는다.

 

8-2. 내부 직원도 고객이다

 내부 고객용 프로덕트가 새롭게 업데이트 될 때마다 배포 예정 일자 며칠 전에 안내 메일을 보낸다. 

기능의 명칭
개발한 이유
배포 예정 일시
사용 안내서
문제 대처 방법