기획서에도 기승전결이 있어야 한다

얼마 전 우리 팀 개발자분에게 기분 좋은 이야기를 들었다.

“다른 회사의 기획자나 PM은 해야 할 업무와 기한만 준다. 그런데 OO님은 기승전결을 갖춰서 목적이나 이유가 무엇인지 등을 설명하고 그다음 업무를 요청한다. 그래서 기획서를 보고 개발하는 입장에서, 이 업무를 왜 해야 하는지 등을 잘 알 수 있는 게 좋다”

‘감사하다’고 하면서 겉으로 티는 크게 내지 않았지만, 속으로는 그 말을 듣고 실제 유저들의 칭찬을 들은 것만큼이나 기분이 정말 좋았다.

혼자서 마케팅을 하다가 일련의 이유로 PM 역할을 맡아 처음으로 조직에서 프로덕트를 이끌며, 구성원들에게 업무를 요청하기 시작한 지 얼마 되지 않았는데, 함께 일하는 구성원에게 긍정적인 피드백을 받으니 기분이 좋을 수밖에 없었다. 물론 개발적 지식, User Flow 그리기 등 배우고 발전해야 할 부분은 아직도 많다.

또한 업무 요청과 팀 리딩에 대해 항상 갖고 있는 신념이 틀리지 않았다는 걸 증명한 느낌이 들었다. 개인적으로 구성원들에게 업무를 요청할 때는 단순히 해야 할 일과 기한만을 제공하는 게 아니라, 목적 및 목표, 업무를 해야 하는 이유와 배경을 제공해야 한다는 신념을 갖고 있다.

단순히 할 일 목록과 기한만 전달하는 Top-Down 방식의 업무 요청은 업무에 대한 구성원들의 의지나 몰입도를 높일 수 없다고 생각하기 때문이다. 어릴 때 특별한 이유를 말해주지 않은 채, 마냥 “공부해”라는 말을 듣는다고 공부가 하고 싶고, 공부에 대한 의지가 높아지지 않는 것과 같다.

업무의 목표, 목적, 배경을 알아야 구성원 스스로가 요청받은 업무를 '내 일'이라고 생각하고 몰입해서 의지를 가지고 업무를 할 수 있다. 그리고 일을 리드하거나 업무를 요청하는 PM의 가장 중요한 일은 구성원들에게 업무의 목표, 목적, 배경을 최대한 잘 이해할 수 있게 전달하는 것이다. 다른 어떤 일보다도 중요하다. 물론 자신이 직접 처리해야 하는 업무를 잘 처리하는 것도 중요하지만, 구성원들을 움직이게 하는 것보다 중요한 건 없다.

그래서 구성원들에게 기획서를 통해서든, 슬랙으로든, 업무를 요청할 때 목적과 배경, 업무 목록 등을 포함해 업무에 대한 기승전결을 논리적이면서 이해하기 쉽게, 전달해야 한다.  위에서 말한 개발자에게 칭찬을 받고, 내가 기획서에 어떤 내용을 적었는지 다시 한번 살펴봤고, 해당 내용을 기승전결의 형식으로 정리했다. 주니어 PM 혹은 이제 막 리드가 된 사람들이 구성원들에게 업무를 더 잘 요청하는 데 도움이 되었으면 좋겠다.

※ PM 역할을 맡은 직후에 쓰기 시작해서 천천히 완성한 글입니다.

기: 목표와 목적

가장 먼저 이번 기획 혹은 업무를 통해 어떤 목적과 목표를 달성할 것인지에 대해 전달해야 한다. 흔히들 목적과 목표를 혼동하기 쉬운데, 목적은 달성하려는 상태이고 목표는 목적을 얼마나 달성했는지 정량적으로 나타낼 수 있는 수치이다. 쉬운 예시로 목적이 '고객들의 회원가입 경험을 개선한다'라고 하면, 목표는 '회원가입 퍼널에서의 이탈률을 10% 이하로 줄인다' 등이 될 수 있다.

목적과 목표를 설정할 때는, 목표의 지표가 목적을 올바르게 반영할 수 있는지를 꼭 확인해야 한다. 목적과 목표 각각만 보면 필요하고 좋은 내용이지만, 목표의 수치가 목적을 반영하지 못하는 경우가 있을 수도 있다. 극단적인 예시를 들면 목적이 '구매 증대'인데, 목표가 '회원가입 퍼널에서의 이탈률을 10%로 줄인다' 같은 경우가 있다. 회원 가입률이 늘어나면, 구매가 어느 정도 늘어날 가능성도 있다. 다만 목표 지표를 통해 ‘구매 증대’ 목적을 달성했는지는 알 수 없다. 이렇게 목표를 설정할 때는 목적을 정확히 반영할 수 있는지를 따져야 한다.

