Chap 01. 서비스 기획 첫걸음

10
09

ACTIVITY/PM 스쿨 일지

Chap 01. 서비스 기획 첫걸음

1. 서비스 기획은 무엇인가

서비스 기획 : 사용자들이 겪고 있는 문제를 발굴하고 이를 해결하기 위해 필요한 모든 과정을 설계하는 것
- 사용자들이 인지하지 못하는 문제를 제시해서 해결해주는 것도 PM의 역량이 아닐까?
기획자는 전략, 사업, 기획, 디자인, 개발 모든 과정에 참여하게 됨
전략 : 사용자들의 니즈를 파악하고 이를 해결하기 위한 컨셉을 제시하는 역할
- 사용자 니즈 파악 방법 : 리서치, 벤치마킹 등
- ex. 공항에 도착하자마자 내 캐리어가 지정한 장소까지 운반이 되면 좋겠다!
사업 : 수익성을 만들어내는 역할
- 사업성 검토 방향성 내에서 비즈니스 모델을 설계함
- 사업 부분이 있을 때도 있고 없을 때도 있음
- B2C 서비스를 운영하면 따로 사용자 대금이 없는 경우가 많음
- 이 경우에는 사업팀이 관여할 부분이 없어서 초기에는 배제되는 경우가 많음
- ex. 캐리어당 과금 (이용대금)
기획 : 컨셉을 실제로 제품화하기 위한 모든 과정을 설계하는 역할
- ex. 앱 설계
디자인 : 설계도를 바탕으로 사용성에 맞춰서 디자인 시안 제작하는 역할
- ex. UXUI를 고려한 디자인
개발 : 설계도에 맞춰 실제 사용자에게 안겨줄 제품을 만드는 역할
이 모든 과정에 영향을 미치는 직업이 PM

Pre-Production : 집을 설계하는 과정 (설계도가 나오는 과정)
- 리서치, 타당성 검토, 사업성 검토, 개발이슈 검토, IA 설계, 필요 스펙 정리, 화면설계
Production : 집을 실제 건축하는 과정
- 디자인팀, 퍼블리싱팀, 개발팀 담당
Released : 집을 인테리어하는 과정 / 제품을 출시하는 단계
- 마케팅팀, 운영팀, 사업팀 담당
- 빈집을 꾸미는 과정..!

2. 서비스 기획의 프로세스 - Pre-Production

Pre-Production : 제품 및 서비스를 설계하는 단계

1) 리서치 : 문제해결을 위한 원인 분석 및 해결방안 검토를 위한 자료조사 단계

로그 데이터 : 서비스에 사용자들이 만든 이벤트, 행동 등이 기록되어있는 데이터 / 사용성 데이터로서 사용자들의 습성, 행태 등을 파악하는데 용이하게 사용됨
A/B 테스트 : 애자일 방법론에서 많이 쓰임 / A, B 옵션 중에서 어떤 옵션을 우리의 의도에 맞게 사용하고 있는지 검증하는 단계
VOC : Voice Of Customer / 고객들의 문제에 대한 제안들을 뜻함 (정성적인 데이터) / 실질적으로 어떤 어려움을 겪고 있는지 파악할 수 있는 소스
사용자 서베이 : 사용자 설문조사를 통해 답변을 유도하는 형태
FGI 인터뷰 : Focus Group Interview / 우리 서비스의 타겟이 되는 그룹에 대한 인터뷰 ⇒ 실질적인 타겟팅을 보다 정교하게 할 수 있는 방법론
벤치마킹 : 이미 시장에 나와있는 경쟁사 혹은 시장에서 좋은 성과를 내고 있는 타사의 제품 혹은 서비스를 검토하고 조사하고 어느 정도 반영하는 단계 / 왜 잘나갈까? 부족한 점은 뭘까? 조사하는 과정

2) 타당성 검토 : 조사된 자료를 기반으로 해결방안 설계하고 상위 기획서를 작성하는 단계

상위 의사결정권자들과의 검토 단계를 위해 필요한 문서
- 이 사업을 왜 해야하는가
- 이 비즈니스, 제품은 왜 필요한가
- 왜 우리가 이 시장에서 이길 수 있는가
- 이 시장에서 우리는 어떤 역할을 할 수 있는가
- 사용자들에겐 어떤 베네핏을 제공할 수 있는가
- 실제로 이러한 베네핏을 제공할 수 있고 시장 핏이 맞는다면 우리는 어떤 방향성과 형태로 제품 및 서비스를 사용자에게 제공할 것인가
- 실현 가능성
  - 개발 단계에서 가능한지 의견을 구하는 것도 좋은 방법
  - ex. 블루투스 샤워기
- 타당성
  - 왜 만들어야 하는 가에 대한 이유가 명확한가?
  - ex. 무한동력 분무기(회귀 분무기)

