프로덕트 관련 콘텐츠를 만드는 일을 하다보니, 기획자가 작성한 문서들을 접할 기회가 많다.
Wiki에 층층히 쌓여 있는 문서들을 들여다보고 있자면, 기획자라는 직무가 단순히 창의력과 추진력이 전부라고 생각했던 나의 무지함이 부끄러워지곤 한다.
기획자는 하나의 서비스를 기획하고 출시하는 모든 과정에서 끊임없이 글로 소통하는 직무이다.
오늘은 기획자에게 왜 글쓰기 역량이 중요하고, 어떤 산출물을 만들어내야하는 지를 실무 기획자 모준승 님의 "기획자의 글쓰기" (위키북스, 2021년)라는 책의 내용을 빌려 소개해보도록 하겠다.
서비스 기획자에게 글쓰기가 중요한 이유
서비스 기획자에게 글쓰기란 굉장히 중요한 자질이다. 일의 모든 면면에서 글쓰기 작업이 필수적으로 들어가기 때문이다.
서비스 기획자의 기획물이 현실화되려면 기획안을 실제로 구현해줄 다른 사람들(개발자, 디자이너 등)의 도움이 필요한데, 이 설득/소통의 토대이자 수단이 바로 기획자가 작성한 문서이다. 서비스 기획안, 유관 부서와의 회의록, 정책서 등 결국 '문서'를 통해 소통하고 소통의 결과 또한 '문서'가 되어 기록으로 남는다. 이 모든 문서화 작업이 결국 기획자의 몫이기 때문에, 기획자에게 다른 사람이 이해하기 쉽게 글을 잘 작성하는 능력은 매우 중요하다.
서비스 기획 산출물 종류
그렇다면 실제로 서비스 기획자들은 어떤 문서를 작성하게 될까? 서비스 기획 프로세스를 따라가며, 각 과정에서 필요한 산출물들을 알아보자.
* 물론 실제로는 기업마다 각기 다른 프로세스와 문서 양식을 사용할 것이고, 많은 부분이 간소화될 것이다. 그러나 일단 정직하게! 책에 나온 내용을 바탕으로 full로 작성해보았다.
📌 서비스 기획 프로세스
1. 문제 정의 > 2. 요구사항 정의 > 3. 기획 정책 수립 > 4. 기능 정의 > 5. IA/순서도(flowchart) 작성 > 6. 와이어프레임 작성 > 7. 화면설계서 작성 > 8. 서비스 운영 정책서/매뉴얼 수립
1. 문제 정의
어떤 문제를 해결할 지 결정하는 작업이다. 산적해있는 문제들을 모두 해결하면 좋겠지만, 조직은 언제나 리소스가 부족하기 때문에 기획자는 매번 선택의 기로에 서게 된다.
이렇게, 앞으로 개발해야하는 기능 또는 제품에서 요구하는 기능 목록을 백로그(backlog)라고 한다. 한정된 리소스로 최선의 결과를 이끌어내기 위해, 팀 내에서 주기적으로 백로그 과제들을 논의하는 과정을 거치고, 이 중 우선순위가 높은 과제들을 개발 과제로 선정하게 된다.
우선순위를 선정하기 위해서는 다음 두가지 방법을 주로 이용한다. 영어를 읽어보면 의미가 쉽게 파악되므로 설명은 생략 😀
1) MosCow 방법(Must have, Should have, Could have, Won't have)
2) RICE 방법 (Reach, Impact, Confidence, Effort)
2. 요구 사항 정의
해결할 문제를 정의했다면, 이제 문제를 해결하기 위한 방법(=기능)을 정리해야한다.
어떤 기능으로 문제를 해결할 수 있을 지, 해당 기능이 어떻게 문제를 해결할 수 있을 지 정리한다.
다음과 같은 문서를 바탕으로 디자이너 및 개발자와 미팅을 가지며, 실제 구현 가능한 요인들을 협의하게 된다.
1) 제품 사양 문서 (Product Specification, Product spec)/제품 요구사항 정의서 (Product Requirement Document, PRD): '어떤 제품을 왜 만들 것인지', '어떤 기능을 왜 만들 것인지'를 정의하는 것으로, 제품의 목표, 타깃 유저, 세부 내용을 전달한다.
2) 요구사항 정의서(SW Requirement Specification): 어떤 기능이 필요하고, 왜 필요한 지, 각 기능에는 어떤 내용(데이터)이 노출되는 지 담은 문서이다. 이를 토대로 개발자/디자이너는 해야할 작업과 필요한 리소스를 예측할 수 있다.
3. 기획 정책 수립
본격적인 개발을 착수하기 앞서, 공통적으로 사용할 용어와 정책을 정의하는 단계이다. 회원에 대한 정의나 상품 판매, 결제 및 환불에 관한 규정처럼 서비스에 공통적으로 적용되는 사항이 있을 수 있다.
이렇게 공통 정책을 먼저 정리하면, 개발팀에서는 DB 설계나 관련 기술 검토 등을 진행할 수 있게 되고 실제 개발에 투입되는 시간을 상당 부분 줄일 수 있다.
4. 기능 정의
요구사항정의서를 통해 실제 구현이 가능한 개발 요건을 파악했다면, 이제 해당 요구사항을 보다 구체화하는 작업이 필요하다. 각 기능의 구성요소를 정리하고, 구성요소가 어떻게 동작하는 지, 어떤 데이터를 입력하는 지 등의 로직을 정리한다.
1) 기능 정의서: 각 요구사항을 기능 단위로 쪼개 각 기능을 정의하고 동작을 설명함으로써 기능을 구체적으로 어떻게 구현해야하는지 설명하는 문서이다.
5. IA/순서도
기능 정의가 각 기능을 개별적으로 파악하기 위한 것이라면, IA/순서도는 전체 구조를 파악하기 위해 작성하는 문서이다. 개발자/디자이너가 작업하기 앞서, 서비스의 구조를 한 눈에 이해하기 쉽게 도와준다.
1) IA(Information Architecture, 정보구조도): 트리 형태로 웹 사이트의 메뉴 구조를 표현한 문서이다.
2) 순서도(flowchart, 화면흐름도): 어떤 기능의 처음부터 끝까지를 한 번에 볼 수 있도록, 프로세스를 기호/도형으로 도식화한 문서이다.
6. 와이어프레임
기획자의 머릿속에 존재하던 이미지를 간단하게 그려서 보여주는 작업이다. 기획자가 작성한 와이어프레임을 토대로 디자이너는 디자인 작업을 진행한다.
1) 와이어프레임(Wireframe): 점과 선 등을 활용해 화면을 간략하게 표현한 문서이다. 주로, Figma, Adobe XD, Sketch 등의 툴을 이용한다.
7. 화면 설계서
제품 개발을 위한 최종 기획 산출물을 작성하는 단계이다. 개발자는 디자이너가 작업한 디자인 화면과 기능 정의 문서를 보고 실제 개발에 착수한다.
1) 화면설계서: 와이어프레임와 기능 정의서를 합친 것으로, 화면에 존재하는 각 컴포넌트를 분리하고 이를 description에서 설명한다.
8. 서비스 운영정책서/매뉴얼
서비스가 오픈되고 나서, 실제로 서비스를 운영해야하는 마케팅팀, CS팀 등의 내부 직원들을 위한 문서이다.
1) 서비스 정책서: 서비스 개념/서비스 범위/서비스 구조 등을 정의한 문서이다.
ex) 회원 정책, 주요 용어, 주요 기능, 상품 정책, 환불 정책 등
2) 운영 정책서: 서비스 운영 시 필요한 기준과 규칙을 정리한 문서이다.
ex) 고객 문의, 환불 프로세스, 개인정보 파기 프로세스
3) 서비스 운영 매뉴얼: 서비스의 개요와 주요 기능과 사용법 등을 설명한 문서이다.
출처: [기획자의 글쓰기- 모준승, 위키북스, 2021년 11월 10일 ]
'IT Note > IT Basics' 카테고리의 다른 글
| [1분 IT] DevOps란 무엇일까? (0) | 2022.12.14 |
|---|---|
| 트렌드 겉핥기에 지친 자를 위한 100년 IT 과거와 현재 -1. 컴퓨팅 (0) | 2022.09.30 |
| [IT샐러드] 문과생을 위한 HTTP통신, 쿠키, 세션, 토큰, 인증, 인가 이해하기 (0) | 2022.01.24 |
| [IT샐러드] 스타트업 업무 용어 정리 2탄 - 개발 프로세스 편 (0) | 2021.11.30 |
| [IT샐러드] 스타트업 업무 용어 정리 1탄 - 업무 문화 편 (0) | 2021.08.28 |
