brunch

You can make anything
by writing

C.S.Lewis

by 위태한개츠비 Apr 04. 2020

기획서 쓰기

지극히 주관적인 기획 문서 쓰기 요령

기획안을 사람들 앞에서 발표하면서 얼굴이 붉어진 경험, 누구나 한 번쯤은 있을 것이다. 생각하지 못한 내용에 대한 공격, 이미 알고 있지만 대응책이 마땅히 없는 항목에 대해서 누군가 지적할 때, 준비가 부족하다고 느끼는 경우 등 여러 상황이 있다. 하지만 내가 만든 기획서를 누군가 앞에서 발표할 때 긴장감보다 발표 과정을 통해 사람들을 내가 원하는 방향으로 끌고 가는 희열은 훨씬 크다. 기획이란 게 원하는 방향으로 끌고 가는 것인데, 문서작성과 발표도 마찬가지 기획의 영역 중 하나라 생각한다.

누군가의 기획서를 볼 때 눈에 너무 잘 들어오고, 무엇이 중요하고 무엇을 의도한 지 명확히 파악되는 게 있는가 하면, 도저히 봐도 무슨 말인지 이해가 안 되는 경우도 있다. 후자의 경우는 문서를 보는 즉시 화가 난다. 기획자는 사용자에 대한 이해가 깊어야 한다. 어떤 상황에서 어떤 흐름으로 제품을 이용하게 되는지를 알고, 그들과 시선을 함께하고 그들을 대변할 수 있어야 한다. 프러덕 태초의 모습인 기획안 문서는 내부 구성원들을 위해 작성한다. 한데 자기 기준에서 자기 생각만 잔뜩 써놓으면 도저히 무슨 이야기를 하는지 알 수가 없다.

하여, '기획서 쓰기'라고 제목은 잡았지만 일반적인 문서 작성 시 주의사항 또는 요령을 지극히 주관적으로 기술하고자 한다.

목적과 대상을 명확히 하자

말로 전달하는 것도 마찬가지지만 모든 일의 시작은 프레이밍이다. 내가 다루고자 하는 주제에 대해서 프레밍이 필요하다. 그래야 효과적으로 이야기의 흐름을 만들어낼 수 있고, 의도한 목적을 이룰 수 있다. 따라서 문서를 작성하기에 앞서 어떤 목적으로, 누구에게 보여주기 위한 것인지 정의하자. 이해관계자들과 단순히 논의를 위한 문서일 수도 있고, 정리된 내용을 바탕으로 Kick-off 하기 위한 내용일 수 있고, 의사결정을 받기 위한 보고 문서일 수 있다. 이 문서를 통해 얻고자 하는 것에 따라 문서의 내용은 달라지게 될 것이다.

한 번은 이런 적이 있다. 개발자를 대상으로 기획안을 리뷰해야 하는데, 어느 주니어 기획자가 개발 항목을 이것저것 방향성 없이 파편적으로 개발자들에게 전달하는 것이다. 그 내용을 본 개발자들은 아직 준비가 덜 됐구나라고 생각하고 그 이후 f/up을 안 하거나, 그래서 뭘 하란 거냐며 반문했는데, 다들 인자한 분들 이어서 표면상에서 문제는 없어 보였지만 그 분위기와 상황을 보니 상당히 난감했고 속상했다. 문서를 보는 사람 입장에서, 그들이 알고 싶어 할 내용들을, 그들의 눈높이와 상황에 맞춰 작성해보자. 잘 모르겠다면 주변 지인들에게 도움을 청하는 것도 좋다. 혼자 품에 안고 속도를 내지 못하는 것보다 주변 사람들의 도움을 받거나 빠르게 피드백을 수렴해서 개선하는 방향이 더 좋다.

프레이밍은 큰 범위에서 작은 범위로,

주요 개념은 반복적으로 설명하자

