작업 명세서

일을 받아 해 주는 관계에서 다툼은 대개 품질이 아니라 범위에서 생깁니다. 약속한 것을 안 해 준 경우보다, 약속에 들어 있었는지가 서로 달랐던 경우가 훨씬 많습니다.

전형적인 장면은 이렇습니다. 기업 고객에게 제품을 도입해 주기로 하고 4,000만 원에 계약했습니다. 두 주쯤 지나 고객이 기존 시스템에 쌓여 있던 문서 8만 건을 언제 옮겨 주는지 묻습니다. 개발팀은 그 이전 작업을 계산에 넣은 적이 없습니다. 고객은 도입이라는 말에 당연히 포함된다고 읽었고, 우리는 새 문서를 쓸 수 있게 만들어 주는 일로 읽었습니다. 어느 쪽도 거짓말을 하지 않았는데 2주치 일이 갈 곳 없이 남습니다.

이 간격을 메우려고 제안서를 근거로 삼으려 하면 또 막힙니다. 제안서는 팔기 위한 문서라서 좋게 들리는 표현으로 쓰여 있고, 도입 지원이나 데이터 연동 같은 말은 읽는 쪽이 원하는 크기로 부풀 수 있습니다.

작업 명세서는 그 사이에 들어가는 문서입니다. 관계 전반의 규칙을 정한 계약서 아래에, 이번 건의 범위와 끝나는 기준을 숫자와 명사로 적습니다. 파는 말과 지키는 말을 분리하는 자리라고 보면 됩니다.

들어가는 칸은 범위, 산출물, 일정, 검수 기준, 대금, 전제와 제외, 변경 절차, 담당자 여덟 가지입니다.

1. 범위 — 하는 일을 동사로 적습니다. 검토한다나 지원한다 같은 말은 크기를 알 수 없으니, 화면 다섯 개를 만든다처럼 셀 수 있게 씁니다.
2. 산출물 — 실제로 넘기는 것을 형식과 개수로 적습니다. 운영 환경에 올라간 기능, 관리자 계정 다섯 개, 운영 안내서 한 부처럼 적습니다.
3. 일정과 단계 — 시작일과 끝나는 날, 중간에 확인하는 시점을 둡니다. 단계마다 무엇이 끝나 있어야 하는지를 함께 적습니다.
4. 검수 기준 — 어떤 상태가 되면 완료로 보는지를 정합니다. 이 칸이 비면 일이 끝나지 않습니다. 고객이 계속 의견을 낼 수 있고 우리는 끝났다고 말할 근거가 없습니다. 기능 목록대로 동작하고 심각한 오류가 없으면 완료처럼 적어 둡니다. 여기 적은 기준은 보증 조항이 약속하는 상태와 어긋나지 않아야 합니다.
5. 대금과 지급 시점 — 금액을 단계에 붙입니다. 착수 시점 30퍼센트, 중간 확인 40퍼센트, 검수 완료 30퍼센트처럼 나눕니다.
6. 전제와 제외 — 가장 자주 빠지고 빠졌을 때 가장 비싼 칸입니다. 기존 데이터 이전은 포함하지 않는다, 고객사 사내망 설정은 고객이 한다처럼 하지 않는 일을 적습니다.
7. 변경 절차 — 범위를 늘릴 때 어떻게 하는지 정합니다. 서면으로 합의하고 추가 비용과 일정을 다시 적는다는 한 줄이 있으면, 요청을 거절하지 않고도 공짜로 늘어나는 것을 막을 수 있습니다.
8. 담당자와 협조 사항 — 양쪽 담당자를 이름으로 적고, 고객이 해 줘야 하는 일에 기한을 붙입니다. 검수 결과를 5영업일 안에 회신한다는 문장이 여기 들어갑니다.

초안은 파는 쪽이 씁니다. 다만 제안서를 그대로 옮기면 안 되고, 실제로 일할 사람이 공수를 확인한 뒤에 확정합니다. 이 검토를 건너뛰면 팔린 범위와 할 수 있는 범위가 어긋난 채로 서명됩니다.

읽는 쪽은 넷이고 보는 칸이 다릅니다.

1. 고객 실무 담당자 — 범위와 일정을 봅니다. 자기가 기대한 것이 목록에 있는지 확인하는 사람입니다.
2. 고객 구매와 법무 — 대금과 변경 절차를 봅니다. 기본 계약서와 어긋나는 문장이 있는지도 여기서 걸립니다.
3. 우리 실행팀 — 검수 기준과 제외 항목을 봅니다. 작업 중에 들어온 요청이 범위 안인지 밖인지를 이 문서로 판단합니다.
4. 정산 담당 — 단계별 금액과 검수 시점을 봅니다. 청구서를 끊을 근거가 이 문서입니다.

쓰는 시점은 제안 뒤 계약 전입니다. 기본 계약서를 먼저 맺고 건마다 이 문서를 붙이는 방식이 일반적입니다. 여러 사람에게 같은 조건으로 파는 이용약관과 달리 상대마다 내용이 달라지므로, 양식을 두고 칸만 바꿔 쓰는 방식이 실무에서 자리를 잡습니다.

"그건 명세서 제외 항목에 있어요. 하려면 변경 합의부터 해야 합니다."

요청을 거절하는 것이 아니라 절차를 밟자는 말입니다.

"검수 기준이 비어 있어서 이 건은 끝이 안 나요."

완료 조건이 없으면 프로젝트가 닫히지 않는다는 지적입니다.

"제안서 문구를 명세서에 그대로 넣지 마세요. 그건 파는 문장이에요."

두 문서의 역할이 다르다는 뜻입니다.

페이지덱은 첫 대형 고객 도입에서 이 문서 없이 시작했습니다. 수아가 제안서와 견적만 보내고 계약을 맺었고, 태오가 작업을 시작한 뒤 고객이 기존 문서 8만 건 이전을 요청했습니다. 제안서에는 도입 지원이라고만 적혀 있었습니다.

결국 이전 작업을 무상으로 해 주고 2주를 더 썼습니다. 그 뒤로 규원은 계약 전에 작업 명세서를 붙이는 절차를 넣었고, 제외 항목 칸을 반드시 채우게 했습니다. 다음 건에서 같은 요청이 들어왔을 때는 제외 항목에 적혀 있었고, 이전 작업은 800만 원짜리 별도 건으로 계약됐습니다.

제안서와 같은 문서라고 생각하는 경우가 많습니다. 둘 다 무엇을 해 줄지 적혀 있으니 자연스러운 혼동입니다. 하지만 제안서는 설득하는 문서고 작업 명세서는 구속하는 문서입니다. 제안서에서는 넉넉하게 들리도록 쓴 표현이 명세서에서는 그대로 의무가 됩니다. 제안서 문장을 복사해 붙이면 크기가 정해지지 않은 약속이 계약으로 넘어가고, 그 크기를 정하는 것은 나중에 요구하는 쪽이 됩니다.

자세히 쓰면 고객이 부담스러워한다는 생각도 흔합니다. 제외 항목을 적으면 인색해 보일까 걱정하는 것입니다. 실제로는 반대로 작동합니다. 무엇을 하지 않는지 적혀 있으면 고객도 어디까지 기대해야 하는지 알고 다른 준비를 할 수 있습니다. 적지 않고 시작한 프로젝트는 중간에 반드시 그 대화를 하게 되는데, 그때는 일정이 걸려 있어서 대화가 협상이 아니라 다툼이 됩니다.