서비스 기획의 A to Z | [패스트캠퍼스x야놀자 PM 부트캠프]

 

다시 시작하는 서비스 기획

 

서비스 기획은 맨땅에 헤딩으로 시작해 무수히 많은 점들이 서서히 선으로 변해가는 것을 보고 느끼는 성장의 과정

(지금부터 지극히 개인적인 저의 스토리가 시작될 텐데 관심이 없으시다면 모른 척 지나쳐주세요:-)

 

 

 

 

지금이 오기까지 나의 지난날은...

제2의 백종원이 되기를 꿈꾸며 대학교를 졸업하고, 지원사업을 받기 위해 사업계획서를 마구 적어보다 기회가 닿아 인턴의 형태로 중소기업청 프로젝트 관리자로 사회생활을 시작하게 된다. 금융치료를 통한 물질적 안정성은 얻었지만 성장성을 잃어가는 느낌이 들어 퇴사를 결심하고, 언젠가 한 번은 도전해보고 싶었던 승무원이 되기 위한 준비를 한다.

그러다 학사시절 존경했던 교수님의 제안으로 대학원을 진학하게 되고, 승무원이 아닌 전공 관련 진로로 다시 돌아와 오●●, 빙●●, 농● 등 모르는 사람이 없는 큰 식품업계의 문을 두드리게 된다. 그러나 탈락의 고배만 무진장 마시게 되고, 외국계 자동차제조회사에 한국 담당자로 채용이 되었지만 코로나로 인해 출국이 불가해지고 채용확정은 무기한 연장이 되어버린다. 

 

이때, 지인을 통해 기획이 무엇인지도 제대로 정의되어 있지 않은 상태로 에듀테크 스타트업에서 신규 플랫폼을 기획해야 한다는 제안을 받게 된다. 신설 부서의 첫 서비스 기획자로 무엇이 올바른 방향인지에 대한 확실성이 없는 상태로 무작정 여기저기 부딪히며 적응을 해가던 중, 대표님이 기획의 방향성 알려줄 수 있는 사수가 아닌 책을 한 권 쥐어주셨고, 나는 이 책을 통해서 조금이나마 서비스 기획에 가까운 업무를 하나둘 배워나간다.

하지만 책은 직접적인 피드백을 해줄 수 없었기에... 나는 기획이 아닌 타 부서의 상사분들께 귀찮을 정도로 끊임없이 질문하고 피드백받기를 반복했고 이를 통해 나만의 방식을 갖춘 기획을 하게 된다. 그렇게 나는 에듀테크 스타트업의 3년 차 서비스 기획자로 성장하게 되었다.

 

그런데 지금의 나는 패스트캠퍼스 X 야놀자의 PM부트캠프에 열심히 참여하고 있다. 왜 지금의 선택을 했냐고 물어온다면... 
시간이 지나면 지날수록 서비스 기획이란 업무에 대한 정체성 혼란이 오게 되었고, 인정욕구에 휘둘려 내가 목표하던 바를 잊어버리기 전에 일(커리어)이라는 녀석과 잠시 떨어져 있기로 마음을 먹었기 때문이다. 그리고 다시 무의 상태로 돌아와 서비스 기획에 대한 지식과 배움을 하나둘 새롭게 채워가기 위함이다.

 

 

---

 

 

마지막으로 서비스 기획에 관심이 있거나 해당 직무로 취업을 희망하는 분들에게 나의 사수를 소개하고 마무리를 하려 한다. 

 

서비스 기획 스쿨 - 도그냥

 

나를 스타트업에서 살아남을 수 있게, 그리고 서비스 기획자로서 성장할 수 있게 해 주었던 기획 바이블! 

 

이 책 한 권 속에는 실제 회사에서 진행되는 서비스 기획의 업무 순서가 그대로 담겨있고, 기획에 대한 베이스가 아예 없는 사람도 이해하기 쉽게 설명이 되어있다. 전체 내용을 요약해놓은 이 글을 읽어보고, 웬만하면 직접 구매해서 읽은 후 실전에서 경험하며 체득하여 본인의 것으로 만들어보기를 추천한다.

 

 

 

+) 추가로 도그냥님이 운영하는 브런치 글도 읽어보는 것을 추천

도그냥의 브런치스토리

 

---

 

서비스 기획

서비스 기획은 아이디어를 통해 고객에게 제공할 하나의 서비스 또는 제품으로 만들어가는 과정이며, 다른 말로는 비즈니스의 요구사항과 소비자 및 트렌드를 반영해 제품이나 서비스를 설계하는 일라고 할 수 있다. 

 

 

채용공고를 통해 서비스 기획자는 어떤 일을 하는 사람인지 살펴보자. 

- 사용자 경험 개선과 서비스 지표향상을 위한 고민을 하는 사람

- App/Web 프로덕트 기능 정의, 화면 및 UX설계, 정책 수립을 하는 사람

- 데이터 분석을 통한 인사이트 발굴 및 이를 활용한 다양한 개선 과제를 수행하는 사람

