'잘' 쓴 기획서란 무엇일까?
잘 쓴 기획서가 있긴 한 걸까
*전적으로 회바회가 적용될 수 있는 영역이라 생각하고, 제 경험을 위주로 담은 글임을 알립니다.
보통 처음 기획 포지션으로 일하게 되면, 기획서를 쓰게 된다. 실제로 나도 일을 시작하기 전, 여러 아티클들을 보면서 다양한 기획서를 쓰는 방법들을 만나게 되었는데, 실제 현업에서는 어떻게 작성하고 일을 할까? 가 가장 궁금했다. 지금 어딘가에서도 이런 궁금증을 가지고 있을 기획자분들을 위해 길지 않은 기간 동안 내가 현업에서 실제 함께 일하는 분들과 부딪히며 이것저것 시행착오를 겪었던 내용들에 대해 이야기해보려 한다.
이렇게 쓰는 게 맞나요? ???: 저도 몰라요
입사한 지 얼마 되지 않았을 때, 항상 보안 이슈때문에 보지 못했던 실제 기획서를 본다니! 하고 기대를 많이 했었다. 하지만... 너무 기대를 많이 했던 걸까. 생각보다 기획서가 체계적이거나 시스템이 갖춰져 있는 상태는 아니었다. 보통 큰 규모의 회사는 양식이나 툴이 규정되어 있고, 어느 정도 관리하는 방법이 시스템화되어있는 반면, 내가 다니는 스타트업은 따로 정해진 것은 없었고, 팀 내에서 자체적으로 결정하면 되는 구조였다. 그래서 그 당시 팀장님이 작성하시던 기획서를 보고, 그냥 어깨너머로 보고 따라 하는 수준에 그칠 수밖에 없었다. 여기저기 서치해보면서 다른 분들은 어떻게 작성하나 보고... 따라 해 보는 날들의 연속이었다. 분명 내가 무언가를 쓰고 있고, 그로 인해 무언가 만들어지고 있는데 이게 맞는지도 모르겠고, 잘하고 있는지도 모르겠는 혼돈의 시기였다.
지금 보니 정말 허접했다ㅎㅎ;에이전시 스타일의 기획서
모종의 이유로 인해, 우리 팀의 팀장님이 에이전시 출신의 기획자 분으로 바뀌게 되었다. 새로운 팀장님이 오신 만큼, 팀장님이 회사의 일하는 방식이 변화하게 되었는데, 이때 에이전시 스타일의 기획서가 무엇인지를 경험할 수 있었다.
디스크립션이 ppt장표 영역을 벗어나버린...에이전시 방식으로 작성하는 기획서는 정말 꼼꼼하게 작성하는 것을 요구했다. 개인적인 생각으로는 ‘이런 것까지 적어야 하나?’ 싶은 것도 적어야 한다는 피드백을 받기도 했었다.
왜 이렇게까지 꼼꼼하게 적는 걸까? 하고 생각해 봤을 때, 에이전시는 아무래도 고객사의 일을 받아서 하는 경우가 많고, 또 함께 협업하는 개발/디자인 또한 같은 회사가 아닌 독립된 외주사와 일 하는 경우도 더러 있기 때문에 다른 협업하는 상황에서 트러블이 발생하는 것을 미연에 방지하기 위함이 아닐까? 하는 생각이 들었다.
에이전시 방식은... 개인적으로는 잘 맞지 않던 방법이었다. 정말 상세하게 작성하느라 들이는 리소스는 컸지만, 그렇다고 개발자와 커뮤니케이션하는 리소스가 줄어든 것은 아니었다. 너무 길고 방대한 장표의 양으로 인해 개발자들도 읽어야겠다는 의지 자체가 사라지고 있다는 느낌을 받았다. 그렇다 보니 분명 기획서에 작성해 둬도, 개발자가 읽지 않아서 커뮤니케이션을 또 해야 하는 경우가 많이 발생했다.
좋은 기획서를 찾기 위한 여정
끊임없이 늘어나는 ppt와 디스크립션에 허덕이던 나는 결국 또 팀장님이 바뀌고 나서야 그 굴레에서 벗어날 수 있었다. 그냥 남들이 하는 방식을 따라 했던 방식부터 에이전시식의 방식까지 겪고 나니, 계속 나한테 맞지 않은 옷을 입고 있었다는 생각이 들었고, 정말 일을 '잘' 하기 위한 기획서를 찾아야겠다는 생각이 들었다.
좋은 기획서란 무엇일까?부터 정의가 필요했다. 나는 다른 사람들과 일하면서 커뮤니케이션하는 것에 대한 리소스를 줄이는 기획서가 좋은 기획서라고 정의했다. 그리고 추가로 개발이나 디자인이 각각 필요한 정보가 적재적소에 들어가 있는 기획서 정도로 정의했다. 그리고 우리 회사에 있는 사람들과 소통하기 위해 필요한 문서인데, 다른 사람들이 좋다고 한 방법을 따라 한다고 해서 그것이 우리 회사에 100% 좋다는 보장은 없다고 생각했다. 그래서 여러 가지 방법을 시도해 보고 각 방식들에 대해서 개발자나 디자이너에게 어떤 방식이 편한지 피드백을 받으며 방법을 수정해 나갔다.
한 기능의 케이스별로 정리한 기획서이런 과정들을 통해 천편일률적인 기획서가 아닌 프로젝트의 특성에 따라 기획서를 작성하게 되었다. 신규 프로젝트의 경우에는 전체 플로우를 먼저 이해할 수 있는 '전체 보기' 페이지를 만들고, 상세한 기능들에 대해 기획서를 작성했다. 기존 페이지의 기능을 개선하는 프로젝트의 경우에는 기존과 '변화'가 이루어지는 영역을 위주로 작성하여, 개발자가 어떤 부분의 변경이 필요한 것인지를 확실하게 인지하도록 작성하는 방식으로 진행했다.
해당 방식으로 진행하다 보니, 개발자/디자이너와의 커뮤니케이션 리소스가 많이 줄어들었음이 체감되었다. 더하여 내가 어떤 방식의 기획서가 일할 때 편한지를 계속 물어보다 보니, 메이커 분들도 어떤 식으로 정리해 주면 좋을 것 같다는 의견을 먼저 주시기도 하여, 함께 조율해 나가다 보니 더 효율적으로 업무를 처리할 수 있었다.
기획서에 정답이 있을까?
나는 절대적인 정답은 없다고 생각한다. 사바사도 심하고 회바회도 엄청 심한 영역이다. 나도 취준생 시절 현업자에게 기획서에 대해 질문하면 '회사마다 달라요~' 이런 답변을 들어서, 왜... 맨날 회바회라고만 말하는 거지?라고 생각했었는데, 실제로 내가 이 상황에 처하니까 그때 그분이 왜 그렇게 말씀하실 수밖에 없었는지 이해가 된다...
기획이 UX까지 신경 써야 하는 회사도 있고, 기능만 기획하고 UX는 디자이너가 하는 등 업무 범위마저 회사마다 차이가 발생하는 경우가 많다. 오히려 어디 유명한 회사는 이 방식으로 한다니까 우리도 이렇게 하자! 하고 절대적으로 믿는 것을 더 지양해야 한다고 생각한다.
그러나 이 사이에 답이 하나 있다면 기획서는 '소통'을 위해서 작성한다는 것이다. 다른 사람들이, 다른 회사가 어떻게 하는지를 보고 배우는 것도 필요하지만, 그것 보단 우리 회사 사람들과 소통하기에 가장 편하고 효율적인 방법은 무엇인가? 를 생각하는 것이 더 중요하다고 생각한다.