벤치마킹이란 무엇일까요?

저도 홈페이지 벤치마킹을 하고자 할때는 많은 생각을 하고 있습니다. 

사실 기획을 제대로 배운적이 없는 상태에서 기획서를 만들려고 할때는 이것 저것 많이 찾아보고 했던것 같아요.

지금은 벤치마킹의 정석이란 무엇일까를 많이 생각하게 되는 것같습니다. 

벤치마킹을 할 때 작으면 작은 일이고 많으면 많은 일이죠. 정말 많은 것을 비교해볼 때도 있고 적은 것을 비교해볼때도 있어요.

기획을 하면서 벤치마킹을 하는 경우를 크게 예를 들면 아래와 같습니다.

1. 리뉴얼 대상의 홈페이지 벤치마킹

  - 리뉴얼 대상의 홈페이지는 이미 홈페이지가 있고, 동종 홈페이지가 매우 많이 존재할 때를 말하죠. 

예를 들어 서울시 교육청 홈페이지의 리뉴얼 벤치마킹을 한다고 가정해봅시다.

전국에는 17개의 광역지자체, 229개의 기조 지자체가 있습니다. 그럼 우리는 "벤치마킹 목록"을 작성할 수 있어요.

2. 신규 제작 홈페이지의 벤치마킹

 - 신규제작하는 사이트의 벤치마킹 목록은 과업지시에 나와있거나 1차 조사를 통해 클라이언트(이해관계자)를 통해 얻을 수 있습니다.

구글 검색으로 쫙열어놓고 목록을 컨펌 받을 수도 있습니다.

3. 스타트업에 대한 벤치마킹

 - 목록을 정하기가 굉장히 어렵습니다. 왜냐하면 아무것도 같은것이 없기 때문이죠. 

   디자인은 국내·외가 다르고 정서가 다르기 때문에 디자인 참고를 외국사이트로 하는 것이 아니라 콘텐츠 위주의 벤치마킹을 해야 합니다.

우리는 이러한 것에 대한 벤치마킹을 할때는 무엇을 어떻게 할 것인가를 정해야 합니다.

저는 벤치마킹할 때 3개의 파일을만듭니다.

 1) 벤치마킹 목록 및 정리파일

 2) 벤치마킹 파일

 3) 벤치마킹 보고서

우선 벤치마킹 목록 및 정리파일을 보시죠.

 1) 벤치마킹 목록 및 정리파일을 만듭시다

우선 저렇게 기본 정보만을 담을 수 있습니다. 

비교대상이 있다면 차례차례 뒤에 붙이는 거죠. 예를 들어 홈페이지에 리모컨(빠른 서비스)가 있다면 하나를 추가해 보는거예요.

그 뒤에 컬럼을 하나 추가하여 있는지 없는지를 표시할 수 있습니다. 

이렇게 필요한 것들을 쫙 나열하는 거예요. 

예를 들어 결제, 회원가입, 아이핀 여부 등 여러가지의 컬럼을 추가 할 수 있을 것입니다. 

그것은 사업의 목적과 배경에 대한 부분과 연결되어 있으므로 과업지시서를 꼼꼼히 읽은 후 조사할 항목들을 보는 것이 좋을 것같습니다.

항목들을 모두 조사했다면 비교 표를 만드는 것입니다.

※ 1메뉴를 비교 했을때 1차 가공

※ 1메뉴를 비교 했을때 2차 가공

※ 1메뉴를 비교 했을때 3차 가공

이후 기존에 메뉴와 비교해서 필요한 것들을 클라이언트와 협의해서 메뉴를 지정하면 되겠습니다

2) 아이디어를 정리해야 합니다.

해당 정리파일에는 아이디어라는 시트를 하나 만들어 두면 좋습니다. 

방식은 없어요. 

※ 이렇게 생각날때마다 정리해두지 않으면 잊을 수 있어서 정리해 두면 좋습니다.

2. 벤치마킹 파일을 작성한다.

1) 일단은 영역을 구분 지어 보는 것이 좋습니다.

※ 더욱 세분화해서 나눠도 되고 덜 세분화해서 나눠도 되고 사업의 목적에 따라 다르게 할 수 있습니다.

2) 인터페이스의 영역을 구분해 볼 수 있습니다.

