여기에서는 제안 작업을 해본 경험이 없는 프로그램머들을 위한 내용으로, 제안서의 작성 요령과 제안발표회 방법등을 이야기해 보자 

■ 제안서(Proposal) 

제안서는 영업하는 하는 과정에 필요한 것이지 프로그램 개발을 위해 필요한 것은 아니다. 
80년대까지만 하더라도 회사에서 필요한 프로그램은 자사에서 개발하여 사용하였으나, 90년대 들어와서는 필요한 프로그램을 구입하거나, 외부에 의뢰하여 개발하였다. 

따라서 프로그램을 전문적으로 만들어 주는 회사에서는 제안서를 만들어, 프로그램을 의뢰하는 회사에 제출해야한다. 제안서란 시스템을 어떻게 만들겠다고 상대방에게 제안하는 내용을 담고 있다. 

프로그램을 의뢰하는 회사는, 이 제안서의 내용에 따라 프로그램을 개발할 회사를 선정한다. 따라서 제안서를 잘 만드는 것은 매우 중요하다. 

■ 제안 요청서(RFP, Request For Proposal) 

보통의 경우에는 프로그램 개발을 의뢰하는 회사에서 개발해주는 회사를 몇개 모아놓고 자신들이 필요한 프로그램에 대한 설명을 말로 해준다. 그리고 나서 언제까지 제안서를 제출하라고 이야기한다. 
하지만 공공기관이나 대기업의 경우에는 이런 내용을 말로하지 않고 문서로 작성하여 배포한다. 이러한 문서를 제안요청서(RFP,Request For Proposal)라고 부른다. 

이러한 제안요청서를 배포할 때에는, 제안에 참가할 회사를 모아 놓고 제안요청서에 대한 내용을 대충 설명해주고, 질문을 받는다. 제안에 참가할 회사는 이때 가급적이면 많은 질문을 하여 많은 정보 - 평가기준, 투자예산, 선정기준, 제안서 분량 등 - 를 얻어 내는 것이 좋다. 

■ 제안서 작성요령 

제안서는 예전에는 일반 문서형태로 작성하였다. 그러나 최근에는 그림이 많이 들어가는 관계로 파워포인트(PowerPoint)를 이용해서 만드는 것이 일반화되었다. 
작성을 할 때에는 그림을 많이 활용하되 가급적 고급스럽고, 깨끗한 이미지릐 색상을 이용하는 것이 좋다. 

제안서의 분량은 20~50페이지가 적당하다. 하지만 수억원이 넘는 큰 프로젝트인 경우에는 수백 페이지가 넘는 수도 있다. 옜날에는 제안서의 분량이 크면 클수록 좋은 때도 있었다. 하지만 최근 들어서는 필요한 내용만 명확하게 언급하고, 상세한 내용이나 자료는 별도로 첨부하는 추세이다. 

제안서의 목차는 대체로 다음과 같다. 

목차 

제안 배경 

회사 소개 

제품 소개 

개발 실적(혹은 판매 실적) 

제안 내용 

개발 일정 

맺는 말 

별첨 : 견적서 
과 같은 순서로 하는 것이 무난하다. 각각은 대부분 1~3쪽 분량이 무난하나, 제안 내용은 10쪽 이상으로 길어질 수 있다. 각각에 대하여 하나씩 살펴보자. 

■ 제안 배경 

제안 배경에는 

■ 회사 소개 

회사 소개에는 주로 다음과 같은 항목을 넣는 것이 무난하다. 

회사명 : 회사의 정식 명칭 

대표자명 

주소 

연락처 : 대표 전화나 영업부 전화 번호, E-mail주소, 영업대표자명. 

회사 홈페이지 주소 

설립 년도나 회사 연혁 

종업원 수 

주요 사업 

년간 매출액 : 최근 몇년 간 실적이나 전년도 실적 

시장점유율 
이외에도 회사를 홍보할 수 있는 항목이 있다면 추가하면 된다. 

■ 제품 소개 

개발해 놓은 제품을 판매하는 회사라면, 이런 제품에 대하여 그림과 함께 소개를 하는 것이 좋다. 
하지만 개발만 한다면 이 항목은 생략해도 좋다. 

■ 개발 실적 

그동안 개발한 실적이나 판매 실적이 있으면 고객사들의 이름과 개발 내용을 간단하게 요약하여 소개한다. 
다음은 개발 실적 작성 예이다. 

- 현대 주식회사(2002.1~2002.7) : 사내 인트라넷 개발 
- 신신 여행사 (2002.5~2003.3) : 회사 홈페이지 개발(www.shin-shin.co.kr) 
- 미래 산업(2003.4~2003.8) : 회사 홈페이지 개발(www.e-miraesanup.co.kr) 

