반응형


처음 기획을 할때 어려운 점이 바로 시작하기가 어렵다는 것이 아닐까 한다. 그냥 모니터만 멍하니 바라보며 있는 경우가 허다하다. 단 한자도 못써내려가는 심정...

난 거의 몇시간을 그렇게 모니터만 본적이 있다.

하지만 이렇나 기획서의 작성시에 이렇게 멍하게 있게 되는 경우가 바로 뭘 써야할지 정리가 되지 않아서 이렇게 시간만 보내는 경우가 많다.

일단 기획서는 이것저것 생각하지 말고 목차를 써내려 가기만 하면 된다. 즉 목차는 모든 기획서의 50%를 차지하기 때문이다. 그리고 무엇을 쓸지 대략적인 머리속의 구상을 보다 구체적인 그림으로 그릴 수 있는 방법이 목차 작성이기도 하다.

그렇다면 이 목차는 어떻게 작성하면 되는가. 이것도 솔직이 고민할 필요는 없다. 즉 이미 정해져 있기 때문이다.

거의 모든 기획서의 목차는 다음의 순서를 따라하게 된다. 기획서의 기본은 바로 사람들과의 말하는 것과 같기 때문이다. 즉 무엇을 말하려고 하는지 그리고 무엇을 하고자 하는지 그리고 그것을 통해서 무엇을 얻고자 하는지 등…

1. 목적

2. 이유

3. 현황

4. 분석

5. 방안

6. 시스템, 인력구성(생략가능)

7. 결론

이정도의 목차수준이면 충분하리라 생각한다.

1. 목적

하고자 하는 방향과 그것을 통한 목적에 대해서 명확하게 정의.

사람들에게 무엇을 할것이다라는 말을 정확하게 제시하라.

2. 이유

이 기획서를 작성하게 된 동기와 그에 따른 이유

모호하게 사용하지 말고 왜 이러한 것을 해야하는지 대략적인 정의를 내린다.

3. 현황

자사의 현황에 대한 문제점을 상세하게 정리

회사의 여러 문제점에 대해서 조사한 내용을 쉽게 정리하고 모호한 표현보다는 직설적인 언어로 사용하라.

4. 분석

다른 업체들의 동향과 트랜드 및 그 업체별 장단점.

객관적으로 업체들의 동향과 트랜드를 분석하여 간략하게 나타내고 맨 마지막장에는 업체분석의 내용을 하나의 표로 나타내라.

5. 방안

자사의 문제점과 분석을 통한 타사의 장점을 조합한 방향 제시

(컨텐츠, 서비스, 사이트 등 구체적인 사항 나열)

분석된 내용을 토대로 회사에 적용할 사항을 정리하여 실행방안을 제시한다.

6. 시스템, 인력구성(생략가능)

이것을 하기 위해서는 어떤 인력이나 회사의 자원에 대한 내용을 제공.

시스템, 유지보수, 실행인력 등 대략적인 회사 역량에 대해서 작성.

7. 결론

이러한 사항을 도입했을 때 회사가 얻을 수 있는 것에 대한 View 제시

(방안에 나온 사항을 토대로 회사가 얻을 이익에 대한 정의 도출)

이렇게 정리되는 것은 바로 어떤 사안에 대해서 옆사람에게 이야기 하는 방법과 같기 때문이다. 기획서를 읽거나 보게되는 사람의 경우 기획서를 보다 잘 이해시키기 위해서는 위와같이 접근하게 된다. 이른바 스토리 텔링 방식으로 접근하는 것이다.

이것을 대화 형태로 바꾼다면

“이것을 하려고 하거든(목적).

왜 하려고 하나면(이유)

울 회사에 이런이런 문제가 있는거야(현황).

다른 회사는 어떻게 하는 알아 봤더니 이런이런 좋은 점들이 있는거야(분석).

그래서 이번기회에 우리 회사도 이번에 이렇게 바꾸어서(방안)