※ 이렇게 정리한 영역도 엑셀에 정리해서 비교 분석을 하면 되겠습니다.

3) 리뉴얼할 사이트와 비교해서 벤치마킹하는 사이트의 장, 단점을 정리할 수 있습니다.

 사실 장단점을 생각하는 것은 주관적이 될 수 있습니다. 주관적이 되었다면 주관적인 의견이라고 반드시 노출해야 합니다.

4) 디자인에 대한 주관적인 느낌을 적어볼 수 있습니다.

5) 홈페이지를 처음 봤을때 시선의 흐름을 적을 수 있습니다.

자! 여기까지 벤치마킹 파일을 만들었습니다. 이렇게 쫙 벤치마킹 사이트를 분석해 보는 것입니다.'

이제 가장 중요한 벤치마킹 보고서를 만들것입니다. 이제까지는 준비단계였습니다!

3. 벤치마킹 보고서를 작성합니다.

1) 목차

 목차작성을 아래와 같습니다.

Ⅰ. 벤치마킹 개요

  1. 개요

   1) 사업명 : 

   2) 대상 : 

   3) 벤치마킹 기관 및 사이트

      (1) 사이트명 1 : 주소 

      (2) 사이트명 2 : 주소 

  2. 취지 및 목적

Ⅱ. 사이트별 벤치마킹 내용

  1. 사이트명 1의 일반현황

    - 주소

    - 기본정보

    - 특이사항

    - 벤치마킹

  2. 사이트명 2의 일반현황

    - 주소

    - 기본정보

    - 특이사항

    - 벤치마킹 

  3. 벤치마킹 결과

    - 비교분석

    - 도입요소 및 이유

    - 제외요소 및 이유

  4. 화면 초안

 2) 디자인

 디자인을 해야 할 경우를 제외하고는 중요하지 않습니다.

이렇게 작성하면 되겠습니다!

벤치마킹은 위의 준비자료가 시간이 오래걸리는 것이며, 벤치마킹 보고서는 단순 보고용으로만 제작되는 것이라 어려운것이 없습니다. 

자 기획자 여러분 오늘도 화이팅입니다.

WBS는 Work Breakdown structure의 약자입니다.

저같은 경우는 WBS를 만들기 전 사전 미팅을 가집니다. 

1. PM, PL, 기획, 디자이너, 개발자를 모아놓고 내부미팅을 먼저 가집니다.

  - 브레인스토밍을 진행합니다.

 · 브레인스토밍을 할때 중요한 부분이 있습니다. 굉장히 매우 중요한 건데요. 상대를 절대 비판하지 않아야 한다는 것입니다.

예를 어떤 한 사람이 게시판형태를 박스형으로 제작하자라는 아이디어를 내놓았는데 이에 있어 수용하고 선택해야 하지 않고 그것은  어떤것 때문에 안돼라고 한다면 더이상 그사람은 아이디어를 내놓지 않을 것이며, 다른이들도 의기소침해져서 더이상의 이야기가 진행되지 않기 때문이죠. 그래서 나잘랐다고 떠드는 회의가 아니고 여러 의견을 모으는 회의자리라는 것을 모두 명심해야 하는 것입니다.(근데 꼭 이런놈들이 있습니다....)

2. 외부의 요구를 회의합니다.

 - 기획자와 PM의 역할입니다.

  · 클라이언트와 미팅을 통해 언제까지 무엇을 해야하는지에 대해 분석하고 협의합니다. 불가능한 일정을 말하는 경우가 대부분이기 때문이죠. 

 · 우리나라의 고질적인 문제는 바로 클라이언트들은 저비용에 고효율을 내려고하는 악덕 클라이언트가 많다라는 것이구요.

그것을 윗선에서는 칭찬하고 성과로 인정하기 때문에 기술자들이 헐값에 기술을 팔아야하는 것이 바로 고질적인 문제죠..

3. 기능목록서를 제작합니다.

 - 기획자와 개발자의 역할입니다.

 · 기능목록서를 세세하게 제작해야 합니다. 그것은 SOW(Statement Of Work)를 제작하는 기초가 되는 것입니다. 

  SOW는 WBS를 제작하는 기초가 됩니다.

 · 예를 들어 Q&A 게시판을 제작한다고 가정했을때 무엇을 개발하는지 분해하는 것입니다.

  1) 리스트 

  2) 등록

  3) 수정 

  4) 삭제

  5) 상세

  이런식으로 개발하는 단위 하나하나에 대한 세부 기능 단위를 분해하는 것이 기능목록서입니다.