개발 실적은 많을수록 좋으나, 너무 많은 경우에는 대표적인 것만 나열하도록 한다. 
하지만 개발 실적이 몇줄 이내라면 회사 소개에 포함시키는 것이 좋다. 

■ 제안 내용 

제안 내용은 제안서의 가장 핵심이 되는 부분으로, 개발할 내용에 대하여 자세하게 서술하는 것이 좋다. 
정해진 항목이 있는 것은 아니나, 대략 다음과 같은 내용을 포함한다. 

시스템 구성도 

개발 범위, 방법 

주요 출력물 

개발 효과 : 직간접 효과에 대하여 자세히 서술한다. 


■ 개발 일정 

개발 일정은 개발할 항목을 단계별로 나누어 간트 차트 형태로 표현한다. 수억원이 넘어가는 대규모의 프로젝트라면 상세한 개발 일정이 필요하겠지만, 수천만원 단위 이하라면 한페이지 정도로 하는 것이 좋다. 


■ 맺는 말 

제안을 하게 해준데 대하여 고맙다는 말과 함께, 개발에 성심성의를 다한다는 말로 끝을 맺는다. 
이 부분은 생략해도 상관없다. 

■ 별첨 : 견적서 

견적서는 가격에 대한 내용을 포함하고 있으므로, 제안서 내에 포함하지 않고 별도로 제출한다. 
제안서는 여러 사람들이 보게되므로, 경쟁사에 유출될 수 있으므로 가격에 대한 이야기는 포함하지 않는 것이 좋다. 
또 제안서를 여러 부(복사본)를 요구하는 경우에도, 견적서는 한 부만 제출하면 된다. 

■ 제안서 발표 

제안서를 제출하면, 대부분의 경우에 제안서를 발표할 시간이 주어진다. 
통상적으로 제안서를 제출하는 날에 발표하는 경우도 있고, 아니면 제안서를 제출하고 난 2~3일 후에 하는 경우도 있다. 

제안서를 발표할 떄, 참석자의 제한을 두는 경우에는 제한한 범위내에 참석하는 것이 좋으나, 그렇지 않은 경우에는, 경험적으로 볼 때 가급적 많이 참석하는 것이 상대방에게 신뢰를 준다. 그리고 직급이 높은 사람이 참석을 하는 것도 상대방에 대한 예의로 볼 수 있다. 

복장은 가급적 양복으로 통일한다. 양복 색상은 여름철이라도 검정색이나 곤색 계통으로 하고, 긴팔 힌 와이셔츠를 입고, 구두는 검정색으로 신는 것이 무난하다. 이런 복장이 상대방에게 깨끗하고 고급스러운 이미지를와 함께 신뢰를 준다. 

발표할 자료는 미리 참석자 수만큼 프린트해서 제본해 둔다. 프로젝트 비용이 수천만원대를 넘어가면 가급적 컬러 프린팅을 해서 이미지를 제고하는 것이 좋다. 

일반적으로 제안서 발표시간은 30분에서 2시간정도이다. 
발표자가 이미 여러번 발표한 경험이 있으면 모르되, 처음 발표하거나 발표할 내용이 이전과 다른 내용이라면 미리 한두번 실제로 발표연습을 해보고 시간을 맞추는 연습을 해두는 것이 좋다. 

제안서 발표는 다음과 같이 한다. 

발표시간 30분 전에는 도착하여 필요한 장비가 모두 갖추어 졌는지 살펴본다. 그리고 제안서 사본을 미리 앉을 위치를 고려해서 탁자 위에 올려 놓는다. 
발표장에 창문이 있으면 커텐을 치고 실내등을 켜는 것이 듣는 사람들의 주의를 집중시키기에 좋다. 

점심시간 바로 직후라면 졸리기 쉬우므로 찬음료를 미리 준비하여 하나씩 나누어 주는 것도 좋다. 
만약 점심시간이나 저녁시간 직전이라면 간단한 다과를 준비하여 배고픔을 채워주는 것도 좋다. 심리학자들에 따르면 공복기에는 사람들이 공격적이 되기 쉽고, 포만감이 있을 때는 기분이 좋아지기 때문이다. 

발표하기 전에 참석자가 많은 경우에는 영업을 대표하는 사람이 나와 자신의 회사에서 참석한 사람을 한명씩 소개하는 것이 좋다. 시간을 끌지 않기 위해 이름과 부서, 직책("기술부 김경수과장 입니다") 정도만 소개하는 것이 좋다. 

한 사람이 모든 발표를 다할 수도 있으나 발표할 내용에 따라 2~3명이 할 수도 있다. 
예를들어 회사 소개와 같은 내용은 발표할 회사의 최상급자가 직접하고, 개발내용은 엔지니어가 하는 것이 그러한 예이다. 

