RFP 응답 요구 사항

최근에 웹 사이트 디자인의 요구 사항, 계약 및 제안에 대한 많은 게시물을 보았습니다. 그 이유는 무엇입니까?

성공적인 웹사이트 디자인을 시작하려면 이미지, 텍스트 및 소프트웨어 코드 이상이 필요하기 때문입니다. 다음은 모든 제안 요청(RFP) 응답에 포함해야 하는 주요 웹 디자인 요구 사항입니다.

웹사이트 디자인의 성공은 견고한 문서화와 구조화된 프로세스의 직접적인 결과입니다

효과적인 웹 디자인 프로젝트를 실행하는 것은 견고한 문서화로 시작하고 끝납니다. 이 견고한 문서는 작업 명세서, 계약서 또는 제안서의 형태일 수 있습니다. 이 문서의 이름은 문서에 포함된 정보보다 덜 중요합니다.

대기업이든 중소기업이든 예산과 작업 시간 및 시간에 맞는 웹 프로젝트를 실행하려면 견고한 문서가 필요합니다.

판매 프로세스에서 문서에 주의를 기울일수록 전체 프로세스가 관련된 모든 사람에게 더 원활하고 쉽게 진행될 것입니다. 이 기사에서는 제안 요청(RFP) 응답을 평가하고 검토하는 방법에 대해 설명합니다. 봐!

RFP 응답 평가

RFP 응답을 검토하고 평가하는 것이 쉬워 보입니까? 그러나 실제로 실제로 연습할 때보다 더 쉽게 들립니다.

프로젝트를 담당하는 팀이 다른 디자인 에이전시의 견적을 요청하면 웹 디자인 제안을 평가하는 작업이 부담스러울 수 있습니다. 좋아, 그들은 단지 그것을 느끼는 것이 아니라 실제로는 압도적일 수 있습니다.

RFP 부상의 수가 많을수록 해당 제안 내의 변형 및 응답 풀이 커집니다. RFP를 보내기 전에 최종 후보에 올랐을 때 웹 개발자의 짧은 목록이 만들어졌기 때문에 이 번호를 제한적으로 유지하고 전체 검토 프로세스를 좀 더 쉽게 만들 수 있기를 바랍니다.

웹사이트 제안을 받으면 시작하기 위해 몇 가지 중요한 질문을 하는 것이 좋습니다. 이러한 질문에는 일반적으로 다음이 포함됩니다.

• 프로젝트에 주어진 일정 내에서 제안을 제공할 수 있습니까?
• 이 제안은 프로젝트의 예산 제약 내에서입니까?
• 받은 RFP 응답이 웹사이트 디자인의 모든 요구 사항을 해결합니까?
• RFP 응답이 잘 작성되고 이해하기 쉽습니까?
• 귀하가 받은 RFP 응답이 전문적인 방식으로 제시되었습니까?
• 주어진 시간 내에 응답이 제공되었습니까?

위에 주어진 질문은 의심할 여지 없이 높은 수준의 질문이지만 분명히 이상한 질문을 하는 웹 디자인 회사를 제거하는 데 도움이 됩니다. 불완전하거나 늦거나 비전문적인 RFP 응답에는 잠재적인 웹사이트 개발에 대한 위험 신호가 주어져야 합니다. 또한 가격을 두 배 또는 세 배의 예산으로 인용하는 RFP 응답과 관련이 있습니다.

이제 모든 응답을 받았고 분명히 적합하지 않은 회사에 위험 신호를 보냈으므로 이제 각 RFP 응답을 철저히 검토하여 RFP 응답을 쉽게 비교할 수 있습니다. 더 많은 사과 대 사과 방식.

각 RFP 응답에서 확인해야 하는 웹 디자인 요구 사항

다양한 길이의 RFP 응답이 있습니다. 따라서 페이지 수나 텍스트의 양에 초점을 맞추지 않는 것이 좋습니다. 가장 중요한 것은 응답에 제시된 솔루션과 내용입니다.

RFP 응답을 검토할 때 각 응답에는 웹 프로젝트의 몇 가지 중요한 요소가 포함된다는 점을 항상 염두에 두십시오. 이러한 웹 디자인 요구 사항이 아래에 제공된 세부 정보를 포함하되 이에 국한되지 않는지 확인하십시오.

프로젝트 계획:

여기에는 높은 수준의 방대한 프로젝트 작업 목록이 포함되어야 합니다. 초기 계획일 뿐이므로 최종 계획 자체만큼 상세하지는 않지만 빌드, 개발, 설계 및 발견의 흐름을 쉽게 이해할 수 있도록 세부사항이 충분히 포함되어야 합니다.

프로젝트 관리 도구:

디자인 에이전시의 프로젝트 관리 도구에 대한 적절한 목록이 있어야 합니다. 회사 내에서 사용할 수 있는 훌륭한 옵션이 많기 때문에 회사마다 프로젝트 관리 도구 세트가 다릅니다. 가장 중요한 것은 프로젝트 관리 프로세스에 적절한 구조가 있는지 확인하고 주어진 작업, 날짜 및 소유자를 쉽게 이해할 수 있도록 문서화하는 것입니다.