4. WBS 제작

 - 툴을 사용합니다.

  · Microsoft Project를 사용할 수 있습니다.

좌측에서부터 SOW를 3DEPTH까지 내려가게 합니다. 

각 SOW마다 들어가는 시잔을 작성합니다. 

끝! 참 쉽죠?

  · Microsoft Excel을 사용할 수 있습니다.

저는 대부분 프로젝트보다 엑셀을 많이 사용합니다. 예전에 만들어 놓은 함수나 조건부서식을 이용하여 간단하게 제작할 수 있어서예요.

필요하신 분들위해 샘플로 하나 올려드릴께요~

엑셀 조건부 서식에서 해당하는 사람 이름을 적고, 엑셀 시트에 담당자 부분에 이름을 적습니다. 그리고 시작일, 종료일이 적으면 그 날짜에 해당 색깔로 표기 됩니다. 

참고로 중간을 띄워서 작성해야만 함수랑 조건부 서식이 먹히니까요 다음 줄 추가해서 쓰지 마시고 중간을 띄워서 쓰세요.

참 쉽죠?

우리가 웹 사이트 구축이라는 프로젝트가 있다고 가정할때의 투입해야하는 기술자는 평균적으로 아래와 같습니다.

1. PM : Project Manager의 약자입니다. PM은 프로젝트의 모든것을 총괄하는 사람으로 모든 방면의 지식을 고루 

         갖추고 있어야 하며, 영업적인 부분까지도 손을 뻣어야 하는 사람이예요.

         이 직책은 인적자원관리부터 아주 자잘한 경비관리까지 담당하는 사람입니다. 제일 높은 사람이라고 생각될 수 

         있습니다만, 누구도 하지 않는 일을 도맡아 해야하며, 뒷정리와 뒷수습을 모조리 해야하는 직책입니다. 

2. PL : Project Leader의 약자입니다. 아키텍쳐가 가능한 사람이 이 PL이라는 직책을 맡게 되는데요. 경우에 따라서 

        기획, 개발 또는 단위 사업마다 PL을 지정하기도 합니다. 이 직책은 PM처럼 자질구레한 일들을 하지 않아요.

        프로젝트가 시작하면 어떻게 구현해야 하는지 DB설계, 프로세스 설계, 시나리오 설계 등 개발자들에게 또는 기획자

        들에게 시작하기 전에 방향을 잡고, 이끌어 가야하는 사람입니다. 품질관리 측면에서도 굉장히 중추적인 역할을

        해야하는 사람이죠! 

        프로젝트마다 다르겠지만 사실상 PL이 연봉이 가장 높은 경우도 있습니다.

3. 기획 : 기획자는 이 프로젝트가 시작하면 가장 먼저 투입해야하는 사람입니다. PL과 협의하여 프로젝트의 방향을 논의하고

          분석, 설계, 벤치마킹, 프로세스설계, 시나리오설계, 화면기획(이용자, 관리자 등), 테스트문서 작성 및 각종 문서,

          매뉴얼 작성, 교육자료 작성 등 기획적으로 생각하는 일보다는 문서처리와 동시에 행하는 사람이라고 생각하는것이

          좋을 것 같습니다.

4. 디자이너 : 디자이너는 프로젝트의 각종 디자인을 진행하는데요. 가장 중추적인 역할은 화면기획에 맞추어 디자인하는 

               직업입니다.