- 온갖 왜?에 답할 수 있도록 스스로도 납득이 되는 서비스 혹은 제품을 기획할 수 있어야 함

3) 필요 스펙 정리 : 해결방안에 대한 구현방식 및 목표를 설정하고 해당 목표를 달성하기 위한 스펙 정리 단계

4) 사업성 검토 : 사업관련 부서와의 사업성 검토 및 스펙초안 확정 단계

사내 타 서비스와의 카니발리제이션 여부 검토
- 이미 돈을 잘 벌고 있는 캐시 카우, 킬러앱이 새로운 서비스로 인해 사장되게 된다면 회사 입장에서 손해임
- 새로운 제품을 출시함으로써 기존의 기능 혹은 제품 등의 손해를 끼치지는 않는가, 손해를 끼쳐도 출시해야 한다면 그 손해의 범위는 어느 범주 정도인가를 검토
내부자산 활용 방안 검토
- 회사 내에서는 기능적인 면, 디자인 컴포넌트, API 등의 내부자산이 있는데 이를 활용해 개발기간을 단축시키거나 좀 더 효율성이 좋은 서비스를 만들 수 없는지 검토하는 단계
서비스 패키징 가능여부 검토
- 기능을 개발할 때 많이 사용되는 단계
- 새로운 기능을 만들 때 기존의 기능과 묶어서 판매할 수 있을지 검토하는 단계
- 사용자들의 과금에 따라 차등을 두는 B2B 서비스에서 주로 검토함
사업팀과 기획팀이 동일한 선상에서 논의하는 과정임

5) IA 설계 : 협의된 스펙을 바탕으로 메뉴를 분류하여 Depth 구조로 설계하는 단계

< 출처 : https://www.behance.net/gallery/93156527/Project-Management-UX-Case-Study >

서비스 플로우
- 어떤 사용자를 대상으로 어떤 컨텐츠를 전달할 것인가?
- 기존 사용자의 사용패턴은 어떠한가?
- 각 섹션별 방문 목적은 무엇인가?
컨텐츠
- 각 섹션에서는 무엇을 전달할 것인가?
- 컨텐츠에 접근하는 사용자는 누구인가?
- 파트너향인가 사용자향인가?
커뮤니케이션
- 누구에게 전달될 자료인가?
- 어떤 용어로 통일하여 제공되어야 하는가?
- 해당 자료의 의도는 무엇인가?

6) 개발이슈 검토 : 논의된 스펙에 대한 서비스 구현 가능성 및 적합성 검토 단계

스펙 초안 리뷰이므로 추후 변경되거나 삭제되거나 추가될 수 있는 가능성이 있음
기능 구현 가능여부 확인
- ex. 블루투스 샤워기..
구현방향 논의
- 어떤 플랫폼으로 어떤 언어를 이용해서 구현할 것인가에 대한 논의
- 팝업, 모달, 웹뷰, 네이티브 클라 등에 대한 검토
추가 검토 필요사항 전달
- 추가적으로 기획자가 기획했을 때 좀더 검토가 필요할 것 같다고 전달하는 과정 ⇒ 개발팀, 디자인팀에서 실제 구현 가능 여부나 적합성을 검토해서 피드백을 줄 것임
리소스 할당
- 이 기능 혹은 제품을 구현하는데 소요되는 일정, 이 일정을 지키는데 필요한 인원 혹은 리소스는 얼마나 들어갈 것인가에 대해서 산정하는 단계
- 산정을 통해 해당 팀과 논의해서 담당자를 배정받음

7) 화면 설계 : 구체적인 서비스의 동작 및 정책 등을 정의하고 이에 대한 상세 기획서 작성 단계

프로덕션 팀이 독자라고 생각하고 한 권의 책을 펴낸다고 생각하면 됨
표지 및 목차
- 페이지네이션 제대로 하는 것이 중요
히스토리
- 기획서 버전 관리
- 상세 기획서는 버전 1, 버전 1.1 … 계속해서 업데이트 됨
- 기획서를 작성하면서도 계속해서 추가적인 논의가 이루어짐
- 기획팀, 프로덕션팀, 법무팀, 개인정보 보호팀과의 논의 등
- 지금 어떤 버전이고 이전 버전에서는 어떤 식의 업데이트가 진행되었다는 것을 명확하게 명시해야 함
사이트맵
- IA와 동일
화면 목록
- 기획서내 페이지별 컨텐츠 정리
상세 설계
- 플로우차트, 정책정의서 : 해당 스펙 혹은 서비스가 어떤 정책 혹은 어떤 로직을 가지고 운영이 되어야 하는지에 대해 설계하는 과정
- UI/UX 설계 : 어떤 버튼을 눌렀을 때 어떤 식으로 서비스가 동작하는가에 대한 상세 작성

3. 서비스 기획의 프로세스 - Production

Production : 제품 및 서비스를 개발하는 단계

