기획자에게 오는 요청은 대개 이런 모양입니다. “게시판에 엑셀 다운로드 버튼 하나만 넣어 주세요.” 문장이 짧고 분명해서 그대로 옮겨 적으면 될 것 같습니다. 그런데 이 문장은 이미 한 번 번역된 결과입니다. 요청한 사람은 자기가 겪는 불편을 스스로 해법으로 바꾼 다음에 입을 열었고, 우리에게 도착한 것은 불편이 아니라 그 사람이 떠올린 해법입니다.
요청은 이미 한 번 번역돼 있습니다
이 번역은 나쁜 일이 아닙니다. 오히려 상대가 문제를 그만큼 고민했다는 뜻이고, 협조적인 태도입니다. 다만 번역에는 언제나 손실이 있습니다. 그 사람이 아는 방법 안에서 떠올린 해법이므로, 더 쉬운 길이 있어도 요청 문장에는 담기지 않습니다. 엑셀 버튼을 요청한 사람이 실제로 원한 것이 “매월 보고서에 넣을 숫자 다섯 개” 였다면, 다운로드 기능을 아무리 잘 만들어도 그 사람은 매달 엑셀을 열어 다섯 개를 골라내는 일을 계속하게 됩니다.
기획자의 첫 번째 일은 그래서 만드는 것이 아니라 되돌리는 것입니다. 요청 문장에서 출발해 그 문장이 나오기 전의 필요로 한 칸 거슬러 올라갑니다.
목적을 되찾는 질문 세 개
거슬러 올라가는 데는 질문 세 개면 충분합니다. 셋 다 기능이 아니라 상황을 묻는다는 공통점이 있습니다.
“이걸로 무엇을 하시려는 건가요?” — 가장 단순하지만 가장 많이 건너뛰는 질문입니다. 답이 “매월 대표님 보고서를 만들어야 해서요” 라면, 만들 것은 다운로드 버튼이 아니라 월간 요약 화면일 수도 있습니다.
“지금은 그 일을 어떻게 하고 계신가요?” — 현재의 우회 방법에는 요구사항이 통째로 들어 있습니다. 사람들이 이미 만들어 쓰는 수작업 절차는 그 자체로 가장 정확한 명세서이고, 어느 단계가 가장 아픈지도 알려 줍니다.
“이게 없으면 어떤 일이 생기나요?” — 우선순위를 정하는 질문입니다. 답이 “조금 번거롭습니다” 인 것과 “마감을 못 맞춥니다” 인 것은 같은 요청이 아닙니다.
물어보는 일이 거절처럼 들리지 않게
질문이 많으면 “안 해 주려고 그러나” 로 들릴 수 있습니다. 그래서 질문 앞에 의도를 먼저 말합니다. “제대로 만들고 싶어서 몇 가지만 확인할게요” 한 문장이면 분위기가 달라집니다.
그리고 기능을 부정하지 않습니다. “그건 필요 없어 보이는데요” 가 아니라 “말씀하신 걸로 해결되는 게 맞는지 같이 확인해 보죠” 입니다. 목적을 찾는 과정은 요청을 반려하기 위한 절차가 아니라, 같은 예산으로 더 나은 결과를 만들기 위한 절차입니다.
목적은 명세의 첫 줄에 남깁니다
알아낸 목적은 반드시 기록합니다. 구두로 합의한 목적은 두 주 뒤에 사라지고, 그 자리에는 원래의 요청 문장만 남습니다. 명세 문서의 첫 줄을 “이 기능은 ○○을 위해 만든다” 로 시작하면, 이후에 생기는 모든 판단 — 범위를 줄일지, 예외를 어디까지 다룰지, 무엇을 먼저 만들지 — 이 그 한 줄을 기준으로 결정됩니다.
기획과 개발 사이의 문서 습관은 개발 워크플로우 아카이브에 더 정리돼 있고, 요구를 받아 실제 작업으로 옮기는 절차를 통째로 보고 싶다면 작업 과정에 우리가 일하는 순서가 그대로 공개돼 있습니다.
다음 회차
목적을 알아냈다면 이제 그것을 적을 차례입니다. 다음 회차는 화면 목록을 만들기 전에 써야 하는 것 — 누가, 무엇을 하려고, 어떤 결과를 얻는지의 시나리오입니다.