5. 프론트앤드개발 : 디자인이 나왔다면 그것은 HTML로 만들어야겠죠. HTML로 작성하고 역동적인 부분은 

                      자바스크립트(JavaScript로구성하며, 더 나아가 아작스(Ajax), 제이슨(Json), 제이쿼리(jQuery) 등을

                      작업할 수 있습니다. 경우에 따라 이사람들을 퍼블리셔라고 부르는 경우도 있습니다.

6. 백앤드 개발 : 개발언어에 따라 asp, .net, jsp, php 등의 개발자가 투입되며, 각 프로그램을 담당합니다. 물론 이 사람들은

                  PL의 주도하에 움직이는 경우가 많죠.

이러한 사람들이 움직여서 하나의 프로젝트를 완수하게 되는데요. 가장 처음 시작하는 것은 내부미팅 및 WBS의 작성입니다. 

WBS는 다음 파트에 설명드릴께요~

사업수행계획서는 이미 어떻게 써야한다고 나와있습니다.

그리고 그 목차를 이용하여 작성하면 되는거죠!

저는 나름대로의 틀을 만들어 재활용하고 있습니다. 

사업수행계획서는 정해진 틀안에서 제출하면 됩니다. 

1. 사업수행계획서의 목차

앞서 말씀들였듯이 목차는 정해져 있으며, 평균적으로아래와 같습니다.

=====================================

1. 사업개요

  가. 개요

  나. 조직도

2. 사업 추진체계 및 추진일정

  가. 사업 추진 조직도

  나. 추진 일정

3. 사업 계획

  가. 추진계획

4. 산출물계획

  가. 업무 기간별 산출물

  나. 최종보고서 제출 목록

5. 보고계획

6. 품질관리계획

  가. 품질관리 전략

  나. 품질보증 절차

7. 보안대책

  가. 보안관리 개요

  나. 대상별 자료 관리 대책

8. 교육계획

  가. 교육훈련 조직

  나. 교육훈련계획

  다. 교육훈련 절차 및 방법

9. 기술적용계획표

=====================================

2. 작성법

하나하나 설명을 드려볼께요. 일단 목차를 쉽게 만들기 위해 한글을 이용하면 좋습니다.

-개요

· 사업명

· 사업기간

· 계약방법

· 추진목표

· 추진전략

-조직도

· 회사내 조직도

· 사업참여 조직도

사업참여 조직도는 아래와 같은 틀을 사용합니다.

-추진일정

추진일정은 WBS를 미리 짜놓았다면 WBS를 첨부해도 좋고, 간단한 일정 정도로 나열해도 무관합니다.

-사업계획

· 최초 우리가 제안서를 작성할 때 만들었던 기능 요구사항을 나열하세요. 

· 그에 따른 시기를 나열합니다.

-산출물

· 기본

· 추가 과업지시상 산출물 나열

-보고계획

-품질관리계획 부분

이 부분은 정형적은 부분입니다. 항상 똑같은 부분이죠.

1. 품질관리계획

1.1. 품질관리 전략

보안을 준수 하며, test 시연을 함으로서 품질 관리에 만전을 기함.

1.2. 품질보증 절차

2. 보안대책

사업과 관련된 이해관계자 및 유관기관의 정보자산을 보호하기 위해 관리적, 물리적, 기술적 보안정책을 수립하고, 보안관리와 관련된 역할과 책임을 명확히 하며 발생 가능한 보안 위험요소들과 취약점을 사전에 파악하여 그 대응책을 마련합니다.

2.1. 보안관리 개요

2.2. 대상별 자료 관리 대책

2.2.1. 관리적 보안

2.2.2. 물리적 보안

3. 교육계획

교육훈련은 단위사업 및 전체 사업을 효과적으로 수행 할 수 있습니다. 따라서 사업착수부터 사업 완료 시까지 운영에 필요한 기술교육을 할 수 있도록 하겠습니다.

3.1. 교육훈련 조직

3.2. 교육훈련계획

- 기술적용계획표

이부분은 과업지시서 또는 제안요청서에 있는 기술적용계획표를 삽입하면 됩니다.

간단하게 사업수행계획서를 작성하는 방법에 대해 알아봤습니다!

제안발표 이후 우리는 바로 계약하는 것이 아닙니다.

제안발표에서 1등을 한 경우 우선협상대상자가 되는 것이죠.

우선협상 대상자란 말 그대로 우선적으로 협상을 할 수 있는 대상자라는 것입니다. 

만약 협상이 결여되면 2등한테 협상대상자를 양보해야 하는 것입니다.

저도 경쟁에서 2등이 되었던 사업에 위와 같은 사유로 계약한 경우도 있습니다.

우선협상 대상자에서 떨어지는 경우는 여러가지 이유가 있는데 대표적으로 아래와 같습니다.

1. 실제 투입될 수 없는 기술자(요원)으로 제안했을 경우

  - 점수를 위해 실제 투입될 수 없는 기술자로 제안했을 경우 1등이 되었을 때 제안서에 있는 인원이 들어가야 하는데도

    불구하고 그렇게 하지 못할 때에는 협상대상자에서 제외됩니다.

2. 요구사항 협상에 실패했을 경우

  - 발주처에서 요구하는 요구사항이 제안요청상에는 없었으며, 너무 터무니없는 요구사항을 말한경우 제안사에서는 

    받아들일 수 없어 포기하게 됩니다.

3. 제안 당시 제안 PM의 추가 기능 수렴과 본사에서의 의견이 차이가 있을 경우

  - 제안 당시에는 심사위원들이 여러가지를 묻고 여러가지를 요청합니다. 예를 들어 이때 반응형 홈페이지로 만들어줄 수 

    있느냐는 말을 하고 제안 PM이 그를 수용했다면 해당 내용은 녹취되며 구두로서 묶이게 됩니다. 협상이 반드시

    이 내용이 나올 것이며, 만약 그 후 본사에서 그를 수용할 수 없다면 포기할 수 밖에 없는 것이죠.

대표적으로 이 같은 이유로 우선협장 대상자에서 제외 되는 것입니다.

이런 저런 얘기로 협상을 진행한 후 협상서에 도장을 찍습니다. 이로써 협상이 완료 되는 것이죠.

협상서는 아래와 같은 방식으로 제작됩니다.

그 후 계약입니다. 

계약서에 도장만 쾅하고 찍으면 되는 것이 아닙니다. 제출 해야 하는 서류가 굉장히 많죠.

보통의 계약은 계약 후 7일 이내에 착수하여야 하며, 착수 후 7일 이내에 착수 서류를 제출해야합니다.

착수 시 제출해야 하는 문서를 말씀드리자면!

1. 착수문서 

 1) 착수공문

   가. 착수계

   나. 사업수행계획서

   다. WBS

   라. 용역책임자계

   마. 조직도

   바. 비밀유지계약서

   사. 산출내역서

   아. 하도급 비율 명세서

   자. 비상연락망

 2) 하도급 서류

   가. 하도급 계약서 및 계약 승인신청서

   나. 하도급 계약서 안

   다. 하도급 적정성 판단 자가진단표

 3) 인력서류

   가. 경력증명서 및 학력증명서

   나. 기본증명서

   다. 신원진술서