팀 멤버:

다른 디자인 에이전시는 팀을 위해 다른 구조를 제공합니다. 웹 디자인 에이전시가 클수록 프로젝트 팀이 작업하는 규모가 커집니다. 구매자로서 팀에서 누가 당신과 함께 일할 것이며 그들이 제공할 작업 능력이 무엇인지 아는 것이 중요합니다. 각 팀 구성원의 전체 이력서가 있어야 하는 것은 아니지만 최소한 앞으로 몇 달 동안 함께 일할 사람들의 목록이 있어야 합니다.

기본 기술 및 콘텐츠 관리 시스템:

웹사이트의 RFP가 원하는 CMS 솔루션을 지정하지 않은 경우 제안의 필수 요소가 됩니다. RFP 응답에 선택한 완전한 CMS와 새 웹 사이트를 배포하고 코딩하는 데 필요한 추가 기술이 나열되어 있는지 확인하십시오. 소유권이 있는 모든 항목에 특히 유의하십시오. 웹사이트의 수명 동안 해당 웹 개발자에게 당신을 가두는 독점 CMS 패키지에 즉시 위험 신호를 보내십시오.

결과물:

이것은 당신이 라이브를 할 때 당신에게 무엇을 전달할 것인지를 알려주기 때문에 또 다른 가장 중요한 목록입니다. 여기에는 사용된 플러그인, 콘텐츠 마이그레이션 볼륨, 디자인 템플릿 및 프로젝트와 관련된 더 많은 것들이 포함될 수 있습니다.

기능 목록:

디자인하려는 웹 사이트가 단순한 브로셔 웹 사이트 이상인 경우 이것은 또 다른 가장 중요한 목록입니다. 웹사이트가 복잡할수록 기능 목록이 더 상세해야 합니다.

콘텐츠 마이그레이션:

웹 사이트 프로젝트에 콘텐츠 마이그레이션이 포함되는 경우 새 웹 사이트로 마이그레이션할 콘텐츠의 양을 나열하는 것을 잊지 마십시오. 여기에는 첨부 파일, 사용자, 이벤트, 제품, 게시물, 페이지 등이 포함될 수 있습니다. 콘텐츠의 양과 성격이 정의되지 않으면 디자인 에이전시는 물론이고 추가 비용과 범위가 늘어납니다.

검색 엔진 최적화:

SEO를 잊지 마세요! 여기에는 301 리디렉션, 메타 정의, 페이지 최적화, 페이지 매핑 및 키워드 조사에 필요한 키워드가 포함될 수 있습니다. 유기적 SEO에 의존하는 경우 재설계하는 동안 이 트래픽 소스를 보호하세요. 이 작업을 수행하는 가장 쉽고 쉬운 방법은 프로젝트 제안 및 범위 지정 프로세스 중에 이 주제가 중심에 있고 첫 번째로 표시되도록 하는 것입니다.

이미지 사용:

웹 디자인 프로젝트 내에서 디자이너가 사용하는 이미지의 할당과 소유권을 주의 깊게 이해하는 것이 중요합니다. 이미지 배치, 편집, 구매 및 선택을 담당하는 사람에 대해 웹 디자인 에이전시에 문의하십시오. 이는 프로젝트마다 다르므로 초기 단계에서 이를 명확하게 정의하는 것이 좋습니다.

제외:

귀하가 만드는 모든 제안에 제외를 포함할 필요는 없지만 웹사이트 프로젝트에 포함되지 않는 항목에 대해 귀하와 클라이언트가 논의할 때마다 이를 나열하는 것을 잊지 마십시오. 이는 구매자가 이후 프로세스에서 보호하는 데 도움이 될 뿐만 아니라 클라이언트에 대한 결과물을 명확하게 합니다.

모바일 응답성:

오늘날 모바일 반응 없이 완벽한 웹사이트는 없습니다. 그것은 모든 현대 웹사이트의 주요 부분이어야 합니다. 그러나 웹 사이트의 크기에 따라 다릅니다. 별도의 모바일 앱이나 웹사이트를 보유한 대기업이 많이 있습니다. 괜찮습니다. 별도의 모바일 웹사이트가 없는 경우 디자인하는 제안서에 태블릿 및 휴대폰에 맞게 조정된 디스플레이를 쉽게 관리할 수 있는 언어가 포함되어야 합니다.

API 또는/및 타사 통합:

엔터프라이즈 및 중간 시장 회사는 일반적으로 조직 내에 엄청난 수의 소프트웨어 및 시스템 패키지를 보유하고 있습니다. 이러한 시스템은 데이터를 동기화, 푸시 및 풀링하여 새 웹사이트와 쉽게 통신하는 데 사용됩니다. API 또는 통합을 때때로 사용해야 하는 경우 제안서에 타사 시스템, 데이터 전송, 데이터 포인트 및 책임 당사자가 정의되어 있는지 확인하십시오.