회사의 시스템을 가지고 회사의 누구누구랑 멋지게 만들어서(시스템, 인력구성)

회사가 다른 경쟁업체보다도 좋은 서비스와 수익을 올리게 하고 싶어(결론)”

라고 할 수 있다.

아무리 잘만든 기획서를 읽기 어렵다거나 이해하기 힘들다면 그것은 아무런 효율도 없이 그냥 버리는 것과 다를게 없게 된다. 항상 이야기 하듯 소설처럼 사람들이 한번에 쭉 읽어 볼 수 있는 기획서를 작성하는 것이 바로 제일 중요한 방법이 아닐까 한다.

기획서 만드는 것이 어려운 것이 아니다. 이미 여러분들은 자신의 삶을 기획하며 살고 있지 않은가. 단지 글로 표현하기 어려울 뿐인 것이다.

이제 방법을 알게 되면 자신의 인생부터 기획서로 만들어 보자!! 그렇게 하나하나 만들다 보면 어느순간에 자신도 능숙한 기획자가 되지 않을까 한다.

반응형
반응형


스토리보드는 어쩌면 아주 간단한 것이지만 그것이 어려운 이유는 바로 생각을 현실로 만드는 첫 단계이기 때문이 아닌가 합니다.

스토리보드는 말 그대로 작업을 할때 구상하는 스케치부터 포함이 됩니다.

스토리보드에서 파워포인트에 작성할때는 이미 모든것이 정해진 상태로 진행해야 합니다. 파워포인트에서 생각하면서 작업하는 것은 그만큼 효율면에서나 시간면에서 문제가 발생을 합니다.

스토리보드를 잘 만드는 방법은 저의 경우는 다음과 같이 작업을 합니다.

1. 분석
만들고자 하는 사이트에 대한 기본적인 분석을 합니다. 이때 분석은 두가지로 진행이 됩니다.
- 컨텐츠 분석 : 어떤 것을 Web에 담을 것인지에 대한 분석입니다.
- 디자인(UI) 분석: 어떤 형태로 고객들에게 제공을 하는지 Web상의 표현방법을 찾습니다.
이렇게 분석을 완료하면 그에 따른 기초 토대를 쌓습니다.
산출물 : 벤치마킹 자료, 요구분석서

2. 기초설계(IA)
흔히들 기초설계부분을 건너뛰고 스토리보드 작업을 진행하는 경우가 많이 있습니다. 아니면 간단한 사이트맵 수준으로 정하고 작업을 하게 되는데 이때 이 부분에서 명확한 정의를 내리지 않을경우 스토리보드 작업시에 정책적 배려없이 뒤죽박죽 된다거나 심할경우 다시 스토리보드 작업을 해야 하는 상황이 나타납니다.
일단 분석에 따라서 기본적인 사이트 구조와 각 구조별 형태 즉 게시판 형태인지 단순한 웹페이지 인지 아니면 보다 개발적 이슈가 강한 것인지에 따른 기본적 정보를 작성하게 됩니다.
이때 나오는 정보를 가지고서 Naming 부터 메뉴 구조등 다양한 기본 사이트 구조의 설계가 완료가 됩니다.
산출물: 기초 통합 기획서

3. 상세설계-1(브래인스토밍)
이제 기초설계에 따른 상세설계를 하게됩니다. 그런데 상세설계를 바로 파워포인트에 하는 것은 오히려 시간적 효율성에서 상당한 손해를 가져오게 됩니다.
일단 파워포인트 작업을 들어가기 전에 구축해야할 컨텐츠에 대한 성격을 고려하고 기초 통합 기획서에 나와있는 형태를 확인하여 일단 손으로 빈 용지에 그려보는 작업을 해야 합니다.
머리속에 있는 것을 가장 먼저 스케치하듯 그리면서 고객에게 어떻게 접근해야 하는가에 대한 기본 UI 안을 그리고 그에 따른 각 컨텐츠 성격에 맞게끔 다양한 스케치를 하게 됩니다.
이렇게 스케치를하고 기본적인 구조를 파워포인트 문서로 작성해서 1차적 브레인 스토밍을 거칩니다. 이때 의견에 따라서 기존 구조를 잡을것을 확인하고 보강해 나갑니다.

