[웹기획가이드] RFP, 어떻게 써야 할까요? - 작성편(1)

야메군
2021-02-11
조회수 12253

웹기획자.. 혹은 웹 사이트 제작을 위해 에이전시나 SI업체에 웹사이트 구축 작업을 맡겨야 하는 의뢰업체 담당자가 자주 접하는 용어 중 하나인 RFP.. 그런데, 의외로 이 RFP를 처음 접하시는 분이 많은데 반해, 해당 문서의 해석방법이나 작성방법을 잘 모르시는 분들이 계시는 듯 하여, 오늘은 RFP에 대한 정의와 함께 RFP 작성요령에 대해서 한 번 살펴보도록 하겠습니다. 





RFP(Request For Proposal)는 제안요청서라고도 하는데, 웹 사이트나 솔루션을 구축하고자 하는 클라이언트가 에이전시 또는 SI업체 측에 '우리는 이렇게 만들고자 하는데, 작업이 가능하다면 제안을 넣어달라.'는 의미의 컨셉정의서라고 볼 수 있습니다.  컨셉정의서라고 하니 마치... 세련되고 미래지향적이며, 사용자 친화와 같은 관념적이고 추상적인 키워드의 나열 정도로 가볍게 생각하실 수도 있겠지만, 그런 단순한 정보만으로는 제안을 넣을 업체는 없으며, 제안업체가 제안 참여를 위해 판단할 수 있는 지표가 보다 구체적이고도 정확히 정리되어야 이를 근거로 클라이언트의 의도에 맞는 제안을 할 수가 있습니다.

 

 

그럼, 이 RFP에 들어가야 할 내용들을 한 번 살펴보도록 하겠습니다.  RFP의 내용은 크게 개요, 구축컨셉, 제안요청사항 정의, 제안서 작성가이드 정의가 들어가게 되는데, 개요단계에서는 프로젝트의 기본정보를 전달하며, 프로젝트 명과 서비스의 성격을 정의하고 만드는 목적과 추구하는 방향성을 정리하는 수순으로 진행되는데, 개요 이후에 정리하는 세부사항을 위한 안내 정도로 생각하면 되지만, 그렇다고 이 개요 부분을 간과하고 넘어갈 경우, 세부항목이 틀어지는 경우가 발생할 수도 있으므로, 가장 많은 생각이 필요한 영역이기도 합니다.

 

 

개요 - 우리가 이 서비스를 만들어야 하는 이유?!

 

개요항목에서는 먼저 프로젝트(사업) 명을 작성하셔야 합니다.  프로젝트 명은 직관적이면서 노멀한 수준으로 작성하시면 되는데, 예를 들어 "XXXXX 쇼핑몰 구축"과 같은 정도로 정리하시면 됩니다.  그 다음, '사이트의 성격정의' 즉, 하고자 하는 서비스의 이름이나 서비스의 형태를 짐작할 수 있는 한 문장의 명확한 정의.. 예를 들어, 'SNS를 기반으로 한 관계지향형 동영상 컨텐츠 서비스' 같이 만들고자 하는 서비스의 형태를 정의해주셔야 하는데, 꽤 많이 확인되는 실수 중 하나가 이 사이트의 기본적인 정의가 이루어지지 않는다는 것입니다.  어찌보면 형식적이고 의례적으로 넘어갈 수 있는 부분일 수도 있으나, 실상 RFP를 이루는 요소 중 가장 중요한 내용이며 이 정의를 통해 '우리가 원하는 서비스'를 어필할 수 있는 것이죠. 

 

그 다음  '왜 이 사이트를 만들어야 하는가?'에 대한 제작 목적을 정의해 줌으로서, 제안업체에서 제안 시에 단기적인 목표냐, 장기적인 목표냐 등을 파악할 수 있습니다.  '아니.. 왜 만들어야 하는지까지 이야기 해야해?' 하고 반문하시는 분도 계시겠지만, 그 반문에 대해 전 이렇게 되묻고 싶습니다.

 

"아니... 만드는 이유도 하나 없이 그냥 만드는거야?!"

 