거의 모든 문서를 적었는데요. 저 중에서 필요한 서류만 제출 하시면 됩니다.

제안서를 작성하기 전단계까지는 아직 이해관계자와의 협의나 미팅을 진행하지 않았습니다.

일단 제안서 작성 단계 전까지는 혼자서도 할 수 있는 작업입니다. 

1. 이제는 이해관계자들을 소집해야 합니다.

제안서를 작성할 때 여러가지 타입이 있습니다.

1) 공동수급 : 2개이상의 회사가 공동으로 본 사업을 수급할 때

2) 하도급 존재 : 원도급과 하도급이 존재하는 사업으로 하도급에게 하달해야 할 때 

2번과 같은 경우 큰 사업은 각 각 파트별로 하도급 업체가 존재하기도 합니다.

여러 이해관계자들이 있지만 샘플 사업은 1개의 회사만으로 충분히 진행할 수 있는 사업입니다.

한개의 회사만이 진행하는 사업의 이해관계자들은 어느정도 아래와 같습니다.

1. 사업의 PM 

2. 개발 PL

3. 기획 및 제안서 작성자

4. 디자이너

5. 프론트 엔드 개발자

6. 경영지원부

사업의 PM은 해당 제안서의 전체적인 틀을 잡고 수행하는 기간 산정, 인력 선정, 정량적 점수 및 정성적 점수 계산 등

전체적인 부분에 업무를 수행합니다.

개발 PL은 기능파트에 개발적인 부분에 대한 제안서 작성과 시스템 구성도 및 개발방법론 등에 대한 부분을 작성하죠

기획자는 시안에 들어갈 화면 기획과 기획이 필요한 제안 파트를 담당합니다. 

나머지 제안서를 채우는 일은 제안서 작성하는 사람이 작성하겠죠.

기획자의 시안 기획서가 작성되면 디자인을 해야 합니다. 