- 문제를 해결하기 위해 다양한 관점으로 대안을 발산하고, 최적의 해결책으로 수렴하여 실행할 수 있는 사람 

- 사용자 관점에서 어떤 것을 궁금해하고 좋아할지 생각하고 이를 실제로 구현(기획)하는 것이 즐거운 사람

- 스스로 문제를 해결하고, 해결책을 고민하고, 여러 아이디어를 낼 수 있는 사람 

 

위 공고를 종합해보면 서비스 기획자는 사용자의 경험 개선을 위해 문제를 정의하고 이를 해결하기 인사이트를 발굴하고, 최적의 해결책을 마련할 수 있는 사람이라고 정의할 수 있다.

 

 

 

이처럼 사용자의 경험 개선을 위해 문제를 정의하는 단계부터 해결책을 마련하기까지의 업무 프로세스에 대해서 살펴보자. 

 

출처 : 한번에 끝내는 서비스 기획의 모든 것 초격차 패키지

 

(1) 리서치/분석 

서비스를 기획하기에 앞서 리서치는 가장 중요한 단계이다. 어떤 서비스를 만들어야 할지 문제를 정의하는 과정에서 리서치를 통해 논리적인 근거를 마련하고, 이를 통해 기존에는 알 수 없었던 새로운 인사이트를 도출할 수 있기 때문이다. 고객이 어떤 문제로 불편을 경험하는지 발견하고, 그것을 해결할 수 있는 서비스를 만들기 위한 첫 단계이다.

UX 리서치의 필요성
- 내가 생각했던 문제는 문제가 아닐 수 있기 때문
- 리서치 없이 디자인을 할 경우, 사용자들의 맥락이나 행동을 무시하게 될 수도 있음
- 정량적 리서치도 필요하지만 데이터가 모든 것을 말해주지 않으므로 정성적 리서치도 필요함

 

• 사용자 조사(고객의 니즈 파악)
  - 온라인 커뮤니티 : 카페나 SNS를 통해서 다양한 사람들의 의견을 들을 수 있음
  - 설문조사 : 원하는 데이터를 쉽게 다수의 사람에게서 얻을 수 있음 
  - 이해관계자 또는 사용자인터뷰 : 시간이 많이 소요될 수는 있지만 가장 깊이 있는 정보를 얻을 수 있음   
  
• 시장조사 및 벤치마킹
  - 구글 검색 : 모든 정보를 보유하고 있는 검색채널로 시장조사를 진행할 때 가장 먼저 사용하기 좋음
  - 뉴스 또는 논문조사 : 신뢰성을 기반으로 한 자료이므로 근거로 제시하기 좋음
  - 직접 사용 : 타사의 서비스를 유저의 입장에서 직접 사용해보며 인사이트를 얻을 수 있음

 

(2) 요구사항 정의

리서치를 기반으로 제품의 비전과 전략을 정의하고, 제품을 구현하는데 필요한 기능을 분석정리하여 프로젝트를 마무리 하는 단계까지 지속적으로 관리해야합니다. 요구사항 정의를 통해 디자인 단계에서 제품이 사용자 요구 사항을 충족하는지 확인할 수 있고, 개발 단계에서는 기능의 목적과 구현을 테스트할 수 있으며, 출시단계에서는 시장에 사용자의 요구사항이 충족하는지를 확인할 수 있습니다.

* 요구사항 정의서(PRD, Product Requirements Document) 
- 제품을 만들거나 업데이트 하기 위해 기능을 기획하는 단계에서 요구사항을 개괄적으로 설명하는 문서
- 각 이해관계자들의 관점 차이를 해소하고 기획한 의도 및 주요기능을 유관부서 등에게 명확하게 전달하는 문서

 

• 요구사항 정의서 구성요소 
  - 요구사항 구분 : 웹사이트와 앱, 그리고 관리자 페이지를 모두 구축해야하는 프로젝트일 경우 구분이 필요함
  - 요구사항 ID : 화면설계서를 작성할때 화면별 ID를 부여하는 것처럼 요구사항 또한 관리를 위해 ID를 부여함
  - 요구사항 명 : 요구사항을 요약하여 키워드 형태로 기재
  - 요구사항 상세 설명 : 요구사항에 대한 상세 내용을 기재하고, 자세하게 작성하는 것이 좋음 
  - 요청자(부서) : 요구사항을 요청한 사람의 정보를 기재하고, 여러 부서 담당자들이 요청을 할 경우 부서명과 함께 기재
  - 중요도 : 개발 우선순위 파악을 위해 요구사항의 중요도를 표기할 수 있음 
  

+) 요구사항 정의서가 더 궁금하다면 아래의 브런치를 참고하는 것을 추천

웹 기획 산출물 :: 요구사항 정의서 작성하기

 

(3) 기획 문서 작성

요구사항 정의서를 바탕으로 제품 또는 서비스 구현을 위한 각종 기획 문서를 작성하는 단계이다.

• IA(Information Architecture) 작성 
  - 서비스 구축 시 기본 설계 구조도이며, 일종의 사이트맵 형식을 구체화한 문서
  - 서비스의 기능들의 구성형태와 화면 상하구조(헤더/푸터) 파악에 도움을 줄 수 있음
  
  
