기획서(SB) 쓰는 법 (2)
안녕하세요. 연두씨입니다.
지난 글에 이어서 기획서의 구성과 작성법에 대한 이야기를 계속하려고 합니다.
케바케로, 사바사로 각자 작성하시는 스타일들이 있을 텐데요.
제가 생각하는 기본적으로 요 정도는 들어갔으면 좋겠다 하는 항목과 구성들을 소개합니다.
예제는 파일로 첨부하면 오피스 버전도 계속 바뀌고 해서 이미지로 캡처해서 올립니다.
먼저, 첫 장입니다. ①당연히 프로젝트명이든 작업 내용이든 제목이 있어야 할 거고요,
② 작성일과 버전, 작성자를 표기합니다. 기획서가 한번 쓰고 끝나는 게 아니라 수정사항에 따라 계속 변동될 거예요.
해서, 최종 작성일과 최종 버전이 표기해 두면 언제 문서인지 파악하기 쉽고 누가 작성했는지 적어놔야 나중에라도 그 사람한테 물어볼 게 있으면 물어볼 수 있겠죠.
여기서, 잠깐! 버전에 관한 이야기를 좀 하자면...
버전 쓰는 법도 다양한데요, 저는 기본적으로 0.1부터 시작하고 크게 대 전제가 바뀌는 시점에 앞자리(1자리) 버전을 올립니다. 중요한 건 0.1부터 시작하든, 1.0부터 하든, 1부터 하든.. 이런 건 크게 중요하지 않고요. 버전이 최초 생성되고 변경되는 시점입니다.
혼자서 문서를 어제 처음 작성했을 때 0.1이고, 오늘 못다 한 내용을 추가했을 때 0.2가 되는 게 아니에요.
최초에 기획자가 문서를 작성하고 디자인-퍼블리싱-개발 및 유관부서들과 리뷰 하면서 수정사항이 발생될 거예요.
그런 수정사항까지 모두 담아서 우리 모두가 합의한 1차 안이 나왔을 때, 이때가 베이스라인이 되는 것이고 이때 0.1로 문서를 배포합니다. 0.1을 가지고 작업하다가 피치 못할 상황이 돼서 수정이 발생한다 할 때 수정 후 다시 배포할 때 0.2가 됩니다.
다시 한번 말씀드리면, 어느 정도 합의가 된 베이스라인이 되는 시기를 정하시고 그때의 문서에 최초 버전을 부여하시고요. 이후 수정/삭제의 히스토리에 따라 유관자들한테 재배포하는 시점에 버전을 올려서 관리합니다.
③ 개정 이력에서는 문서 전체의 수정/삭제 이력을 기록합니다.
나중에 이 기능이 왜 이렇게 수정되었는지 주석처럼 남겨두어 히스토리를 파악할 수 있게 합니다. 이 부분에 남기는 항목도 개인에 따라 다양할 것 같은데요, 저는 주로
1) 어떤 내용이 2) 어느 위치에서 수정되었고 3) 어느 버전 문서에서 일어난 일이며 4) 그 수정 내용을 누가/언제 작성해 넣었는지 표기하고요, 마지막 비고에는 수정된 사유를 적습니다. 사유를 적을 때, 아주 직접적으로 적어요. 예륻 들면,
-2020-03-24 김철수, 김영희와 회의해서 수정하기로 결정함
-2020-03-24 이순희 대표가 전화로 수정하라고 지시함
④ 본격적으로 시작에 앞서 항상!! 반드시!! 까먹지 말고 절대로 꼭!!! 개요 부분을 작성합니다.
무엇을 목적으로 얼마의 기한안에 이 업무를 어떻게 할 것인지 작성합니다. 개요 없이 냅다 화면부터 그리면 나중에 이 문서를 봤을 때 도대체 이걸 왜 했는지 알 수가 없습니다. 나중 아니라 작업을 하는 중간에도 작업자 모두 이 업무에 필요한 배경과 관련 정보를 똑같이 이해하고 작업할 수 있도록 합니다. 작업 중 수정이 발생하거나 의사결정이 필요할 때에 작성된 배경 의도와 정보들을 기반으로 검토할 수 있습니다. 매우 중요한 장표입니다.
내용은, 저는 예시로 목적과 기한, 일정 정도만 썼는데요. 대응 디바이스랄지, 타겟이랄지, 법적 근거 등 필요한 사전 내용을 모두 작성하면 되겠습니다.
⑤ 다음으로 전체적인 구조를 작성합니다.
어떤 사이트나 여러 페이지를 같이 작업해야 하는 거라면 도식화 또는 표 또는 도식화+표로 작성합니다.
각 페이지의 작업보다는 어떤 프로세스가 추가되는 경우라면 해당 프로세스를 플로우 차트로 작성합니다.
이걸 작성하는 이유는 전체적인 범위와 관계를 파악하기 위함입니다. 사이트라면 메뉴와 페이지 등의 전체 작업량을 파악할 수 있고 메인과 리스트 등의 구성별 관계도가 파악이 될 거고요, 프로세스를 그린 거라면 전체적인 흐름도를 파악할 수 있습니다.
⑥ 다음은 표준 정책입니다. 제작(디자인, 퍼블리싱, 개발) 시 페이지마다, 요소마다 매번 새롭게 작업하는 게 아니라 일정한 패턴으로 작업할 수 있도록 표준 정책들을 정리해 둡니다. 이러한 정책을 마련하는 것은 완성되었을 때에 사용자로 하여금 학습된 패턴으로 서비스 이용 시 정리된 느낌과 함께 더 빠르게 적응하여 사용할 수 있도록 하고요,
작업 시에도 효율적으로 할 수 있습니다. 주로 UI상의 공통 정책들을 많이 정리하는 것 같아요. 버튼 디자인이나 입력 UI, 인터렉션 등. 그 외에도 디자인-퍼블리싱-개발에서 공통적으로 정의가 필요한 모든 부분을 정리해 두면 되겠습니다.
⑦ 이제, 드디어 실제 화면을 작성하시면 되겠습니다. 화면 작성은 예제도 많고 이미 많은 분들이 다들 잘 쓰셔서 자세한 설명은 생략할게요. 요소요소들을 배치하고 넘버링해서 상세한 설명을 달아주면 될 것 같아요.
기획서의 핵심은 앞의 글에서도 썼었지만, 목적과 요건을 잘 기술하고 시뮬레이션해서 리스크를 미연에 방지하는 데 있습니다.
근거를 위한 기록과 동시에 검증을 위한 도구입니다.
어떤 툴이 더 좋고 어떤 양식을 꼭 써야 한다는 그런 건 없어요. 제가 위에서 소개한 내용들 역시 모두 꼭꼭 있어야만 하는 건 아니고요, 필요에 따라 쓰시면 될 것 같습니다. 제가 생각하는 있어야 할 만한 항목들 정도로 정리했습니다.
기획서를 쓰는 대전제에 대해서 생각해 봐 주시고 상황과 목적에 잘 부합하게 쓰시면 되겠습니다.