일정:

각 웹 제안 응답에는 프로젝트의 이정표에 해당하는 목록이 포함되어야 합니다. 이를 통해 구매자는 각 이정표를 완료하는 데 필요한 시간과 프로젝트가 주어진 일정에 맞춰질지 여부를 알 수 있습니다.

이정표:

설정된 이정표가 있는 경우 팀은 다음 단계로 이동하기 전에 웹 사이트 디자인 프로세스의 각 단계에서 목표를 달성하기 위해 보다 효과적으로 작업할 것입니다. 일반적인 이정표에는 일반적으로 베타 테스트 또는/및 출시, 콘텐츠 마이그레이션, 테마 코딩, 그래픽 디자인, 정보 아키텍처, 검색 및 실행이 포함됩니다.

지연:

프로젝트 지연은 일반적으로 개발자와 클라이언트 모두로 인해 발생합니다. 이러한 지연을 성공적으로 처리하는 방법과 전반적인 웹 디자인 프로젝트 일정 및 예산을 변경하는 방법을 이해하는 것이 중요합니다.

지불 조건:

소규모 웹사이트 프로젝트가 있는 경우 구매자는 프로젝트 시작 시 50%, 완료 후 50%를 지불해야 합니다. 반면에 더 큰 웹 사이트 프로젝트가 있는 경우 지불은 정해진 타이밍이나 이정표를 기반으로 합니다. 제안서에 지불 조건이 명확하게 정의되어 있는지 확인하십시오.

경비:

비용에는 일반적으로 스톡 이미지, 플러그인 라이선스, 호스팅 요금, 도메인 요금 및/또는 여행이 포함됩니다. 제안서 내 모든 비용에 대한 적절한 세부 정보가 있어야 하며 구매자가 지불을 책임져야 합니다.

사용자 교육:

사용자가 CMS를 처음 사용하는 경우 제안서에는 교육 문서, 대화형 교육 세션 또는/및 온라인 교육 도구 작성에 대한 몇 가지 지침이 포함될 수 있습니다. 교육 방법론은 사용자 기반과 일치해야 합니다.

보증 기간:

보증 기간은 일반적으로 웹사이트 내의 소프트웨어 버그 수정에 적용됩니다. 보증 기간은 일반적으로 특정 기간 동안 설정되며 계약 또는 제안서에 명시되어야 합니다. 이 보증은 웹사이트 개발자의 코딩에는 적용되지만 타사 확장 프로그램이나 플러그인에는 적용되지 않습니다.

지속적인 유지 보수:

유지 보수를 보증 기간과 혼동하지 마십시오. 보증기간과 많이 다릅니다. 유지 관리 계약은 연간 또는 월 단위로 지불해야 하며 시간이 지남에 따라 시스템 및 소프트웨어에 대한 웹 개발자 업데이트를 제공하는 데 사용됩니다. WordPress 웹 사이트의 경우 지속적인 유지 관리에는 전체 WordPress 핵심 소프트웨어 및 웹 사이트에 설치된 모든 플러그인의 업데이트가 포함됩니다. 지속적인 유지 관리에는 필요 시 일대일 지원, 보고, 백업, 모니터링 및 보안도 포함됩니다.

필요할 때 사후 지원:

모든 회사가 유지 보수 계약을 필요로 하거나 원할 필요는 없습니다. 일부 회사는 유지 관리 계약 대신 주문형 사후 지원을 요구할 것입니다. 이는 일반적으로 시간 단위로 청구되며 지원 시스템 또는 티켓을 통해 관리됩니다.

웹사이트 RFP 프로세스와 관련된 다음 단계:

전체 RFP 응답을 검토하고 선택한 공급업체의 범위를 좁혔으면 이제 최종 세부 정보 및 계약을 협상하는 다음 단계에 집중할 때입니다.

인터넷이 계약 협상에 대한 권장 사항으로 가득 차 있지만 프로세스 세부 사항에서 지체하지 마십시오. 이 단계는 선택한 웹 개발자와 오랜 파트너십을 맺기 전 마지막 단계라는 점을 명심하는 것이 중요합니다.

이 협상은 미해결 문제 또는 질문을 해결하는 데 중점을 두고 있으며, 이는 설계 및 구현 프로세스를 시작하기 위한 견고한 기반을 제공합니다. 미해결 문제를 해결하고 혼란스러운 점을 명확히 하는 데 주의를 기울이면서 계약 협상에 들어갑니다.

선택한 프로젝트 팀이 프로젝트 범위 지정을 훌륭하게 수행하고 올바른 개발자를 선택한 경우 협상은 서명에 불과합니다. 팀이 잘못된 웹 디자인 에이전시를 선택한 경우 프로젝트는 팀이 2위 회사에 대해 생각하게 하기에 충분할 수 있습니다.