• 와이어프레임(Wireframe) 작성
  - 앱/웹 서비스를 만들때 동성, 구조를 제안하기 위한 화면 설계도
  - 디자인 요소가 들어가기 보다는 선(Wire)을 이용해 윤곽(Frame)을 잡는 것을 말함
  - 기획자의 요구사항, 서비스의 기능요소를 모두 파악하여 전략적으로 설계해야 함
  - 디자이너, 개발자등 협업을 위한 의사소통 수단이라고 할 수 있음

* 프로토타입(Prototype)
- 본격적으로 개발에 들어가기 전, UI/UX 상호작용을 시뮬레이션 하기 위해 동적으로 만드는 모형
- 정적인 화면으로 설계된 와이어프레임보다, 사용자들의 경험에 대한 테스트를 진행해 볼 수 있음

 

• 스토리보드 작성
  - 일반적으로 기획서라고 칭하는 문서로 서비스 기획 문서의 최종 산출물을 말함
  - 최종적으로 유관부서에게 공유하는 문서 
  - 스토리보드 = 상세기획서 = 화면설계서 
  
  <구성요소>
  ① 서비스 개요 : 목표 및 주요기능
  ② 서비스 구성 : IA, 서비스 정책, 주요 서비스 프로세스
  ③ 상세 기획 : 화면 시나리오, 화면별 와이어프레임(+기능 상세설명)  
  

웹/앱 설계의 기본, 화면설계서(스토리보드) 작성방법 - 기획자 데이먼

 

• WBS(Work Breakdown Structure) 작성
  - 프로젝트를 효율적으로 진행하기 위해 업무 일정을 계획하고 관리할 수 있는 기초 문서
  - 프로젝트 전체 업무를 더 작고 관리하기 쉬운 작은 요소로 세분화하는 단계
  - 작성 목적
  ① 효율적인 업무수행
  ② 작업의 책임과 역할 명확화
  ③ 작업 진척 모니터링

 

(4) 유관부서 리뷰

본격적인 작업을 진행하기에 앞서 기획 문서를 바탕으로 협업하게 될 유관부서들의 리뷰를 듣는 단계이다. 디자인, 개발, 마케팅, QA팀의 리뷰를 통해 개발을 진행하면서 발생할 수 있는 리스크들을 미리 확인하고, 제거 또는 개선할 수 있다.

 

(5) 디자인/개발진행

기획단계 이후 스토리보드(화면설계서)를 바탕으로 디자인과 개발 작업이 진행되게 되며, 이 단계에서 기획자는 기획방향대로 잘 진행되고 있는지 체크를 해야한다.

 

(6) 취약점 점검

제품 또는 서비스가 보안적으로 안전한지 확인해야하며, 해킹의 위험은 없는지 정보탈취 가능성은 없는지 등을 정보보안팀에서 확인하게 된다. 

 

(7) QA(Quality Assurance)

일정한 효율과 품질이 보장되어야 하는 활동을 뜻하며, 개발 완료 후 서비스가 오픈되기 전에 안정적으로 작동되는지 문제가 될 만한 사항은 없는지 등을 살펴보는 단계이다. 서비스의 정책이나 시나리오를 바탕으로 서비스의 무결성을 위해 진행되는 단계로 볼 수 있고, QA팀이 있다면 QA팀에서 진행하겠지만 보통은 서비스 기획자 또는 PM이 진행하는 경우가 대부분이다

* QA 프로세스
기획서 분석 → 테스트 범위 설정(단말기 등) → 테스트 케이스 검토 및 작성 → 테스트 진행(버그 리포트) → 최종 테스트 진행 → 결과리포트 작성

 

• 테스트 케이스(Test Case) 작성- 개발완료 후 제품이 기획한 시나리오대로 작동하는지 확인하기 위해, 테스트 목적과 조건 그리고 입력값에 따른 예상결과와 같은 내용을 작성해야 한다.

테스트케이스 예시 - 작성자

 

+) 테스트 케이스가 더 궁금하다면 아래의 브런치를 참고하는 것을 추천

테스트 케이스(TC)로 QA 하기

 

(8) 배포/오픈 

배포를 통해 서비스를 모니터링하고, 지표를 관리하며 서비스가 정상적으로 작동하는지 확인할 수 있다.

• 서비스 오픈 전 단계
  - 최종 QA 및 테스트 결과 확인
  - 서버, 앱 배포일정, 배포 시나리오 확인
  - 마케팅/프로모션 확인
  - 고객센터 및 유관부서 업무메뉴얼 작성 및 서비스 공유 오픈
  
  
• 오픈 당일
  - 오픈 이후 운영환경에서 테스트 진행 및 모니터링

 

• 오픈 이후 
  - 고객센터, 앱스토어 리뷰 등에 올라오는 CS 대응 및 개선포인트 찾기
  - 지속적인 서비스 로그 모니터링 
  - 일별/주별/월별 등 지표 분석