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

안녕하세요?  야메군 입니다.

앞서 정리했던 RFP 작성법, 잘 읽어보셨나요?  오늘 다룬 2편에서는 1편에서 미처 다루지 못했던 제안요청 정의와 제안서 작성가이드 정리요령을 살펴보겠습니다.  앞단에서 구축컨셉과 타깃을 정의하는 과정을 설명드렸는데, 이 내용을 좀 더 구체적으로 정의한 자료가 바로 제안요청 사항 정의 항목 입니다.

제안요청 사항 정의 - 구체적이고.. 구체적이고.. 구체적이고..

 

제안요청 사항은 만들고자 하는 서비스의 사용자 페이지와 관리 페이지에 대한 사이트 맵 및 짚어주어야 할 유의사항을 정리해야 하며, 이를 개발하기 위한 개발환경에 대한 포괄적인 제안도 받아야 하는데, 처음부터 얼마 이내로 해달라는 금액 제한을 걸기보다는 먼저 최적환경의 제안을 받은 후, 금액을 조율하는 것이 바람직 합니다.  이 때, 가능한 경우 원하는 개발언어 환경이나 권장 서버환경을 가이드라인으로 제시해주는 것도 좋습니다.

 

 사이트맵은 만들어질 웹사이트의 페이지를 정의내리는 것을 의미합니다.

 

그 다음으로 하자보수 및 교육에 대한 항목을 정의해주셔야 하는데, 이 하자보수 항목은 다른 작성영역과 비교했을 때, 가장 디테일하게 정의해줘야 하며, 차후 하자보수 과정에서 갑과 을의 이견이 발생하지 않도록 세세한 정의와 검토가 필요합니다.  보통 하자보수 조건 항목에 들어가는 내용은 다음과 같습니다.

 

1. 유/무상 하자보수 기간.

2. 하자보수의 범위 : 어떤 항목들을 하자보수의 범주에 포함 시킬 것인가?

3. 장애 발생 시 업체의 대처방식과 시간.

4. 하자보수의 지연이나 잘못된 하자보수로 인한 책임 소지. (금전/기간연장 및 법적 분쟁 발생 시 대처방법.)

5. 내부 관리자가 해당 관리자 페이지를 운영하기 위한 교육일정 및 가이드 자료의 제출여부.

 

대략 이 정도 범위의 내용이 수록되는데, 하자보수 무상기간은 프로젝트의 성격이나 업체와의 조율에 따라 1~12개월 가량이 설정되는데, 여기서의 하자보수는 앞서 기획된 내용 중 결과가 미진하거나 혹은 기획된 내용을 바탕으로 개발/디자인 과정에서 빠졌더나 잘못 만들어진 부분에 대한 보수를 의미합니다.  때문에 사전 설정된 하자보수 기간 중에 요청할 수 있는 사항은 잘못된 내용에 한하며, 기능적인 추가개발 등은 하자보수의 범주에 해당되지 않으므로, 추가개발이 필요한 경우 개발업체와 충분한 협의가 필요 합니다. 

 

 

문제는 의뢰회사에서 하자보수로 요청하는 항목 중, 하자보수의 범주에 벗어나는 경우 입니다.  의뢰회사에서는 "하는 김에 좀 더 해주세요."라고 별게 아니라고 생각해서 요청하지만, 개발회사 입장에서 봤을 때 추가개발 요소일 수도 있는 만큼, 의뢰하는 입장에서 REP를 작성할 때 추가개발과 문제에 대한 보수의 개념을 좀 더 명확하게 정의하고, 계약 이후에 이 같은 문제로 분쟁이 발생하지 않도록 주의해야 합니다.

 

유지보수와 하자보수의 차이?! 

참고로 유지보수는 운영의 개념으로 사이트 내에서 발생하는 서비스의 기획, 디자인, 개발, 운영 등을 대행하는 것을 의미하며, 하자보수는 서비스 런칭일을 기준으로 일정기간 동안 발생하는 오류에 대해 개발업체가 오류개선을 해주는 것을 의미합니다.

 

하자보수에 대한 정의가 마무리 되면 장애에 따른 업체의 대처형태.. 예컨데, "고객이 장애 확인 후, 업체 측에 통보한 시점으로부터 12시간 이내 수정 후, 담당자에게 통보"와 같이 사이트의 장애요소 처리 프로세스도 정리하셔야 합니다.  보통 사이트를 완벽하게 만들었다고 하더라도 여러 요인에 따라 장애가 발생하는데, 서버의 하드디스크가 망가졌다거나.. 혹은 테스트 시 확인되지 않았던 오류가 생겼다거나 했을 때 이러한 가이드라인이 없거나 명확하지 않을 경우, 의뢰업체와 개발업체 간의 분쟁이 생길 수 있는 만큼 이 부분도 세세히 정리하셔야 햡니다.

 

