개발 견적의 “문의 기능 1식”을 작업 범위로 바꿔 적기

“홈페이지 제작, 문의 기능 포함”이라는 견적 문장을 받았다고 해보겠습니다. 입력받을 항목도, 결과를 확인할 곳도 적혀 있지 않습니다. 가격을 논의하기 전에 이 한 줄을 어떻게 바꾸면 좋을까요? 아래는 실제 고객 문서가 아닌 가상의 제작 건입니다.

같은 요청을 세 칸으로 나눕니다

저장소까지 만들지 않는 예제라면 그 점을 적습니다. DB 보관, 관리자 검색과 엑셀 다운로드는 메일 알림과 다른 작업입니다. 개인정보 안내와 외부 메일 서비스의 설정 담당자도 함께 정해야 실제 작업을 계산할 수 있습니다.

이번 금액에 없는 작업도 같은 문서에 둡니다

“이번 범위에는 회원가입·결제·예약·관리자 조회를 포함하지 않습니다. 필요한 경우 요청 내용을 확인해 추가 일정과 비용을 협의합니다.”처럼 씁니다. 할 수 없다는 선언보다 이번에 합의할 범위를 보여주는 문장입니다.

사진 촬영, 로고 제작, 문구 작성과 기존 자료 이전도 누가 맡는지 적습니다. 고객이 준비할 자료에는 담당자와 필요한 날짜를 넣고, 자료가 늦어지면 공개일을 다시 협의한다는 조건을 같이 남깁니다. 특정 수정 횟수나 작업 기간을 업계 공통 규칙으로 두지 않습니다.

추가 요청을 받으면 바뀌는 동작부터 답합니다

가령 “문의 내역을 엑셀로 받고 싶다”는 요청이 들어왔다면 먼저 목록이 필요한 사람과 시점을 물어봅니다. 수신 메일을 가끔 정리하면 되는지, 사이트에서 매일 검색·내려받아야 하는지에 따라 해결 방법이 달라집니다.

요청: 문의 내역을 사이트에서 엑셀로 내려받고 싶습니다.
기존 범위: 이메일 알림까지만 제공
추가 검토: 문의 저장, 관리자 접근, 다운로드, 보관·삭제 기준
진행 기준: 일정과 비용을 확인하고 합의한 뒤 착수

합의한 기능의 오류를 고치는 일과 새 기능 추가는 구분합니다. 어떤 동작을 언제까지 확인할지 문서에 남겨두면 “수정 한 번”의 뜻을 서로 다르게 이해하는 일을 줄일 수 있습니다.

바로 편집할 수 있는 범위 확인서

편집용 범위 확인서에는 결과물, 완료 확인, 제외 항목, 고객 자료, 변경 요청과 인계 항목을 넣었습니다. 프로젝트별로 채우는 서식이며 실제 계약서나 법률 자문을 대신하지 않습니다. 저작권·책임·지급 조건은 실제 거래에 맞춰 별도로 검토합니다.

포함·제외와 제약을 함께 정리하는 원칙은 Atlassian의 프로젝트 범위 안내도 참고했습니다. 이 글의 문장과 서식은 작은 홈페이지 사례에 맞춰 직접 구성했습니다. 보낸 뒤에는 상대가 어떤 범위로 이해했는지 확인하고 문서 버전과 확인일을 남겨보세요.