웹사이트 구축 RFP에 무엇을 적어야 합니까

먼저 정할 것 — 왜 만드는가

「홈페이지가 낡아서」는 이유가 되지만 목표는 아닙니다. 목표가 없으면 제안사가 각자 다른 목표를 가정하고 제안합니다.

채용 지원자를 늘리려는 것인지, 제품 문의를 받으려는 것인지, 투자자에게 보여 줄 자료를 갖추려는 것인지에 따라 만들 페이지도 측정할 값도 달라집니다. 목표를 두세 문장으로 적고, 가능하면 지금 수치를 함께 적으십시오.

「현재 월 방문자 3,000명, 문의 폼 접수 월 12건」처럼 적으면 제안사가 무엇을 개선할지 구체적으로 씁니다.

범위를 숫자로 적습니다

범위를 열어 두면 견적이 서로 다른 가정 위에서 나옵니다. 아래 항목은 숫자나 예/아니오로 적어야 비교가 됩니다.

• 페이지 수

  디자인이 다른 화면의 수를 적습니다. 같은 틀에 내용만 다른 페이지는 따로 세어 구분합니다.

• 언어

  필요한 언어와, 언어마다 전체를 번역할지 일부만 할지 적습니다.

• 관리자 범위

  관리자에서 고칠 수 있어야 하는 영역을 나열합니다.

• 연동

  사내 시스템·회원 인증·결제·고객관리 도구와 연결이 필요한지 적습니다. 연동 대상의 이름을 적으면 가장 좋습니다.

• 콘텐츠 제작

  글과 사진을 누가 만드는지 적습니다. 이 항목이 빠져서 분쟁이 나는 경우가 많습니다.

• 이관 대상

  기존 사이트에서 옮겨야 할 게시물과 회원 데이터의 규모를 적습니다.

산출물 목록을 명시합니다

구축이 끝났을 때 무엇을 받는지 목록으로 적어 두면 나중에 다투지 않습니다. 디자인 원본 파일, 소스 코드, 데이터베이스 구조 문서, 관리자 매뉴얼, 서버 설정 정보가 대표적입니다.

산출물의 형식도 적으십시오. 「디자인 원본」이라고만 쓰면 이미지 파일만 받을 수도 있습니다. 편집 가능한 원본 파일이 필요하다면 그렇게 적어야 합니다.

평가 기준과 배점을 공개합니다

무엇을 몇 점으로 볼지 RFP에 적어 두면 제안사가 그 항목에 집중합니다. 가격만 100점이면 가격만 낮춘 제안이 오고, 디자인만 보면 실행 계획이 부실한 제안이 옵니다.

실무에서는 이해도와 제안 내용, 수행 실적, 투입 인력, 가격을 나눠 배점합니다. 투입 인력에 배점을 두면 제안 발표자와 실제 담당자가 다른 문제가 줄어듭니다.

질의응답 기간을 두고 받은 질문과 답을 모든 제안사에 함께 보내십시오. 한 곳에만 답하면 조건이 달라집니다.

일정은 구간으로 적습니다

「3개월 내 완료」처럼 총 기간만 적으면 검수와 승인에 걸리는 시간이 계산에서 빠집니다. 발주사가 확인해야 하는 구간을 함께 적어야 현실적인 일정이 나옵니다.

기획 확정, 디자인 확정, 개발 완료, 검수, 오픈으로 나누고 각 구간에서 발주사가 며칠 안에 확인할지 적으십시오. 내부 승인이 2주 걸리는 회사라면 그것도 일정입니다.

오픈 시점이 정해져 있다면 그 이유를 함께 적으십시오. 행사나 신제품 출시에 맞춰야 한다면 제안사가 우선순위를 다르게 잡습니다.

검색과 접근성 요구를 적습니다

검색 노출과 웹 접근성은 나중에 붙이면 비용이 더 듭니다. 구축 범위에 넣을 것인지 RFP 단계에서 정하십시오.

웹 접근성 인증을 받아야 한다면 심사 비용과 재심사 조건을 누가 부담하는지 적어야 합니다. 인증 기준은 정해져 있으므로 제안사가 다르게 해석할 여지는 적습니다.

AI 검색 서비스가 사이트를 읽어 갈 수 있도록 구조화 데이터를 넣을 것인지도 이때 정하면 좋습니다. 오픈 후에 넣는 것보다 설계 단계에서 넣는 편이 비용이 적습니다.