아무런 이유도 없이 웹사이트나 어플리케이션을 만들지는 않을 겁니다.  분명 회사가 원하는 어떠한 목적이 하나쯤은 있을 겁니다.  새로운 시장을 구축하기 위해서라거나, 홍보나 마케팅 측면을 고려했다거나 하는 목적 말이죠.  형식적이어도 좋습니다.  어떠한 목적으로 해당 프로젝트를 진행하며, 이를 통해 얻고자 하는 것이 무엇인지를 정의해줘야 RFP를 보고 입찰할 업체가 목적에 따른 방향성을 잡고, 제안을 할 수가 있습니다.  그럼 예를 한 번 들어보죠.

 

이번 XX 프로젝트는 오프라인 상에서 확고하게 자리잡은 회사의 브랜드 이미지를 온라인 영역으로 확장하여, 브랜드인지도 및 가치를 확보하고, 대고객 친화적 환경 구축을 통해 "고객 중심의 기업"이란 부가적 이미지를 심어주는데 그 목적을 가진다.

 

위의 목적을 살펴보면, 왜 프로젝트를 진행하는지에 대한 몇 가지 포인트를 확인할 수 있습니다.  첫째로 오프라인에서는 인지도가 높지만 온라인 시장에서는 인지도가 부족하다는 점, 둘째로 고객과의 직/간접적인 접점을 필요로 한다는 점이 그것인데, 비록 형식적이라 할 수 있지만 이 두 가지 정보가 참여업체에게 전달되느냐, 아니냐에 따라 원하는 결과를 만들어낼 수 있는가가 결정되게 됩니다.

 


분류

내용

 개요

프로젝트 명

 프로젝트(사업)의 공식적인 명칭.

성격정의

 구축하고자 하는 사이트(서비스)의 성격을 정의.

사업목적/목표

 어떠한 목적으로 이 사이트를 제작하며, 이를 통해 무엇을 얻고 싶은가?

구축방향

 큰 맥락에서 갖추고자 하는 사업의 키워드들을 정리하고, 키워드 별 설명을 작성.

진행일정

 언제 시작할 수 있어야 하고, 언제까지 완료해야 하는지를 정리.

 구축컨셉 및 타깃 정의

구축컨셉

 추상적이지 않은 구체적인 컨셉 제시.

주요타깃

 이용이 예상되는 주요 타깃. (성별/연령/포지션 등)

레퍼런스

 서비스의 전반적인 윤곽을 확인할 수 있는 참고할만한 서비스 기재.

 제안요청 사항 정의

 사용자환경

 사용자가 접근하는 영역의 개략적인 사이트맵.

 관리자환경

 사내 백오피스(Backoffice)에 접근하는 관리자 영역의 개략적인 사이트맵.

 서버 및 개발환경

 서버구축 제안 및 IDC 환경 등에 대한 포괄적인 제안 요청.

유지보수 조건 

 개발완료 후, 유/무상 유지보수 기간을 설정하고, 장애 발생에 따른 대처와 책임소지 기재. 

 교육 및 기술이전

 관리자가 해당서비스를 운영하기 위한 운영교육에 대한 요건 기재.

 진행산출물 제시

 착수보고서/정기보고서/완료보고서 등의 정의와 완료 시 제출해야 할 자료항목 정의.

 기타 협의 이슈

 위의 내용에 언급되지 않은 일반적인 전달사항과 인력 상주 등의 요건을 기재.

 제안서 작성 가이드 정의

제안 프로세스

 제안서 제출 이후, 어떤 과정으로 제안검토가 진행되며, PT 절차 등을 정리. 

제안서 포함내용

 일반적으로 회사에서 요구하는 제안목차를 정리하고, 필수/선택 제출항목과 서류 분류.

선정기준

 회사에서 제안참여 업체의 제안내용을 어떤 기준으로 선정할 것인지의 개략적 가이드 제공.

진행일정

 제안요청서 공고와 제안서 제출일정, 검토기간, PT 일정 및 최종 선정 스케줄 정리.

 담당자정보

 제안서를 받거나 피드백을 줄 수 있는 담당자의 이름/부서/직급/연락처/이메일정보 기재.



 