1) 기획서 리뷰 : 상세기획서 작성 완료 후 관련 부서 전체에 공유하는 단계

2) 리소스 할당 : 서비스 개발을 위해 각 부서 담당자 배치를 할당 받는 단계

스펙 상세 리뷰 : 상세 기획서에 작성된 다양한 요구사항들을 다시 한번 설명드리는 단계
기능 구현 가능여부 검토요청 : 상세 기획서 내부에서도 이미 어떤 식으로 구현할지에 대해선 정의가 되어있는 상태지만 만약 개발적인 이슈가 발생한다면 구현이 불가능하거나 혹은 스펙이 변경되어야하거나 혹은 좀 더 효율적인 방향을 찾을 수 있는 가능성이 있기 때문에 기능 구현에 가능 여부 검토를 요청하게 됨
담당자 지정 요청 : 기능 구현 가능여부 검토요청까지 마치고 나면 해당 제품 혹은 서비스를 구현하기 위한 담당자를 지정해달라고 각 팀에 요청하게 됨
기능 구현에 대한 의견 청취 : 담당자가 지정되면 기능 구현에 대한 의견을 듣고 협의를 통해 전체 일정을 산정함
일정 산정

3) 디자인 요청 : 상세기획서 내용을 기반으로 서비스 디자인을 제공받으며 시안을 기준으로 수정사항 확인 및 반영하는 단계

디자인 가이드라인 공유 : 각 컴포넌트 간의 간격, 배치 등을 수치화해서 보여주는 단계 ⇒ 이 가이드라인을 통해 퍼블리싱팀이나 클라이언트팀이 붙어서 해당 디자인을 실제로 제품화하는 작업을 진행하게 됨
인터랙션 재검토 : 인터랙션이 디자인의 관점에서 적합하지 않다거나 좀 더 효율적인 방법을 제시할 수 있다거나 하면 이러한 의견을 반영하여 해당 인터랙션에 대해 재검토가 진행됨

4) 퍼블리싱 요청 : 디자인 시안을 바탕으로 마크업 작업을 요청하는 단계

5) 개발 요청 : 기획서 스펙사항을 서비스에 반영하는 단계

6) QA : 개발이 완료된 내용에 대해 품질 검증을 위한 테스트를 진행하는 단계

테스트 케이스 : 제품을 이용함으로써 발생할 수 있는 모든 케이스를 정리해놓은 리스트

7) 릴리즈 : 사용자에게 서비스를 오픈

사전 공지
- 기존 서비스의 경우 유저에게 사전 공지가 나가야 함
- 업데이트 내용, 업데이트로 인해 서비스 운영, 사용에 불편함을 줄 수 있는 사안에 대해 미리 고지 ⇒ 유저가 서비스를 지속적으로 운영하는 것에 대해서 혼란을 겪지 않도록 하는 작업
약관 검토
- 이용약관을 통해 유저에게 우리가 어떤 서비스를 제공하고 있고, 여기에 당신이 동의하고 있다는 것을 명시해주는 프로세스가 들어가야 함
앱 심사 요청
- IOS, 플레이스토어 등 심사 요청
릴리즈 대기
- 주로 사용자가 적은 주말, 새벽 등에 릴리즈 함
회고
- 좋았던 점, 개선할 점 회고 ⇒ 다음 프로젝트에 반영

4. 서비스 기획 방법론_애자일, 린, 워터폴의 차이

소프트웨어 개발 방법론에서 시작된 개념임
애자일 : 여러 번의 개선을 통해 점진적으로 발전시킴 / 시장의 빠른 변화에 대응가능한 트렌디한 방법론
워터풀 : 위에서 아래로 이미 정해져있는 프로세스

1) 워터풀 방법론

각 단계가 위에서 아래로 물이 떨어지듯 순차적 진행되며, 정해진 일정에 맞춰 각 단계가 진행되는 방법론
요구사항 정의 ⇒ 디자인 ⇒ 개발 ⇒ 테스트 ⇒ 배포 & 검증 ⇒ 회고 & 사용자 피드백 듣는 단계

< 장점 >

대규모의 팀의 합의점 도출이 용이함
개발주기가 정해져 있어 일정관리가 안정적으로 가능함
요구사항이 픽스되어 목표 변경에 따른 혼란이 방지됨

< 단점 >

개발 속도가 상대적으로 느림
개발 방향성에 대한 유연성이 부족함
처음 방향성 설정이 잘못된 프로젝트라면 프로젝트 자체가 엎어질 수 있는 위험성이 높음

< 적합한 조직 >

커뮤니케이션 비용이 높은 대규모 팀
순차적 프로젝트 타임라인 수립이 필요한 팀

2) 애자일 방법론

프로젝트의 반복주기를 작게 나누며 각 반복주기의 결과물을 측정하고, 지속적으로 각 주기를 평가하는데 사용하는 방법론