그리고 제안서의 전체적인 디자인 작업을 진행합니다. 본 샘플 사업은 온라인 제출이나 오프라인 제출 같은 경우

3공바인더로 제출 또는 제본으로 제출하기에 표지 디자인, 목차, 간지, 내용부분에 대한 전반적인 디자인을 진행합니다.

물론 PPT 디자인을 전문적으로 하는 회사도 있습니다만 비용문제로 잘 사용하지는 않습니다.

프론트 엔드 개발자는 상황에 따라 디자인 시안을 HTML로 만들거나 제안 내용 중 웹접근성 웹표준 및 호환성 부분에 대한

도움을 받을 수 있습니다.

경영지원부에서는 인력에 대한 서류 및 연락 체계구성과 체크리스트로 만들었던 서류를 준비하죠.

이렇게 각자의 역할을 말하고 기간을 산정하고 각자가 맡은 역할을 충분히 수행하면 되는 것입니다.

2. 제안서 작성 템플릿 공유

 1) DEPTH 선정

관공서에서 공문을 작성할 때 사용하는 특수문자가 있습니다. DEPTH를 구분하기 위한 특수문자인데요. 

순서는 □, ○, -, · 입니다. 이러하듯 우리도 제안서를 작성할 때 DEPTH의 구분을 정해야 합니다.

샘플 제안서에서는 대메뉴 Ⅲ 이후 1. 1) 가. 가)  -  · 로 정합니다. 최대 6 DEPTH까지로 정하며 그 이하는 

사용하지 않는 것으로 정합니다. 저 부분은 모두에게 공유되어야 하는 부분입니다.

2) 템플릿 공유

템플릿은 아주 단순하게 단조롭게 작성하는것이 가장 좋습니다. 

간단하게 템플릿을 만들어보았습니다.

  이렇게 만들어진 PPT 파일을 이해관계자에게 보냅니다. 그 후 제안서가 돌아오기를 기다리면 되겠죠!

3) 이 후 제안서는 목차에 맞추어 차례차례 작성하면 되겠습니다!

4) 다 취합된 제안서를 가지고 한 파일로 합치고 제안서를 완성합니다.

3. 제안 요약서 작성

제안요약서는 제안서를 따다가 붙이는 작업이 아닙니다. 최대한 압축하여 여러장에 있는 중요한 부분을 넣어야 합니다.

 1) 방식을 정해야 합니다.

   - 사실 제안발표 때에는 중요한 기술 부분과 관리 부분을 주요사항으로 봅니다. 따라서 그런 목차로 지정하는 방법이 

     있습니다. 제안요약서는 목차가 정해져 있지 않기 때문이죠!

   - 또는 제안서 순서대로 요약하여 요약서를 작성할 수도 있습니다.

   - 또는 평가의 기준대로 요약서를 정성할 수 있습니다. 아래는 평가 기준입니다.

제안요약서는 대부분 가로형으로 제작합니다.

템플릿을 이런식으로 만들 수 있습니다.

제안요약서는 제안 PM과 기획자가 작성합니다. 그 이유는 제안 PM은 발표하는 사람으로서 어떻게 발표할지 시뮬레이션을

하면서 작성해야 하기 때문입니다. 그리고 기획자가 말해주는 기획의도도 명확히 인식해야하기 때문에 기획자와 같이 

작업합니다.

4. CD 및 인쇄

이 부분까지는 내려가지 않을 수도 있지만 혼자 제안서 작업을 하는 경우도 종종있기 때문에 CD제작과 인쇄까지도 담당해야

하는 경우도 있습니다. 

물론 샘플 사업에 경우 온라인으로 발표를 하는 것이라 인쇄를 할 필요는 없습니다만 참고사항으로 말씀드리자면

CD안에는 제안서, 제안요약서, 각종 문서를 담아가야 합니다. 

인쇄시에는 담당 인쇄소가 있는 경우 쉽겠지만 그렇지 않은 경우는 반드시 3공바인더인지 떡제본은지를 말해주고, 몇 부를

인쇄할지를 말해줍니다. 

인쇄소 관계자는 3공바인더를 먼저 제작하기 때문에 표지파일을 먼저 원할 것입니다. 표지파일을 미리 준비해주세요.

그리고 디자인 시안을 A3로 인쇄할 때는 반드시 얘기해줘야 합니다. 