또한 기획과 업무의 목적이 팀, 조직 전체의 목적과 일치하는지도 확인해야 한다. 기획과 업무의 목적과 목표가 아무리 정확하고 올바르고 논리적이라도, 팀과 조직 전체의 목적과 목표에 맞지 않는다면 의미가 없다. 결국 모든 기획과 업무는 조직 전체의 목적을 이루기 위해서며, 이에 어긋나는 일은 삽질에 가깝다.

그런데 생각보다 팀과 조직 전체의 목적이나 목표를 잊기 쉽다. 따라서, 기획서를 작성할 때 팀과 조직 전체의 목표를 간단하게 (한 줄로라도) 적어두는 게 좋다. 스스로도 해당 기획과 업무가 조직의 목적을 이루는 데 도움이 되는지 다시 한번 확인할 수도 있고, 업무를 받는 구성원도 업무의 목적에 대해 정확히 이해할 수 있다.

승: 배경 및 맥락

목적 및 목표, 즉 업무를 통해서 어떤 것을 이뤄낼 것인지를 적었다면 그것을 왜 이뤄내야 하는지는 배경 및 맥락을 통해서 전달할 수 있다. 배경 및 맥락은 한마디로 업무를 하는 근거이다. 따라서 배경 및 맥락은 기획서를 받는 입장에서 논리적으로 구성되어야 한다. 또한 결국 완성된 기획을 실제로 쓰는 사람들은 고객들이기 때문에, 철저히 고객 관점에서 작성해야 한다.

고객 관점에서 생각하며, 기획서를 실제로 받는 구성원들이 쉽게 이해할 수 있도록 논리적으로 작성하는 게 쉽지는 않다. 아니 진짜 어렵다. 쓰다 보면 고객 관점이 아니라 제작하는 입장에서 자신만의 논리와 생각에 갇히는 경우도 많고. 배경과 맥락을 작성하는 것이 어려워도 기획서를 보는 구성원들이 직관적으로 이해할 수 있도록 쉽고 논리적으로 풀어내야 한다.

적절한 배경과 맥락 없이 전달하는 기획서는 그냥 Top-Down 방식일 뿐이다. 그리고 이런 방식은 구성원들의 몰입과 책임감을 이끌어 낼 수 없다. 당연히 높은 퀄리티도 기대하기 어렵다. 배경 및 맥락에는 크게 4가지 유형이 있다. 정량적 배경, 정성적 배경, 업무의 중요성, 왜 당신이 담당자인지. 이에 관해서는 전에 발행한 글에 더 자세히 써놔서 이를 참고하면 좋다.

전: to-do

실제 해야 할 업무에 대한 부분이다. 우선순위가 높은 기획부터 전달하는 것이 좋다. 그리고 명확하게 할 일을 전달해야 한다. 명확하게 전달한다는 건, 받아보는 구성원 입장에서 다른 해석의 여지가 없이 하나의 의미로 받아들일 수 있게 한다는 것이다.

특히 기획을 하다 보면, 특정 기능 하나에도 여러 경우의 수가 나오는 상황이 많다. 정말 쉬운 예시로, 회원이 구매하기 버튼을 누를 때와 비회원이 구매하기 버튼을 누를 때 이후 화면이나 플로우가 달라진다. 이러한 다양한 경우의 수를 모두 고려해서 전달해야 구현 시 놓치는 부분을 최소화할 수 있다. 또 그래야 커뮤니케이션 리소스를 최소화하며 기획을 정확하고 빠르게 구현할 수 있다.

여러 구성원이 각각의 업무를 진행해야 할 때는 담당 업무별로 각 구성원을 언급해 주는 것이 좋다. 모든 구성원이 전체 기획서를 모두 꼼꼼히 보면 좋겠지만, 각자의 스케줄이나 업무 등으로 인해 그렇지 못할 수도 있다. 따라서 최소한 자신이 해야 하는 업무에 대해서라도 확실히 파악하는 것을 돕기 위해 개별로 언급해주는 것이 좋다.

데드라인은 정해진 스프린트 기한이 있을 때 중간 체크 데드라인 정도만 써도 충분하다. 만약 정해진 스프린트 기한이 없으면 중간 체크 데드라인과 최종 데드라인만 설정하면 된다. 일정 조정은 각 구성원에게 맡겨야지, 일정 조정까지 너무 세세하게 하려다가는 마이크로 매니징이 된다.

결: 참고 자료, 기타 사항

기획에 있어 참고할 자료나 추가로 언급할 말이 있다면 마지막에 전달하면 된다. 해당 부분은 자유롭게 적어주면 된다. 개인적으로는 보통 참고할 만한 자료나 이전에 비슷했던 기획을 링크로 걸어서 전달했다.

자신만의 기획서 작성 방법의 중요성

원페이지 기획서, 기획서 작성법, 문서 스펙 작성법 등 구글링을 하면 더 좋은 기획서 작성 방법을 찾을 수 있다. 이 글은 기획서를 처음 작성하며 생각한 것들을 적어 놓은 글인 만큼, 글을 읽는 사람들이 이를 참고해서 더 좋은 자신만의 기획서 작성 방법을 만들었으면 한다.