by
Nov 29. 2019
서비스 기획서 가이드 1편
기획의 품질과 생산성, 효율성을 높이는 기획서를 만드는 가이드
지난 시간에 기획의 품질을 높이는 프로세스와 체크리스트에 대해 어디에 더 비중을 두어야 하는지에 대한 말씀을 드렸었습니다.
고객에게 긍정적이고, 매력 있고, 구매욕구를 불러일으키는 경험을 기획하는 것은 기획자의 사명 같은 것이지만, 그 사명을 이루기 위해서는 함께 협업하는 많은 단계의 분들 (업무 요청자, 디자이너, 퍼블리셔, DB 담당자, 개발자-프런트엔드, 백엔드, 웹 개발, 앱 개발 등등)에게 "일이 되도록"하기 위한 문서를 제작해야 합니다. 문서의 종류는 "요구사항 정의서" "SOW(Statement of Work)" "기능명세서" "스토리보드" "WBS" 등 프로젝트 수행단계에서 정의하게 될텐데요.
프로젝트에 있어 기준 문서는 통일되어 있어야 서로 커뮤니케이션이나 실무 수행에 문제가 발생하지 않기 때문에 이 과정은 시작부터 끝까지 계속 이루어지면서 관리된다는 것은 기획자라면 다들 아실 겁니다.
꼭 PPT 문서로만 하냐는 질문들을 많이 받는데, 프로토타이핑 툴 관련해서는 많은 프로그램들을 직접 활용도 해보고 했지만, 다른 주제에서 말씀을 드리도록 하겠습니다.
하나 분명한 것은 PPT가 화면 설계에 대한 시각화를 잘 표현할 수 있고, 습득 시간이 빠르며, 다양한 방법을 구사할 수 있고 누구나 설치되어 있다는 부분에 있어서 접근성이나 장점이 크다고 할 수 있습니다.
다양한 실무경험을 가진 30여 명의 모든 협업부서 구성원들이 모여서 잡은 가이드는 아래와 같습니다.
하나하나 같은 목표와 성과를 내기 위한 조정이었기 때문에 2년째 조금씩 업데이트는 있지만 이 틀을 유지하고 있습니다. 보기 좋고, 잘 정리된 기획서를 보면 일하기도 좋다는 거죠. ^^
화면 비율 : 16:9
표준 4:3 크기는 외부에 PT 발표를 하거나, 예전 프로젝터, 모니터를 쓸 때 사용하는 비율입니다. 회사 내 대부분의 모니터는 16:9이며, 가로로 넓어진 공간을 활용하여 더 많은 정보를 담을 수 있으므로 더 유리합니다. 출력해서 보기도 용이하고요. 예를 한번 보실까요?
4:3 일 때
16:9로 확대해보면숨겨진 공간을 활용하면 표현이 이렇게 풍부해질 수 있습니다. ^^
파일명 : 프로젝트(업무)명_v1.0_작성자_YYMMDD
파일명은 컴퓨터 내 주소 같은 역할, 그리고 모두가 하나의 파일에 있는 동일한 내용을 가지고 얘기해야 혼란이 없기 때문에 정리하는 것은 중요합니다.
상세하게는 버전 관리를 하는 부분인데요. v1.0 은 개발자부터 테스트 엔지니어까지 업무의 범위에 대해 유관 부서와 협의 후 확정된 최종 버전을 말합니다.
숫자상으로는 v0.7은 업무범위에 관련된 모든 기획서를 기획자 입장에서 완료한 버전, v0.8은 킥오프 미팅을 통해 나온 개선사항을 반영한 버전, v0.9는 공유된 v0.8을 가지고 킥오프 미팅 시 보지 못한 부분을 실무 진행 관점에서 각 협업 담당자들이 페이지마다 상세히 확인하면서 보내준 수정사항을 모두 반영한 버전입니다. 이런 v0.9에서 PL급 팀장이나 기획팀장이 전체 범위에서 빠진 부분이나 추가 코멘트할 부분이 없는지 확인을 거쳐 v1.0을 완료하게 됩니다.
수정에 대한 자료와 근거를 남기기 위해서는 아래와 같이 구글 닥스를 사용하면 수정 개선하는 부분도 빠뜨림 없이 진행할 수 있습니다. (저의 경우 녹음해서 다시 들으면서 하나씩 보정하는데, 구글 닥스와 병행해서도 쓰고 있습니다.)
통상 v0.8 단계가 v1.0 인 경우가 많습니다. 절차는 상황에 맞게 유연하게 하면 되는데, 여러 명의 개발자가 있을 경우는 이런 단계를 거치면 재작업 이슈가 많이 줄어들긴 합니다.
최종 버전을 v1.0으로 규정하고, 이후 업데이트 버전부터 v1.1, v1.2..로 순차적으로 순번을 부여합니다. (문서 업데이트가 많을 경우, 소수점 2자리까지 부여 가능) v2.0, v3.0과 같이 앞자리가 바뀌는 경우는 해당 업무의 2차, 3차 버전과 같이 정책적인 큰 변화가 있는 경우에 부여될 수 있도록 관리합니다. (보통 이렇게 되면 새로운 프로젝트로 발의해서 업무 진행하는 게 더 낫습니다. )
표지
표지에서는 함께하는 유관 담당자와 버전 입력란, 최종 수정일을 확인할 수 있는 영역을 제공하면 맞는 파일을 보고 있다는 확인을 한번 더 할 수 있게 됩니다.
표지 샘플파일명을 보고 연 다음 제대로 찾아왔는지 확인하는 거죠.
문서 변경 이력
버전 명시와 변경이력 작성은 마음을 내려놓고 습관처럼~ 진행해야 빠뜨리지 않게 됩니다. 문서 공유 이전, 본인만 작성하시는 경우라면 크게 변경이력 관리는 하지 않아도 되지만, 킥오프 미팅을 가지거나 공유가 한 번이라도 되었다면, 변경이력은 관리하기 시작해야 합니다.
현재 문서에서 변경한 이력을 별도 BG 컬러로 표시해두면, 담당자가 더 편하게 확인 가능하겠죠?
변경 이력위에서 쓴 이력의 화면 ID만 찾아가서 변경사항만 디자인, 개발을 수행하면 되는 부분인데요. 변경/추가된 페이지를 찾아간 경우 ‘메모 BOX’로 표시해두면 해당 장표의 내용을 확인할 때 이해하기 편합니다.
타이틀에는 버전명(예: v1.1) + 변경 유형(예: Add, Delete, Update) 명시하고 내용은 'Before→After 형식'으로 업데이트 전/후를 비교할 수 있도록 작성해주면 더 좋습니다. 구 버전의 메모 Box는 화면 밖으로 이동시키고, gray 컬러로 변경 처리해 놓으면 나중에 참고가 가능하겠죠?
화면 ID
페이지로 표현하는 경우 추가페이지 생길 때마다 위치가 변경되어 혼란이 옵니다. 화면 ID가 필요한 이유기도 하고 IA를 그리거나 찾아가기 쉬운 방법입니다.
메뉴 Depth를 ID로 표현한다기보다, 어떤 화면인지 소통하기 용이하도록 카테고리 화해서 문자로 시작하며, 숫자는 가급적 1~2단계 내에서 사용합니다. 예) leclist_01, myoff_01_02
화면 ID 표기 예제