여기까지 정리가 이루어졌다면, 만들어진 사이트를 운영할 내부 관리자(운영자, 개발자 등)를 대상으로 한 교육일정과 횟수, 그리고 운영에 필요한 메뉴얼의 제출을 요청해야 합니다.  간혹, 일부 개발업체의 경우 이 부분을 대충 넘기는 곳들도 있는데, 그럴 경우 내부 운영에 심각한 문제를 초래할 수도 있으므로, 교육을 위한 내용 역시 꼼꼼하게 정리해야 합니다.  다만, RFP에 기재된 내용은 일종의 가안 성격이 강합니다.  다시 말해, 실 계약과정에서 개발업체와의 협의를 통해 일부 내용이 변경될 수도 있음을 참고하시기 바랍니다.

 

 

그 다음 서비스를 만들어가는 과정에서 생성되는 산출물에 대한 제출과 인력상주 여부 등을 기재하셔야 하는데, 보통 산출물은 크게 제안서와 착수보고서, 주간 보고서, 완료보고서 등이 여기에 해당됩니다.  제안서는 회사에서 제시한 RFP를 근거로 개발업체 측에서 제출하는 '이렇게 하겠다..'를 의뢰업체 쪽에 어필하는 문서이며, 제안서가 채택된 이후, 전체 스케줄을 기반으로 각 진척사항을 보고받는 착수보고서나 주간보고서, 그리고 기획서와 의뢰회사에서 요청한 각각의 기능구현이나 테스트 여부 등을 체크리스트로 정리하여 올바르게 구현됐는가를 보고하는 완료보고서 등을 언제 어떻게 받을 것인가 하는 내용을 기재하시면 됩니다.

 

참고로, 의뢰업체와 개발업체 간에 빈번하게 발생되는 회의록을 제출받으시는 것을 권장해 드립니다.  회의를 통해 언급되는 내용이라는 게, 미묘한 입장차이가 있을 수 있는 만큼 공식적인 문서를 통해 회의 내용을 제출받는 것이 의뢰한 작업의 정확성과 커뮤니케이션 미스를 줄일 수 있는 방법입니다.

 

보통 규모가 의뢰업체의 경우, 파견근무라는 이름으로 에이전시에서 작업인력을 몇 주에서 3개월까지 파견하는 경우가 있는데, 에이전시 입장에서 모든 업체에 자사 직원들을 파견하는 것은 아니며, 어느 정도의 규모 있어야 하는 만큼, "아니 왜, 우리한테는 작업자 파견을 안해주는거야?" 라고 무턱대고 투덜대시면 안됩니다.  의뢰 회사 입장에서야 수시로 작업사항을 확인하고자 하는 욕구가 있겠지만, 개발회사에서는 비용을 고려하지 않을 수 없는 거니까요..^^;

 

 

제안서 작성 가이드 - 이렇게 제안서를 작성해주세요.

 

제안서 작성 가이드는 말 그대로 제안서를 작성하는 개발업체 측에 "어떤 식으로 제안서를 써야한다.."에 대한 가이드를 제시하는 것으로, 제안서 제출 일정부터 제출 이후 업체 선정까지의 진행스케줄을 작성하면 됩니다.  예컨데, 이런 내용이 담기는거죠.

 

1. 제안일정

   ① 제안서 접수마감 : 2013년 xx월 xx일까지 도착분에 한함.

   ② 제안서 검토기간 : 2013년 xx월 xx일부터 xx월 xx일까지.

   ③ 1차 제안 PT일정 : 2013년 xx월 xx일 AM 10:00 부터 (본사 대회의실 진행)

   ④ 2차 제안 PT일정 : 2013년 xx월 xx일 PM 02:00 부터 (본사 대회의실 진행)

   ⑤ 업체확정과 통보 : 2013년 xx월 xx일 예정.

 

2. 제출방법

   ① 제안담당자의 이메일로 제안 PPT 자료 발송.

   ② 첨부할 제안자료는 20MB 이하로 제출.

 

3. 제안서 제출 및 문의처

   ① 문의전화 : 02-xxxx-xxxx

   ② 접수메일 : xxxxx@xxxxx.com (xxxx팀 홍길동 대리)

 

