서비스 기획 특강 2

서비스가 의미있다는 것을 어떻게 확인할 수 있을까?

Product Life cycle에 따른 일의 구분을 통해 확인할 수 있다.

 

도입기 : MVP 상태에서 PMF를 찾기 위한 노력이 있어야 한다. Opportunity Solution Tree를 이용해서

• 온라인의 특성상 되게 좋은 서비스도 처음엔 뜨지 않을 수 있다. (사람들이 모르니까)
• 진짜 애자일하려면 이걸 필요한 시점에 만들고 필요없는 것들은 부술 수 있어야 한다.

성장기 : PMF의 달성을 확인

PMF를 어떻게 확인?

- PMF이 맞는 것이 보이면 그 후 개발 들어간다. -> j curve 나타난다.

이 때의 맞는다는 기준은

1. 위클리당 7~8%의 성장률을 자생적으로 보일 때
2. 리텐션이 월별 20% 이상으로 유지되기 시작될 때
3. 서베이를 통해 40% 이상이 서비스가 없어진다고 했을 때 극단적으로 아쉬움을 보일때 (20% 이하면 피봇팅)
4. NPS(Net Promoter Score) : 추천지수 10점으로 (NPS = 추천 고객의 % - 비추천 고객의 % > 80점 이상)

- PMF가 달성되기 전까지 서비스를 계속 조금씩 바꾸면서 실험을 해야 한다.

 

성숙기 : Scale up의 준비

• 프로덕트의 상황과 종류에 따라서 언제나 MVP로만 움직일 수는 없다.
• 레거시 기반 시스템의 플랫폼을 재정비해서 리팩토링하고 구조화해야 한다.
• 비스니스 요구사항의 최소 2분기 앞서서 고려하고 플래닝 준비 시작

PRD의 구성

PRD는 개발이 끝나서도 수정하는 문서(성공도, 단점, 리뷰등 모두 들어있다.), 살아있는 문서

6번까지는 프로젝트 시작하기 전에 끝내는 것

• 기능적 요구사항 - 큰 그림을 만들어서 user story를 작성할 수 있게끔, 정책과 프로세스 중심으로 들어가야 한다. (알고리즘은 어떻게 나누고 ,,, -> X, 14세 미만은 본인인증을 통해서 주문을 할 수 있게끔 정책 만듬 -> O)
• User Stroy - 사용자가 누구고 무엇을 통해서 무엇무엇을 할 수 있다. User Story를 정의하기 위해서 고객에 대한 정의가 명확해야 한다. 우리의 사용자는 누구이며, 어떤 목표를 가지고 있는가에 대한 전제조건이 있어야 정의할 수 있다.
• Dependency - 이 프로젝트에서는 타 프로덕트팀의 디펜던시를 최소화한다 by 제프 베이조스, MSA(Micro Service Architecture)로 구현해야 한다. MAS끼리 우리 서비스에서 서로 안 하겠다고 싸움,,
• 디자인 파일 / 개발 정리 파일 - 프로젝트를 진행하면서 개별 작성되는 모든 내용을 링크한다. Ex) 로고가 바뀌었다. 작성 -> 변경사항을 훨씬 더 빠르게 인식할 수 있다.
• 일정(Timeless & Milestone) - 1층 만들고 2층 만들고,, 기능을 쪼개서 일정을 잡는다.
• MVP 이후 추가 개선 플랜(evaluation plan) - 목표에 맞지 않아서 자른 기능들을 백로그나 추가 개선 플랜에 기록해야 한다.

User Story에 대한 가장 유명한 작성 방법

- 독립적이다 : User story가 겹치지 않아야 한다. ex) 고객은 상품을 담아서 주문할 수 있다. -> X, 장바구니에 상품을 담아서 수정하거나 삭제하거나,, 하위 스토리가 너무 많음!

- 협상 가능하다 : 스펙아웃이 가능하다 => 사용자는 결제 수단을 여러 개 중 한 개를 설정할 수 있다.

- 테스트가 가능해야 한다. 

프로젝트를 User story와 완료조건

ATDD(Acceptance Test Driven Development)

=> DDD(Domain Driven Development, 누가 봐도 이해할 수 있게 써라 Ex) 상품 출고, 결제 완료 등 O, d1, d2, d3 X)

와 TDD(Test Driven Development, 사용자가 할 수 있는 조건들을 가지고 테스트 코드를 쓴다.)를 넘어선 ATDD!

=> 개발자들이 실제 사용자들의 비즈니스를 이해하도록 도메인용어 테스트 가능한 구체적인 내용을 소스코드 수준까지 반영하는 것

- DDD를 추구하는 회사들은 서비스명이 변경될 때 코드를 싹 다 갈아버린다.

- 소스 코드도 비즈니스를 이해할 수 있게끔 짜는 것이 요즘의 트렌드이다.

- 단위테스트케이스 수준의 Userstory와 Acceptance Criteria를 작성, Acceptance Criteria를 맞추는 작업은 기획자와 개발자의 의견 합치를 위해서 필요하다.

User story 예시

금융지식을 위한 퀴즈앱 - 사용자가 출제한 사람, 문제를 푸는 사람

문제를 출제할 때는 pdf로 넣으면 자동으로 입력 -> 기존에 퀴즈에 대한 질답이 이미 있을 것이다.

문제를 푸는 사람은 출제한 사람이 문제 범위를 지정하면 이것을 기준으로 푼다.

문제를 푸는 과정을 보여준다.

 

initiative=============

도식도를 그려야 한다. Ex)

1. pdf를 넣기 -> 이미지를 인식 -> 인식 리스트를 확인 -> 저장

2. 사용자가 할 수 있는 것 : 사용자가 순서 설정 -> 저장

3. 출제자가 할 수 있는 것 : 등록 리스트를 확인 -> 사용자가 있는지 리스트 보기 -> 

 

출제자는 금융퀴즈를 등록할 수 있다.

   - sub story) : 출제자는 pdf로 된 문제 파일을 등록하며 문제를 등록할 수 있다.

AC 1. pdf가 암호가 걸려있을 때는 안내 문구를 반환한다.

AC 2. pdf에 문제가 하나도 없다고 인식될 때는 안내 문구를 반환한다.

AC 3. pdf를 선택할 때는 디바이스에서 저장된 업로드만 할 수 있다.

AC 4. 파일 크기는 최대 nm Byte까지 업로드 할 수 있다. (개발자와)

   - JPG로 등록을 하는 경우

문제를 푸는 사용자는 리스트에서 문제 리스트를 확인할 수 있다.

===================

용어 정리

PMF : Product Market Fit

MVP : Minimum Viable Product / 먹힐만한 프러덕트