4. 상세설계-2(스토리보드 작성)
이렇게 브레인스토밍에 따른 구체화된 기본구조에 옷을 입히는 작업을 합니다. 즉 기본구조에 링크를 달고 설명을 해서 각 링크간 페이지에 대한 내용을 최대한 자세하게 작성을 하게됩니다. 단 이점에서 주목할 것은 자신의 언어가 아닌 팀원의 언어로 정의를 내린다음 이것을 통해서 스토리보드의 언어를 사용해야 하는 것입니다.
간혹 자신만이 아는 방식으로 스토리보드를 제작하고 만들고 난 다음에 다시금 제작할때마다 스토리보드를 설명하려 왔다갔다 하는 것이 아닌 바로 스토리보드를 이해하면 바로 작업을 들어 갈 수 있도록 해야 하는 것이 스토리보드의 핵심입니다.
그래서 스토리보드를 작성할때는 이전에 이미 기초통합기획서에 대한 내용을 명확하게 이해하고 그에 따른 작업으로 스토리보드가 진행되는 점을 팀원들에게 명확하게 설명을 해야 합니다.
그에 따라 내부적으로 운영하기 위한 스토리 보드를 작성하기전에 명시할 사항은 다음과 같습니다.
- 파일명: IA때 파일명명에 대한 사항을 명시하여 스토리보드에는 메뉴와 파일명이 일치하도록 함.
- 링크 : 링크 처리된 사항에 대한 표시(페이지구분, 파일명구분)에 대한 정책수립.
- 문서명명 : 해당 스토리보드의 문서에 대한 일정한 기준으로 문서명에 대한 정책수립.
- 문서버전 : 작업자의 스토리보드가 변경될때에 대한 버젼 관리에 대한 정책수립
위 사항을 팀원 각자에게 주지 시키고 디자인과 개발로 넘어가는 단계의 정책에 있어서 혼선이 생기지 않도록 위 사항에 맞게 문서를 작성해야 합니다.

5. 마무리
스토리보드를 작성한 후에 반드시 1차 전체 검수를 하게 됩니다. 링크는 제대로 표시가 된것인지 파일명은 확실한지 전달자에게 해당 파일명에 대한 버전표시는 제대로 이루어지고 있는지 작업자에게 정확하게 도달되었는지를 반드시 확인해야 합니다.
스토리보드 하나에 디자인과 개발진까지 고려해서 생성하지 않을 경우 결국 스토리보드는 기획의도와는 상관없이 왜곡 될 수 있는 점 반드시 명심하셔야 합니다.
큰 줄기가 바뀌지 않도록 제공하며 반드시 하나의 스토리보드에 따른 작업진행하기전에 반드시 디자인, 개발의 인원을 모아서 전체 브리핑을 하게 됩니다. 이유는 바로 전체 브리핑을 하지 않을경우 각 파트별 문제사항으로 인한 스토리보드의 변경에 차질이 오게 되며 불필요한 작업으로 인한 시간 손실을 감수해야 합니다.
그래서 반드시 하나의 스토리보드에는 1차 브리핑을 통해 팀원들의 의견과 잘못된 사항에 대한 내부적 토의를 거치고 이에 따른 결과는 전체 프로젝트에 참여한 인원들이 알 수 있도록 합니다.

스토리보드는 팀원간의 작업을 위한 언어입니다. 자신만의 언어가 아닌 공통된 기준과 스타일을 통해 보다 원활하게 사이트의 구축을 이룰 수 있을 것입니다.
반응형

+ Recent posts