혼자 개발·디자인·컨설팅을 파는 사람에게 견적서는 영업 문서이기 전에 작업 계약의 스키마다. 필드가 비어 있으면 프로젝트가 시작된 뒤 그 빈칸은 대부분 대표의 추가 노동으로 채워진다.
나는 첫 견적을 만들 때 금액보다 먼저 아래 구조를 고정하는 편이 낫다고 본다.
type Quote = {
deliverables: Deliverable[];
doneCriteria: string;
revisionPolicy: RevisionPolicy;
clientInputs: string[];
dueDateRule: string;
paymentSchedule: string;
exclusions: string[];
};
실제 견적서에 코드를 넣을 필요는 없다. 다만 이 필드들이 모두 답을 갖고 있는지 검사하면 “이것도 포함인 줄 알았다”는 대화를 크게 줄일 수 있다.
deliverables: 서비스 이름 대신 결과물을 적는다
“랜딩페이지 개발”만으로는 작업량을 계산하기 어렵다. 페이지 수, 반응형 범위, 폼 연결, 배포 여부처럼 고객이 실제로 받는 단위를 적어야 한다.
완료 조건도 필요하다. 단순히 코드가 전달되면 끝인지, 지정 도메인에서 정상 동작해야 끝인지에 따라 책임이 달라진다.
effort: 코딩 밖의 시간을 다시 포함한다
예상시간을 준비·제작·소통·마무리로 분해한다.
- 준비: 상담, 요구사항 확인, 자료 검토
- 제작: 실제 구현이나 콘텐츠 생산
- 소통: 중간 확인, 피드백 정리, 일정 조정
- 마무리: 테스트, 파일 정리, 전달, 결제 확인
고정 가격을 제시하더라도 내부에서는 이 시간을 계산해야 한다. 여기에 유료 API, 외주, 라이선스처럼 프로젝트 때문에 생기는 직접비와 매달 나가는 도구 비용의 일부를 더한다.
revisionPolicy: 수정 횟수보다 변경 유형을 구분한다
문구 한 줄 교체와 데이터 구조 변경은 같은 “수정 1회”가 아니다. 기본 수정에 포함되는 변경, 새로운 요구사항으로 보는 변경, 피드백을 받을 형식을 정의한다.
요구사항이 바뀌었을 때는 아래 셋 중 하나가 함께 바뀌어야 한다.
- 범위를 줄인다.
- 일정을 늘린다.
- 비용을 다시 산정한다.
셋 다 그대로인데 결과물만 늘어나는 상태는 견적이 아니라 미정의 동작에 가깝다.
dueDateRule: 마감일 대신 마감 조건을 적는다
“2주 안에 완료”보다 “착수금 확인과 필수 자료 수령 다음 영업일부터 10영업일”이 안전하다. 고객 자료가 늦으면 납기가 어떻게 이동하는지도 적는다.
급행 작업은 다른 작업의 우선순위를 바꾸므로 별도 조건으로 둔다. 대표가 일정 재배치 비용을 무료로 떠안지 않게 하는 장치다.
하나의 가격 대신 세 가지 구현 범위를 제안한다
기본형은 핵심 문제만 해결한다. 권장형은 실제 운영에 필요한 범위를 담는다. 확장형은 빠른 납기, 추가 채널, 운영 지원처럼 분명한 추가 가치를 포함한다.
예산이 부족하다는 답이 오면 동일한 스키마의 가격만 낮추지 말고 필드를 조정한다. 페이지 수, 수정 횟수, 지원 기간, 속도 가운데 우선순위가 낮은 항목을 다음 단계로 미룰 수 있다.
프로젝트 종료 후 실제값으로 스키마를 보정한다
예상시간과 실제시간, 추가 요청, 소통 횟수, 놓친 비용을 기록한다. 차이가 컸다면 단가만 올리기 전에 어느 필드가 모호했는지 찾는다.
견적은 한 번 정하고 끝나는 가격표가 아니다. 실제 프로젝트 로그를 반영해 계속 개선하는 운영 규칙이다.
Top comments (0)