발표 도중 질문을 하는 경우가 있다. 질문의 내용이 단답형으로 끝나는 경우에는 곧바로 대답을 해주는 것이 좋으나 답변이 길어지거나, 내용과 관련 없는 질문이라면, "답변이 길어질 수 있으므로, 발표가 끝난 후 별도롤 만나 답변을 드리겠다"고 정중히 거절하는 것이 좋다. 

특히 발표회에서 상대방의 꼬투리를 잡기 위해 하는 질문이 종종 있는데, 이런 질문에는 즉답을 회피하는 것이 좋다. "발표할 내용이 많아서 그러니, 발표가 끝난 후 개인적으로 만나 답변을 주겠다"고 이야기하고 빠져나가는 것이 좋다. 그러나 질문의 내용이 제안 내용과 밀접하게 관련되어 있고, 질문의 답변이 자신의 회사의 장점을 설명할 수 있는 기화가 된다면 아무리 답변이 길어지더라도 답변을 하는 것이 좋다. 

발표가 끝난 후, 가능하다면 걸상 정리, 쓰레기 치우기, 칠판 딲기 등을 하고 나오는 것이 좋은 이미지를 심는데 도움이 된다. 

■ 데모 

최근에는 인터넷을 발달로 제안서 내용을 발표하는데 그치지 않고 실제로 유사한 시스템을 보여줘야하는 경우도 많다. 이러한 데모를 하는 경우에는 반드시 데모 시나리오를 만들어 이 시나리오대로 몇번 연습해보는 것이 필요하다. 

나 자신을 비롯해 "평소에는 잘되는 것이 항상 데모만 하면 잘 안된다"고 푸념하는 엔지니어들을 너무나 많이 봐왔기 때문이다. 특히 데모에서 가장 문제가 되는 것은 시간을 맞추는 일이다. 따라서 연습을 할 때 시간을 맞추는 노력을 해야한다. 

데모에서 가장 중요한 것은 시나리오에 없는 것을 데모하는 경우이다. 종종 데모를 보는 사람들이 이런 것을 해보라 저런 것을 해보라고 요구하는 경우가 있는데, 이런 경우 실제로 해보이는 것보다 말로 해결하는 것이 최상책이다. "이렇게 하면 답이 이렇게 나옵니다"라든가, 아니면 "시간 내에 일단 데모를 다 보여 드린 후, 나중에 보여 드리겠읍니다"라고 피해가는 것이 좋다. 

그렇지 않고 그 사람들이 요구하는 대로 모두 보여주다가는 시간도 못 맞출 뻔 더러 실수를 하기 쉽기 때문이다. 데모를 하는 경우에 한번 실수가 생기면 당황하여 연속으로 실수가 생긴다. 또, 시스템 내에서 하나 꼬이면, 그것으로 인해 계속 문제가 꼬인다. 

따라서 원래 만든 시나리오에서 가급적 벗어나지 않는 것이 중요하다. 발표나 데모는 자기 페이스대로 가야지 절대로 상대방 페이스에 말려 들면 안된다. 

경험에 의하면, 나중에 끝나고 나서 별도로 답변을 하겠다거나 별도로 보여주겠다고 답변을 한 후, 끝나고 나서 답변을 요구하거나 보여달라고 요구하는 경우는 거의 없다. 다른 말로 표현하면 그런 질문이나 답변은 대부분 즉흥적이거나, 내용과는 상관 없이 자신이 잘난 체하려고 하는 데서 기인 하는 경우가 많다는 이야기이다. 

경험담 하나만 이야기 해보고 마치자. 

1980년대 초반에 IBM에 가보면 여자들이 데모를 하는 경우가 많았다. 그래서 " 왜 IBM에는 유독 여자들이 데모를 많이 하는지?" 그 이유를 물어본 적이 있었다. 그 답변은 대충 이러했다. 

남자들이 데모를 하는 경우 보는 사람(남자)들이 공격적이 된다고 한다. 예를 들어 실수를 하면 꼬투리를 잡고 늘어지거나, 안되는 것 을 뻔히 알면서 해보라고 시킨다. 하지만 여자들이 데모를 하면 반대가 된다고 한다. 만약 여자가 실수를 하면 흡사 자기가 실수를 한듯이 보는 사람이 더 미안해하고, 어려운 것이나 안될 것 같은 것은 절대 요구하지 않는 다는 것이다. 

그 이야기를 듣고 난 후, 데모를 볼 때마다 당시 그 답변을 떠올리면서 보았는데 실제로 그러했다. 
[출처] [펌] 제안서 작성|작성자 신의한수