이러한 목적이 정의 되었다면, 프로젝트의 방향성을 정리할 필요가 있습니다.  보통 이 방향성을 정리하기 위해서는 프로젝트의 핵심이 되는 주요 키워드를 뽑고 이 키워드를 중심으로 전개해 나가면 되는데, 큰 줄기에서 다뤄야하는 서비스의 특징이나 이슈요소를 뽑고 이를 간략하게 설명하면 됩니다.  예를 들어, "운영관리의 최소화"라는 구축 키워드가 있다면, 여기에 "관리체계의 자동화를 통해 적은 운영인력의 효율적 서비스 운영 체계마련" 정도로 정리하시면 되겠습니다.  서비스의 방향성과 유사한 내용으로 아래에서 설명할 구축컨셉이 있는데, 두 내용이 어느정도 중첩되는 부분도 있으므로, 둘 중 하나만 정리하셔도 되겠습니다.

 

방향성이 정리되어 있지 않았을 때의 문제점.. 어떤 게 있을까요? 


 

그 다음, 프로젝트의 개발 일정을 정리해주면 됩니다.  언제 스타트해서 언제 완료하고 얼마만큼의 검수와 테스트를 거쳐서 언제 오픈하겠다.. 이런 내용이 들어가면 되겠습니다.

 

 

구축컨셉과 타깃정의 - 우리 서비스의 핵심적인 방향!!

 

앞에서 정리된 개요가 프로젝트나 사업에 대한 개략적인 정보전달의 의미라면, 구축컨셉과 타깃을 정의하는 과정에서는 보다 구체적인 내용들을 정리해주셔야 합니다.  먼저 구축컨셉은 앞서 정리한 개요의 구축방향에서 개략적으로 언급한 이슈들을 세분화하여 보다 구체적으로 정리해 줄 필요가 있는데, 예를 들어 "직관적이고 간결한 사용자 환경" 이라는 키워드가 있다면, 여기에 어떻게 직관적이면 되는지를 정리하는 식.. 예를 들어, "사용자가 핵심 컨텐츠를 이용하는데 최소의 클릭으로 목적을 달성할 수 있어야 하며, 표현 문구가 어렵지 않아야 함." 같은 내용을 정리해주시면 되는데, 이러한 요구사항이 많을수록 구체적인 접근이 가능합니다. 

 


 

그 다음은 만들고자 하는 서비스의 주요 타깃층을 생각해 볼 필요가 있습니다.  만일 RPF 작성 이전에 사업기획이 정리되었다면 이미 타깃이 나왔겠지만, 그렇지 않은 경우... 명확한 사용자 층을 구분해내는 일은 쉽지 않습니다. 이 경우, 만들고자 하는 서비스와 유사한 서비스의 디자인적인 분위기나 게시판이나 SNS 등을 통한 유사 서비스 현황을 살펴보고, 근접하는 연령대와 성별을 기재하면 됩니다.  여기서 가능하다면, 리서치 등을 통해, 사전에 세밀한 타깃층.. 즉, 성별, 연령 뿐만 아니라 라이프사이클이나 포지션 등을 분석하는 것도 좋은 방법입니다.  언제 기회가 된다면 이에 대한 분석방법과 시나리오 작성방법도 포스팅 하겠습니다.

 

마지막, 레퍼런스 부분은 경쟁사나 서비스의 롤모델로 참고할만한 곳이 있다면 제안업체에게 이를 전달해 줌으로서, 보다 시각적이고 구조적인 측면을 보다 원활하게 이해시킬 수 있으므로, 참고할만한 서비스를 찾아보는 것도 좋은 방법입니다. 오늘은 개요와 구축컨셉에 대한 내용을 다뤄보았는데요, 다음 편에서는 보다 구체적인 제안요청사항의 정리와 제안업체 측에 전달할 제안서 작성방법에 대해 자세히 설명 드리겠습니다.


출처: https://www.yamestyle.com/230 [야메의 이상한 생각과 공감] 

3 0

Data Chef.

datachef00@gmail.com

ⓒ 2023 Data Chef.

Hosting by I'M Datachef

Data Chef.
e-Mail

datachef00@gmail.com


Seoul, Korea  ㅣ  Biz License 000-00-00000  ㅣ Hosting by Datachef.