기술을 모르는 상태에서 개발자나 제작사에 일을 맡길 때 가장 먼저 하게 되는 일은 대개 화면을 모으는 것입니다. 마음에 드는 사이트를 캡처하고, 메뉴 구조를 정하고, 필요한 페이지를 나열합니다. 그 자체는 좋은 준비입니다. 다만 그것만 건네면 견적은 빨리 나오되 결과는 어긋나기 쉽습니다.
이유는 간단합니다. 화면은 답이고 요구사항은 문제인데, 답만 건네면 받는 쪽은 그 답이 왜 그래야 하는지 알 수 없습니다. 그래서 적힌 그대로 만들고, 만들고 나면 “생각했던 것과 다르다” 는 말이 나옵니다. 이 어긋남은 실력의 문제가 아니라 전달된 정보의 문제입니다.
화면만 건넸을 때 실제로 생기는 일
참고 사이트 다섯 개를 건네면 제작자는 다섯 개의 공통점을 추측합니다. 추측이 맞을 때도 있지만, 대개는 우리가 그 사이트에서 좋아한 지점과 제작자가 읽어 낸 지점이 다릅니다. 우리는 “문의가 잘 들어오게 생긴 화면” 을 골랐는데, 상대는 “이런 색과 여백” 으로 읽는 식입니다.
더 큰 문제는 말하지 않은 조건입니다. 나중에 우리가 직접 문구를 고칠 수 있어야 한다든지, 검색에 노출되어야 한다든지, 기존 도메인을 그대로 써야 한다든지 하는 것들은 화면 캡처에 나타나지 않습니다. 이 조건들은 대개 작업이 거의 끝난 뒤에 드러나고, 그때는 되돌리는 비용이 가장 큽니다.
요구사항 한 장에 들어가는 세 가지
거창한 문서는 필요 없습니다. 세 개의 제목이면 충분하고, 각 항목은 문장으로 씁니다.
목적은 사업의 언어로 씁니다. “문의 폼이 필요합니다” 가 아니라 “상담 문의를 주 5건 이상 받고 싶고, 지금은 전화 문의만 들어옵니다” 라고 쓰면, 제작자는 폼 말고 다른 제안도 할 수 있게 됩니다.
조건은 타협할 수 없는 것만 적습니다. 사용 중인 도메인, 이관할 수 없는 데이터, 사내에서 직접 수정해야 하는 영역, 예산 상한, 마감이 걸린 날짜 같은 것입니다. 조건이 미리 나오면 견적에 반영되고, 늦게 나오면 추가 비용이 됩니다.
판정 기준은 이 연재에서 반복해 등장할 개념입니다. “무엇을 보면 이 일이 끝났다고 할 것인가” 를 미리 적는 것인데, 이것이 없으면 인수 단계가 감상평 교환이 됩니다. 자세한 작성법은 4회차에서 다룹니다.
같은 요청을 두 가지로 써 보면
예를 들어 보겠습니다. “메인 페이지를 세련되게 만들어 주세요” 는 요구사항이 아닙니다. 세련됨은 판정할 수 없고, 따라서 언제 끝났는지도 알 수 없습니다.
같은 요청을 이렇게 쓸 수 있습니다. 목적 — 처음 방문한 사람이 5초 안에 우리가 무엇을 하는 회사인지 알게 한다. 조건 — 문구는 우리가 직접 수정할 수 있어야 하고, 모바일에서 먼저 보기 좋아야 한다. 판정 기준 — 업계를 모르는 지인 세 명에게 첫 화면만 보여 주고 무슨 회사인지 물었을 때 세 명 모두 맞힌다.
세 번째 줄이 중요합니다. 판정 기준이 구체적이면 제작자도 편해집니다. 무한한 수정 요청 대신 통과 조건이 생기기 때문입니다. 좋은 요구사항은 발주자를 지키는 문서인 동시에 수주자를 지키는 문서입니다.
견적을 요청할 때 함께 보낼 것
요구사항 한 장에 더해 세 가지를 같이 보내면 견적의 정확도가 크게 올라갑니다. 현재 사이트 주소(있다면), 현재 사용 중인 호스팅 종류, 그리고 우리 쪽에서 직접 준비할 수 있는 것의 목록입니다. 마지막 항목은 특히 유용합니다 — 문구와 이미지를 우리가 준비하는지 아닌지에 따라 견적이 달라지기 때문입니다.
이 사이트도 워드프레스 업그레이드와 최적화를 맡는 업체이므로 같은 기준을 스스로에게 적용합니다. 우리가 무엇을 하고 무엇을 하지 않는지는 최적화 지원 사업 페이지에 범위와 제외 항목으로 적어 두었고, 실제 작업 절차는 작업 과정에 단계별로 공개돼 있습니다. 견적을 받을 때 이 두 가지가 문서로 있는지 보는 것이 첫 번째 확인입니다.
다음 회차
요구사항을 보냈으면 견적서가 돌아옵니다. 다음 회차는 그 문서를 읽는 법입니다 — 금액보다 먼저 봐야 하는 항목이 세 개 있습니다.