by
May 05. 2024
5. 서비스 기획자의 기획서
기획서의 종류, 작성 팁과 샘플
지식 공유를 위해 경험과 자료를 정리하며 작성한 글이다.
이번 글에선 아래 내용을 확인할 수 있다.
1. 기획서의 개념
2. 상위 기획서와 하위 기획서
3. 상위 기획서에 담기는 내용들
4. 하위 기획서에 담기는 내용들
목차
개요
PM/서비스 기획자에게 기획서란
상위 기획서에 포함되는 내용들
하위 기획서에 포함되는 내용들
이모저모
레퍼런스
개요
IT 업계든 아니든, 기획자든 아니든 우리는 기획서를 작성할 때가 있다. 때론 전략을 포함하고, 때론 설계서로 만들기도 한다.
기획서란 무엇일까? 말 그대로 기획한 내용을 문서로 작성한 것을 의미한다. 이를 위해 '기획'의 의미를 먼저 돌아보자. 앞서 작성한 글에서 기획을 아래와 같이 정의했다.
어떠한 산출물(Output)을 말한다기보다, 특정 상황에 적합한 구체적인 해결책을 만들거나 재구성하는 ‘목표 지향적인 행동’
그러면 기획서는 어떤 의미를 가질까? 기획한 내용을 문서로 정리하는 이유는 간단하다. 누군가에게 정보를 전달하기 위함이다. 기획서는 의사소통을 위한 수단이다. 기획서는 기획자의 의도를 독자에게 명확하게 전달할 수 있어야 한다. 그래서 기획서는 사용되는 곳에 따라 특정한 목적을 띄고 있다. 궁금하다면 시중에 공유되는 마케팅 기획서, 사업 기획서, 서비스 기획서를 찾아보자.
PM/서비스 기획자에게 기획서란
기획자는 다수를 상대할 일이 많다. 조직의 로드맵을 달성하거나 요구사항을 정의하기 위해 경영진, 제품 책임자, 사업부와 논의한다. 또한 제품이나 기능을 만들기 위해 디자이너, 개발자, 운영자를 설득한다. 이때 기획자가 다수를 설득하기 위해 작성하는 문서가 기획서다.
PM의 관점에서 기획서를 크게 두 종류로 나눌 수 있다.
1. 상위 기획서
조직의 장기 목표, 이니셔티브, 비즈니스의 전략적 목표와의 연계에 중점을 두고 전략에 대한 광범위한 개요를 제공한다. 자세한 내용은 시니어 기획자, 김광섭님께서 작성한 글을 읽어보자.
https://brunch.co.kr/@supernova9/225#comments
2. 하위 기획서
(a.k.a 상세 기획서, 서비스 기획서)
상세하고 구체적인 기획서다. PM이라면 보편적으로 기능을 개선하거나, 개발하는 ‘프로젝트 단위’의 기획서를 만들 것이다. 프로젝트의 목적과 목표, 타깃 고객과 정의한 문제, 가설과 검증 지표, 유저 스토리, 정책, 화면 설계서, 체크 리스트 등 제품을 만드는 실무자가 알아야 하는 정보부터 WBS, 리스크, 백업 방안 등 프로젝트를 관리하기 위한 수단이 포함된다. (앞으로 다룰 글은 이와 더 관련 있다.)
둘을 하나로 합쳐서 적든 분리해 적든 그것은 조직과 개인의 성향에 따라 다르다. 다만 기획서는 ‘명확한 의사전달을 위한 도구’ 임을 잊지 말자. 명확하게 이해를 시키려면? 간결할수록 좋다. 작문 능력은 필수!
상위 기획서에 포함되는 내용들
상위 기획서에는 보편적으로 몇 가지 주요 결과물이 포함된다:
개요 및 배경: 프로젝트의 개요, 진행 배경
전략적 목표: 조직의 비즈니스 목표를 연결하는 명확하게 정의된 목표
예산 및 리소스: 프로젝트를 진행하기 위해 필요한 리소스
리스크 관리 전략: 잠재적인 리스크와 백업안
이해관계자 분석: 주요 이해관계자와 그들의 역할, 이해관계, 기대치
성과 지표: 성과를 평가하기 위한 기준 및 지표(마일스톤, KPI 등)
경험상 PPT, 워드로 만든 기획서를 많이 봤다. 필자의 경우 피그마로 만들어 공유하고, 필요하면 PDF로 내보낸 다음 공유하는 편.
프로젝트 차터, 원 페이저, 아마존 6 페이저 같은 프레임워크를 활용하는 방법도 있으며, 컨플루언스, 노션 같은 툴로 공유할 수도 있다.
어떤 방법이나 툴을 쓰든 조직과 기획서의 타깃이 쉽게 수용할 수 있는 것을 쓰는 게 좋다.
예전에 작성한 프로젝트 차터 샘플 ⓒ 327roy하위 기획서에 포함되는 내용들
조직의 목표, 혹은 특정 프로젝트의 목표를 달성하기 위한 구체적인 작업을 명시한다. PM 관점에서 일반적으로 다음 내용을 담는다:
목적과 목표
타깃 고객과 정의한 문제
가설과 검증 지표
도식(플로우 차트 등)
유저 스토리: 유저 스토리는 인수조건으로 사용하는 걸 고려해서 작성하는 편
정책: 서비스(기능)의 큰 골자가 되는 정책
화면 설계서: 와이어 프레임/디자인된 화면과 화면 구성 요소의 상세한 정책
체크 리스트
WBS(Work Breakdown Structure): 리소스, 일정 등 프로젝트 관리를 위한 업무 분류 체계
리스크: 프로젝트 진행 시 예상되는 리스크
백업 방안: 프로젝트가 위험에 쳐했을 때 고려할 수 있는 백업 방안
나는 보통 하위 기획서(상세 기획서)를 컨플루언스로 작성한다. 지라로 프로젝트를 관리하기 때문에 연동할 때 편하기도 하고, 텍스트 검색이 가능하기 때문이다.
하위 기획서 샘플 ⓒ 327roy요즘엔 피그마로 '기획서 키트'를 만들어 테스트 중이다. 기획서에 들어갈만한 요소(속성)를 컴포넌트화하고, 오토 레이아웃을 사용해 템플릿처럼 사용하는 형태다. 피그마 팀 라이브러리를 활용할 수 있고 구성원이 피그마를 일정 수준 이상 활용할 수 있어야 한다는 과제가 있다.
이모저모
기획서, 화면 설계서, 티켓이 파편화돼요.
실무를 하다 보면 디자인 및 화면 설계서(피그마), 기획서(컨플루언스), 프로젝트 관리(지라)로 산출물이 파편화되곤 한다. 최악의 상황은 실무자가 필요한 정보가 생겼는데 메신저를 뒤져봐야 하는 것.
그래서 제품 개발과 관련된 모든 자료를 개발 목표를 의미하는 지라의 티켓에 첨부하고, 이를 팀원에게 학습시키는 편이다.(보통 '에픽' 타입 이슈를 활용한다.) 피그마에 화면 설계서를 만든다면 그 옆에 지라 위젯을 사용해 티켓을 첨부하고, 지라 티켓엔 화면 설계서 등 관련 문서를 모두 링크한다.
지라 위젯과 화면 설계서 샘플 ⓒ 327roy