기획서를 쓰는 목적은 무엇인가

기획서를 위한 툴이야기를 하려다가 서론이 너무 길어졌달까. 기획서에 대해 한번 더 짚고 넘어가야 할 것 같다. 원고 분량 조절 못한걸 포스트 연재로 해결하기로(…) 이전에도 기획서에 대해서 썼던 글이 있다. 딱 1년 만에 다시 쓰는 기획서에 대한 글이다.

1. 도큐먼테이션

Documentation <컴퓨터> 연구에 필요한 문서, 증거 서류, 자료, 문헌 따위를 잘 이용할 수 있도록 정리하고 체계화하는 기술. 이에는 정보의 수집, 분류, 색인, 초록의 작성, 정보 검색 따위가 있다.

기획서의 성질 자체도 도큐먼트에 기반하므로 ‘정리’하고 ‘체계화’하는 기술이 가장 중요하다. 하지만 많은 기획자들의 시간은 정리나 체계화에 쓰기보다는 디테일에 목숨걸고 폰트하나 픽셀하나를 보기좋게 맞추는데에 있고, 이런 저런 레퍼런스들을 갖다붙이며 페이지를 늘리는데에 혈안이 되곤 한다. PPT나 Keynote같은 프레젠테이션툴이 가장 기본적인 도큐먼테이션 툴이기 때문에 많이 사용하는데, 화면단위의 UI 1-2개와 디스크립션이 적혀진 포맷이 일반적이다. 그래서 Flow나 Case 정의도 화면으로 예시를 전부 보여주는데, 이는 ‘정리’나 ‘체계화’와는 거리가 먼 단순한 나열에 불과하다.

따라서 특별한 UI가 필요한 경우가 아니라면 대표적인 화면 1개를 그리고 그 화면에서 발생할 수 있는 베리에이션에 대해서는 별도의 문서로 작성하는 것이 좋다. 뭔가 프레젠테이션툴이라 한 눈에 파악할 수 있게 스토리보드에 모든 화면을 그려야 한다고 생각하기 쉽지만 페이지가 달라져도 정보는 충분히 연계된다. 따라서 트리구조나 플로우로 먼저 정리하고, 필요한 화면 번호를 달아주는 것이 플로우를 따라가며 개발하기에 좋다.

또 같은 화면에서 문구나 요소들의 베리에이션이 발생할 때는 표(또는 엑셀파일)분리해서 삽입하면 된다. 양이 많지 않을 때에는 문서에 직접 삽입해도 좋고, 양이 많으면 구글 스프레드시트 등을 사용해 공유하면 된다.

2. 리뷰와 공유

기획서의 두 번째 목적은 기획자의 머리속에 있는 요구사항이나 스펙등을 개발팀과 상호리뷰하고 공유하는데에 있다. 따라서 나의 기준이 아니라 모두가 함께 볼 수 있는 형식과 포맷을 갖추는 것이 좋다. 기획자가 욕먹는 이유중에 하나는 기획서의 업데이트가 늦다는 것에 있는데, 기술검토나 회의를 통해 변경되는 스펙이 발생했음에도 불구하고 기획서는 반영되지 않는 다는 점이다. 기획이 변경되었음에도 불구하고 가장 최근버전의 기획서가 예전 버전의 기획이라면, 개발자는 당연히 구 버전의 기획에 맞춰 개발하기 마련이다. 따라서 기획서는 잦은 리뷰와 업데이트, 팀 공유에 최적화 되어야 한다.

조금만 더 신경을 쓴다면 릴리즈 버전에 대해 어떤 버전이 업데이트 되는지 버전관리가 되어야 한다. 기획서는 소스코드처럼 형상관리툴이 없으므로 아차 하는 순간 버전이 통채로 날아가기도 하며, 제대로 관리하지 않으면 언제 쓴 기획서가 최근버전인지 본인 조차도 모를 수 있다. 굳이 가이드를 하자면, 문서의 초반에는 해당 문서의 히스토리를 적어두는 것이 좋으며, 이전 버전의 기획에서 변경되는 부분은 하이라이트(밑줄, 글씨 색 지정 등)해두고 빠르게 변경할 수 있도록 하는 것이 좋다.

히스토리의 역할은 무엇인지 질문을 받은적이 있다. 히스토리에 아무것도 없으면 다음에 기획서 업데이트할때 뭐가바뀌었었는지 추적하기가 힘들고, 커뮤니케이션 과정에서 말을 바꾸는 일이 많은데 A로 하자 -> B로 바꾸자 -> c로 바꾸자 -> A가 낫지않아? 의 상황이 의외로 자주 발생한다. 이럴 때, A는 이런이런 이유 때문에 제거한다는 것을 명시하기 위해 히스토리를 남긴다. 소소한 변경사항은 페이지별로 기록하고, 정책적인 면이 변경됐을 때는 문서 전체의 히스토리로 남겨두는 편이 좋다.

공유는 생각보다 신경을 많이 써야하는 작업이다. NAS 같은 웹하드나 구글드라이브/드롭박스 같은 클라우드라 같은 곳을 바라본다면 다행이지만, 이메일로 공유하는 경우는 파일관리가 제대로 되지 않고 검색에 용의하지 않은 편이라 원할 때 바로 접근하기가 어렵다. 요즘엔 Slack 같은 협업공유툴이 유행이라 바로 업로드하고 묻혀버리기 쉬우니 묻히지않도록 잘잘… 팀마다 룰이 있을테니 이건 잘…

3. 커뮤니케이션

기획서는 효율적인 커뮤니케이션을 위한 도구가 되어야 한다. 기획서를 보고 이야기하고, 기획서를 변경하고, 이력을 관리하는 것 모두 커뮤니케이션을 위한 사전준비랄까. 한장짜리 손그림 기획서도 커뮤니케이션에 윤활유가 될 수도 있지만, 디테일 쩌는 100장짜리 기획서라고 해도 커뮤니케이션에 방해가 될 수가 있다.

기획서를 만들기부터 제대로 활용하기 위한 단계는 도큐먼테이션, 리뷰, 공유, 커뮤니케이션 순이지만 그 우선순위는 반대로 커뮤니케이션, 공유, 리뷰, 도큐먼테이션이 되어야 한다. 하지만 정말 많은 조직에서 기획의 포지션은 탑다운을 위한것이라해도 무리가 없어서 도큐멘테이션만 하고 공유하면 자기의 일을 다 끝냈다고 생각해 커뮤니케이션하고 피드백받는 일은 거의 하지 않는다.

수시로 변경되고 추가되는 스펙은 엄청나게 많은데 기획의 기획서는 초기버전에 머물러 있다면, 아무도 기획서를 보고 개발하지 않는다. 1px까지 맞춰가며 도큐먼테이션에 시간을 쏟은 기획서가 쓰레기통 파일이 되는 것은 한 순간 이라는 것을 기억하자.

다른 글

앱 & 서비스 기획자입니다. 잘하고 싶어요.

Sliding Sidebar