그리고 중요한 부분은 제안요청서에 흑백인지 양면인지 등에 대해 나와있기에 이부분도 놓치지 말고 지켜줘야 합니다.

대부분은 아래와 같습니다.

제안서 : 3공 바인더, 양면인쇄, 세로형, 흑백인쇄

제안요약서 : 스프링 인쇄, 단면인쇄, 컬러인쇄, 가로형

이렇게 됩니다. 

여기까지 제안서 작성하는 방법에 대해 마치겠습니다.

PS. 원본과 평가본을 제출하라는 곳에는 평가본에 회사를 알 수 있는 정보를 일체 삭제해야 합니다. 

     실격처리 될 수 있습니다.

사실 제안서를 작성하기 위한 기본적인 목차는 기재 되어 있습니다.

2장에서 말씀드렸듯이 제안서의 목차는 정해져 있습니다. 

그 안에서 세부적으로 어떤 내용을 작성할지 목차를 정하는 거예요.

여기서 우리는 제안서를 작성하기 위해 정해야 하는 것들이 있습니다.

1. 제안서의 DEPTH를 정해야 합니다.

  1) 제안서의 깊이를 말하는 건데요. 예를 들어 기능 요구사항이 아래처럼 있다고 가정합니다.

목차를 작성해 볼께요.

위처럼 요구사항의 내용을 보고 목차를 세부적으로 잡아야 합니다. 

페이지 수는 왜 적었냐하면 제안서의 분량이 딱 정해저 있거든요. 그래서 목차를 잡을 때 페이지 수를 써서 넘치지 않게 

작성하기 위해서 입니다.

간단하죠? 이렇게 제안서 목차를 만드는 것입니다!

우리나라에는 나라장터라는 곳이 있습니다. 

나라장터에 대해서 설명할 것은 아니기 때문에 나라장터에 대해 궁금하신 분들은 이곳을 클릭 하시면 알 수 있습니다.

나라장터의 주소는 http://www.g2b.go.kr/index.jsp 입니다.

나라장터에는 많은 공고가 올라오고 있습니다.

국가기관에서 올라오는 공고는 여러 검증단계를 거쳐서 공무원이 일을 끝낸 순간부터 약 1달 후에 입찰공고가 올라옵니다.

우리는 웹 기획에 대해 이야기를 할 것이기 때문에 홈페이지를 검색해서 적당한 공고를 한번 살펴 볼께요.

여러가지 정보는 모자이크 처리 하였습니다.

우리가 봐야 할 것은 기본정보 후에 첨부파일 입니다.

가장 중요한 문서 2개는 공고서와 제안요청서입니다.

1. 공고서 살피기

  1) 입찰자격을 파악한다.

     - 현재 재직중인 회사가 입찰자격을 갖추고 있는지 확인해야 합니다. 물론 나라장터에서 보시는 경우라면 당연히

       입찰자격을 갖추고 있을 것입니다.

  2) 제출 서류를 파악한다.

     - 기획자는 일일이 하나하나 챙겨야 합니다. 어떤 서류를 내야 하는지 체크리스트를 만들어야 합니다.

       체크리스트는 1차와 2차로 나뉘어 작성합니다. 1차는 공고서를 보고 작성합니다.

     - 아래는 공고서 내에 있는 제출 문서 목록입니다. 그대로 엑셀파일로 옮기세요.