이렇게 제안 일정이 정리되면, 그 다음으로 제안서에 수록되어야 할 내용을 정리하셔야 하는데, 프로젝트의 형태나 제안 의뢰업체의 분위기에 따라 조금씩 따르지만, 대략 이런 내용이 들어갑니다.

 

1. 제안 개요.

    ① 제안 목적

    ② 제안 내용 중 주요 특징과 장점.

 

2. 기획 및 구현방법.

    ① 기획방향 및 디자인/개발과정에서의 포커스 요소.

    ② 사용되는 주요 개발기술.

    ③ 기존의 유사개발 진행 실적.

 

3. 프로젝트 진행계획.

    ① 본 프로젝트의 참여 인력구성 및 계획.

    ② 업무진행 보고 형태 및 일정.

    ③ 개발진행 과정에서의 지연에 따른 대책.

 

4. 유지보수 및 교육일정.

    ① 테스트 일정.

    ② 하자보수 지원계획.

    ③ 관리자 교육 범위와 계획.

    ④ 교육 프로그램 (교육내용, 대상자, 장소, 메뉴얼 등)

    ⑤ 기술이전 종류 및 전략.

 

5. 세부견적

    ① 사이트 및 시스템 구축비용.

    ② 투입 인건비.

 

6. 제안참여 업체의 기본적인 조직도 및 재무정보.

    ① 업체 연혁, 조직도, 조직 별 보유인력 현황.

    ② 주요사업 내용 및 추진실적.

    ③ 재무재표 정보.

 

들어가야 할 내용이 상당히 많죠?  위의 내용도 이해를 돕기 위해 러프하게 작성한 것이며, 세부적으로 필요한 요건들이 있을 수 있으니 참고만 하시기 바라며, 위와 같은 제안요건이 정리한 후 의뢰업체의 제안서 검토 후 평가항목, 즉 제출된 제안서를 바탕으로 한 선정기준을 정리하셔야 하는데, 보통 공기업 프로젝트의 경우 이 선정기준이 각 부분 별로 정량화되어 있습니다만, 필수항목은 아니며 정량화된 평가기준 제시가 어려울 경우, "자체평가 기준에 따름" 정도로 간단히 표기하셔도 무방합니다.  어짜피 선정과정에서 내 의견은 귓등으로도 안들을테니..

 

대략 이 정도의 내용이 제안요청서에 담겨야 할 내용이며, 부가적으로 개발업체에 당부하고 싶은 내용은 기타사항으로 정리하여 전달하시면 제안요청서 작업이 완료 됩니다.  세세하게 정리된 제안요청서는 정확한 제안을 받기위한 첫번째 단계인만큼, 최대한 꼼꼼하게 정리하시는 것이 의도한 방향으로 이끌 수 있는 가장 좋은 방법이라는 점, 잊지 마시기 바라며, 다음 편에서는 개발업체의 입장에서 RFP를 어떻게 해석할 것인가에 대한 해석방법을 정리하도록 하겠습니다.

 

아울러 이 글을 보시는 여러분들의 공감댓글 한마디가 더 좋은 글이 나오는 원동력이랍니다. 글을 통해 도움이 되셨거나 기획과 관련해 궁금하신 점이 있다면 언제든 댓글 남겨주세요..^^ 

 

야메군이 진행하는 "웹기획 마인드 강좌"는 오프라인 강좌 뿐만 아니라, 온라인 강좌로도 만나보실 수 있습니다. 지식 동영상 스토어 "AirKlass", 지구상 가장 큰 학교 "EDUCAST", 전문가의 지식노하우 플랫폼 "TOC6"에서 강좌를 확인해보세요!! 

야메군. Web와 Mobile, Digital 카테고리 SME(Subject Matter Expert). 웹기획 15년차로 네이버 웹기획자 커뮤니티 "웹(WWW)를 만드는 사람들"에서 운영진으로 활동하고 있으며, 딴지일보를 시작으로 아이러브스쿨, 짱공유닷컴, YES24 등의 회사를 거쳐, 현재는 민간 IT 원천기술 연구소 "Valhalla Lab"에서 Pattern recognition과 Machine learning, Natural Language Processing 기술의 상업적 이용방법에 대해 연구했으며, 2016년 7월 7일, 기획자의 업무능력 향상으로 위한 Guide Book "처음부터 다시배우는 웹기획(정재용, 최준호, 조영수 공저)" 출간.