수학을 참 좋아하는데, 이유는 기본 개념이 탑재되면 이를 활용한 응용이 무궁무진하기 때문이다. 케이스 바이 케이스로 상세 내용들을 설명하는 것은 효율적이지도 않고 듣는 사람의 진을 빼기 쉽다. 따라서 뭔가를 설명하기 위해서는 위에서 언급한 것처럼 프레이밍이 필요하다. 이는 큰 범위에서 작은 범위로 점점 좁힐 필요가 있다. "전체는 이렇지만, 이런 기준으로 우리의 타깃은 이렇게 된다." 식으로 큰 범위에서 작은 범위로 좁혀야 한다. 프레이밍으로 생각의 범위를 좁히고 나면 그 안에서 설계를 진행해야 한다. 설계는 주요 정책은 어떻게 되는지, 전체 흐름/시나리오는 어떻게 되는지 등 큰 범위를 이해할 수 있도록 전체를 설명할 수 있는 내용이 포함되어야 한다. 그 이후 각 흐름별 세부사항들을 기술해야 하는데, 이때 상위 정책과 얼라인을 맞추면서 설명하면 디테일한 내용을 전달하기 쉽다. 그리고 주요한 정책 또는 기능 등은 아무래도 반복적으로 이야기가 나올 수밖에 없다. 인간은 망각의 동물이기 때문이고 듣는 것과 보는 것, 받아들이는 것이 각기 다르기 때문에 지루하지 않은 수준에서의 반복은 좋다.

협업 포인트 또는 논의 포인트를 설명하자

대부분의 문서는 어떤 일을 추진하기 위해 작성이 된다. 문서를 읽고 설명을 듣는 사람들은 그 일을 수행해야 할 사람일 가능성이 높다. 일을 한 팀 또는 한 명이 할 수 없기 때문에 이해관계자들 간의 협업이 필요한 부분 또는 협의가 필요한 부분을 미리 짚어주고, 회의자리에서 Agenda를 던지는 게 좋다. 이런 설명이나 초반의 Initiative가 없는 상태에서 알아서 이해관계자들끼리 논의하겠지 하고 두면 백이면 백 그대로 진행되지 않을 가능성이 높다. 때문에 원활한 업무의 진행을 위해 일의 오너쉽을 가진 문서 작성자가 이해관계자들 간의 협업 포인트 또는 논의 포인트를 짚어주는 것이 효과적이다.

당연한 건 없다.

정말 세상에 당연한 건 없다. 너무나 당연하게 생각했던 기능조차도 말하지 않으면 원치 않은 결과가 만들어지기 쉽다. 때문에 기획자는 본인이 원하는 디테일은 최대한 상세히 전달하고 조율할 필요가 있다. 한데 아직도 많은 사람들이 "당연히 이렇게 돼야 하는 거 아냐?"라고 자신의 책임이 아니라 다른 사람의 책임으로 생각하는 사람도 많다. 원하는 feature를 제대로 설명하지 못한 사람의 잘못이라고 생각한다. 때문에 특히 신경 써야 할 부분들이 있다면 문서에는 최대한 디테일을 살리고, 요구사항을 명확히 할 필요가 있다.

Must have 우선

하고 싶은 게 많을 수 있다. 한데 그중에 반드시 해야만 하는 일은 얼마나 될까? 본인도 이런 요구사항이 왜 나왔는지 정확히 설명 못하면서 요구사항을 줄줄이 늘어놓는 경우도 많다. 마치 세상에 발생 가능한 모든 경우의 수를 나열하는 것 같다. 잊지 말아야 할 것이 있다. 세상의 모든 경우의 수를 생각하고 대응하는 게 일을 잘하는 것이 아니라, 우선순위를 정하고 할 일과 하지 말아야 할 일을 정리하는 것이 더 중요하고 어려운 일인 것임을. 때문에 Must have, Nice to have를 구분하여 함께 설명하는 것도 좋다. 두 구분의 명확한 기준과 납득할 논리는 준비되어야 한다.

정리하면, 문서를 보는 사람에 맞춰서, 그가 듣고 싶어 하는 내용 또는 그가 들어야 할 내용을 눈높이와 이해 수준에 맞춰 정리하면 된다.

끄읏!

keyword