--------------------------------------------------------------------------------------------

    - 엑셀로 옮겼습니다. 기획자의 기본은 엑셀을 다룰때 언제나 연번을 취급합니다. 

    - 이 문서에는 해당 문서를 어디서 보았는지 출처를 적고, 누가 준비해야 하는지 특이사항은 없는지 작성합니다.

    - 확인란은 제안서 제출 전 체크리스트를 활용하여 체크하기 위함입니다.

    - 정량적 제안서 : 간단하게 회사의 기본 속성입니다. 바뀌지 않는 회사의 속성에 대해 작성합니다.

                        어떤 내용을 쓰는지는 제안 요청서에 나옵니다.

    - 정성적 제안서 : 기술적인 부분과 관리사항 등 회사정보가 아닌 부분을 작성합니다.

    - 제안요약서 : 제안서에 기술된 내용을 함축하여 작성합니다.

    - 발표자료 : 제안발표 시 필요한 자료를 작성합니다.

 2. 제안요청서 살피기

    제안요청서는 머하나 중요하지 않은 부분이 없습니다. 반드시 한번은 정독해야 합니다.

   1) 제안요청서 상에서 필요한 문서 목록을 체크리스트에 작성합니다.

      - 제안요청서에도 필요한 문서를 적어 놓았습니다. 애써서 제안서 작성했는데 문서때문에 제안서를 제출조차 할 수 없을

        때도 있습니다. 꼭꼭 살펴야 합니다.       

    - 목록이 늘었습니다. 해당 공고는 온라인 제출과 온라인 발표로 되어 있습니다. 오프라인 제출과 오프라인 발표일 경우

      입찰참가신청서, 인감증명서, 사용인감계, 청렴서약서 등 제출해야 될 문서가 더 있습니다.

   2) 제안서 목차 보기

     - 제안요청서에 신경쓰는 공무원이었다면 정량적 제안서 목차와 정성적 제안서 목차를 따로 정리하는데 조금

       이상한 부분이 있습니다.

     - 정량적 평가 제안서에 첨부되는 서류는 제안요청서에 따로 작성되어 있습니다.

    - 제안요청서를 보아하니 제안서는 정량,정성 모든 부분을 담고 정량적평가 제안서를 별도로 취합해서 제출하는것이 

      좋을 것으로 판단됩니다. 이럴 때에는 담당자에게 문의하여 어떻게 할지를 반드시 확인 해야 합니다.

   3) 요구사항 확인하기

    - 요구사항은 이렇게 아이디와 명으로 되어 있고, 해당 표 아래에 자세히 작성되어 있습니다. 

    - 뭔가 요구사항이 많아 보이지만 사실 그렇지 않습니다. 기능 요구사항 외에는 모두 정형적인 내용이며, 항상 나오는

      요구사항입니다.

이렇게 제안요청서에서 자세히 살펴봐야 할 것을 봤습니다.

개인적으로 처음 제안서를 작성할때 제안요청서는 글자가 지워질때까지 봤던것 같아요.

제안요청서에 글자 하나를 놓쳐서 낭패를 격는 경우도 있으니 주의하시면서 필독 또 정독하세요.

블로그를 하면서 내가 생각하는 기획이란 무엇인지를 말하고 싶었습니다.

그래서 이제부터 저를 먹여살리고 있는 기획에 대해서 하나하나 말해볼까 합니다.

이제 막 기획을 시작하시는 분들에게 많은 도움이 되었으면 좋겠다는 마음으로 글을 써봅니다.

사실 제가 사회에 나와 처음 '기획자'라는 직업을 선택한 것은 할것이 없어서 였습니다.

뭔가 김빠지는 얘기죠?

기획자라는 것은 생각하는 직업이라고 생각했기에 별다른 기술이 없던 저는 기획을 해봐야 겠다는 생각을 막연하게 

가졌던거예요. 

하지만 한해 한해 지나고 계속 기획이라는 일을 하면서 느끼는 것은 기획은 기술직이라는 거예요. 전문적인 기술직이요.

굉장히 프로페셔널해야 하며, 다방면으로 알고 있어야 하고, 영업적으로도 탁월한 능력이 있어야 하는 것입니다. 

그리고 더 중요한 것은 인간관계와 인내심이 가장 중요합니다.

기술적인 부분은 인간관계보다 나중에 자기개발되도 되는 부분이라 생각해요. 

그리고 많은 클라이언트와 내부적인 이해관계자들과의 의사소통과 분쟁등에 익숙해야 하며, 절대로 화를 내거나 짜증을

내면 안되며 항상 웃는 얼굴로 모든 이를 대해야 한다는 점에서 인내심도 중요한 부분이예요. 

기획자는 절대 혼자서 일할 수 없는 사람입니다. 

본론으로 들어가서 이제부터 제가 할 이야기는 기획과 PM의 모든 업무에 대해 다룰것입니다.

어떤 주제를 가지고 기획을 설명할까를 고민해봤는데요.

여러분들은 G2B 나라장터를 알고 계신가요? 

나라장터에서 적당한 과업을 가지고 시물레이션을 하는 것이 좋을 것 같다 생각했습니다.

그럼 이제부터 기획에 대한 이야기를 시작해 볼께요.