나의 상위 기획서 작성방법
큰 규모의 프로젝트를 처음 시작할 때 어떻게 접근해야 할까?
이전 글: 데이터를 보여주는 방법
다음 글:
Intro
기획자와 PM은 항상 새로운 프로젝트를 시작할 때 팀원들이 한 방향을 바라볼 수 있게 이끌어야 합니다.
저는 프로젝트의 첫 미팅을 진행할 때 상위 기획서를 작성하여 회의에 참여합니다. 회의에서는 프로젝트의 목적과 방향성을 명확히 하고, 각자의 역할을 빠르게 이해할 수 있도록 정리합니다.
이번 글에서는 프로젝트를 시작할 때, 제가 어떻게 상위 기획서를 작성하고 공유하는지에 대해 이야기하려고 합니다.
상위 기획서란?
이 글에서 제가 말씀드리고 싶은 상위 기획서란,
프로젝트에 참여하는 모든 사람이 같은 방향을 바라볼 수 있도록 안내해 주는 핵심 기획서입니다.
기획서에 정해진 형식은 없으며, 상황에 따라 문서가 될 수도 있고, PPT의 형식이 될 수도 있습니다.
저는 소규모 프로젝트는 1 Pager의 형태로 핵심 내용을 간단히 정리하고, 규모가 어느 정도 있는 프로젝트는 PPT를 활용하여 단계별로 정리합니다.
상위 기획서는 프로젝트에 참여하는 모든 사람들이 보는 문서인 만큼,
모든 내용을 상세히 정리하는 것보다 모두가 쉽게 이해할 수 있게 작성하는 것이 중요하다고 생각합니다.
저는 1 Pager는 Notion 또는 Confluence로 PPT는 피그마로 작성합니다.
이번 글에서는 제가 PPT를 활용해 상위 기획서를 작성하는 방법에 대해 공유드리겠습니다.
작성 프로세스
1. Project Overview(프로젝트 개요)
이번에 다룰 프로젝트가 어떤 것인지, 프로젝트가 왜 시작하게 되었는지 소개하는 단계입니다.
Project Overview 예시(1). 개요
- 프로젝트를 요약하여 한 줄로 소개하는 것입니다.
구체적인 내용이 있다면 그 내용을, 추상적이라면 목표와 방향성을 함께 작성합니다.
e.g.
- 멤버십 구조 개선 프로젝트
- Retention 주기 단축을 위한 결제 페이지 개선 프로젝트 등
(2). 배경
- 프로젝트가 시작된 배경을 설명하는 것입니다.
프로젝트가 시작된 이유를 모두가 이해하기 쉽게 정리하는 것이 중요합니다. 또한, 특정 문제를 탐색하기로 했다면, 문제 탐색을 시작하게 된 사유를 알려주어도 괜찮습니다.
e.g.
- 지속적인 Retention 비율 감소로 인한 대응 전략 필요
- 고객 서베이 결과 결제 단계에서의 불편 확인 등
*프로젝트 개요 단계에서는 모든 참석자가 이번 프로젝트의 맥락과 목적을 명확히 이해하고 공감할 수 있도록 하는 것이 중요합니다.
2. Discovery(탐색)
이 단계에서는 프로젝트의 배경을 기반으로 시장 조사, 요구사항 분석, 데이터 분석 등을 수행합니다. 이를 통해 근본적인 문제를 파악하거나 추측하고, 문제에 대한 프로젝트 목표를 설정합니다.
Discovery(문제 분석) 예시(1). 문제 분석
- 프로젝트 배경에서 도출된 문제들이 진짜 중요한 문제인지, 근본적인 문제가 숨어 있지는 않은지 탐색하는 단계입니다.
문제 탐색에는 정해진 방법이 없으며, 상황에 따라 가장 적합한 방식을 선택해 진행합니다.
e.g.
- 사용자 인터뷰를 진행하고 그 요구사항을 분석해 근본적인 문제를 찾거나,
- 내부 또는 외부 데이터를 활용해 가장 가능성이 높은 문제를 추론합니다.
(2). 문제 정의
-해결해야 하는 프로젝트의 핵심 문제들입니다.
문제 분석 결과를 바탕으로 근본적인 문제라고 생각하는 것들을 정리하는 단계입니다. 문제 정의는 앞서 진행한 문제 분석과 논리적인 일관성이 있어야 합니다. 따라서, 새로운 내용이 문제 정의 단계에서 나와서는 안됩니다.
e.g.
- 예상치 못한 비용: 00으로 인해 A화면에서 확인된 가격과 B화면의 가격이 다름
- 불편한 00 UX:A 화면의 00 과정에서 사용자에게 수동 입력을 요구하는 불편한 UX가 제공되고 있음 등
(3). 목표
- 정의한 문제를 해결하기 위한 프로젝트의 목표입니다.
목표는 정의한 모든 문제를 포괄하고 있어야 합니다. 만약 목표를 달성한 후에도 해결되지 않은 문제가 있다면, 목표를 다시 검토해야 합니다.
e.g.
- 일관성 있는 가격 구조 개선
- 편리한 00 UX 제공
*탐색 단계는 문제를 정의하기까지 거쳤던 탐색 과정을 논리적이고 명확하게 표현하며 문제와 목표를 맥락에 맞게 연결하는 것이 중요합니다.
3. Solution(해결 방안)
정의된 문제를 바탕으로, 프로젝트의 세부적인 해결 방안을 제시하는 단계입니다.
Solution(해결 방안) 예시(-). 솔루션
- 목표 달성을 위한 구체적인 실행 계획입니다.
솔루션 또한 문제 탐색과 마찬가지로 정해진 형식이 없습니다. 중요한 것은 목표를 어떻게 달성할 것인지 명확히 하는 것입니다. 개발할 기능을 키워드 중심으로 간략히 정리하거나, 메뉴 구조도나 플로우 차트와 같이 시각적으로 구조화해도 괜찮습니다.
e.g.
- A화면의 00 기능 계산: A화면에서 00 표시
- 고객 세그먼트별 00 진행: B문제가 있다고 판단되는 유저들을 대상으로 00 진행
*솔루션에서는 자신이 세운 계획의 성과를 어떻게 측정할 것인지, 이 성과가 어떻게 목표 달성으로 이어지는지도 함께 고민해 보는 것이 중요합니다.(다만, 상위 기획 단계기 때문에 엄청 구체적이지 않아도 괜찮습니다.)
4. Road Map(로드맵)
프로젝트 목표 달성을 위한 주요 일정과 각 단계별 과업을 시각적으로 정리하는 단계입니다.
Road Map 예시(-). 로드맵
- 프로젝트의 진행 계획을 시각적으로 정리한 것입니다.
로드맵은 프로젝트 시작부터 끝까지 어떻게 관리할 것인지 이해하기 쉽게 보여주는 것이 중요합니다. 따라서, 각 파트의 역할과 프로젝트의 흐름을 한눈에 파악할 수 있도록 정리해야 합니다.
*하지만 꼭 기간을 명확히 제시하지 않아도 괜찮습니다. 각 업무의 진행 순서를 단계별로 정리하는 것이 중요합니다.(Phase, Step과 같은 용어를 사용하여 어떤 것부터 하나씩 관리할 것인지 정리)
마무리
프로젝트의 로드맵까지 진행하였다면, 각 담당자들이 앞으로 어떤 것들을 해야 할지 명확히 짚어주는 것이 중요합니다. 각 프로젝트의 담당자들이 검토해야 할 항목에 대한 Check list를 작성하고 이를 공유하며 마무리합니다.
프로젝트의 개요부터 로드맵까지 전반적인 과정을 살펴보았습니다. 프로젝트는 항상 다양한 상황과 맥락 속에서 진행됩니다. 따라서 늘 정해진 형식과 틀을 사용할 수 없습니다. 저 역시 매번 유사하면서도 조금씩 달라지는 기획서를 작성하며 프로젝트를 관리해 왔습니다.
항상 수많은 변수가 존재하기 때문에 이를 최소화하기 위해, 우리가 프로젝트를 왜 시작했고 무엇을 어떤 방식으로 진행할 것이며 앞으로 어떤 것들을 할 것인지 명확하게 전달하는 것이 중요합니다.
감사합니다. :)
