PART1. 시작할 것인가, 말 것인가
기획을 이야기할 때 사람들은 흔히 문서를 떠올린다. 기획서, 화면 설계서, 요구사항 정의서.
하지만 실무에서 기획이 실제로 시작되는 순간은 문서를 쓰기 시작할 때가 아니다. 요구사항에 대한 질문이 정리되는 순간이다. 질문이 정리되지 않은 상태에서 작성된 문서는 시간이 지날수록 계속해서 수정될 수밖에 없고, 디자이너나 개발자로부터 쏟아지는 질문에도 명확하게 대응하기 어렵다.
프로젝트 초반에는 언제나 질문이 많다. 무엇을 만들어야 하는지, 어디까지를 전제로 생각해야 하는지, 이미 정해진 일정 안에서 무엇이 확정된 것인지. 하지만 이런 질문들은 처음부터 정리된 형태로 등장하지 않는다.
요구사항을 확인하기 위한 회의가 열리지만, 그 자리에서는 요구사항에 대한 질문, 일정에 대한 전제 확인, 정책과 운영에 대한 질문, 결정 방식에 대한 질문이 한꺼번에 뒤섞여 쏟아진다.
이 상태에서는 아무리 많은 이야기를 나눠도 기획은 시작되지 않는다. 질문이 많다는 것과 질문이 정리되어 있다는 것은 전혀 다른 상태이기 때문이다.
질문을 정리하는 순간, 기획은 시작된다
기획자의 역할은 이 질문들에 즉시 답을 주는 사람이 아니다. 오히려 이 질문들이 어떤 종류의 질문인지를 구분하는 사람에 가깝다. 지금 당장 결정해야 할 질문인지, 전제가 먼저 정리되어야 할 질문인지, 아직 질문할 단계가 아닌 질문인지. 이 구분이 되지 않으면 모든 질문은 동시에 답해야 할 문제처럼 보이고, 그 결과 기획은 늘 촉박해진다.
실무에서는 이런 질문들을 자주 마주한다.
“이 기능은 가능한가요?”
“이 일정 안에 가능한가요?”
“이건 왜 안 되는 거죠?”
이 질문들에 곧바로 답하려다 보면 기획자는 자연스럽게 결정권자처럼 행동하게 된다. 하지만 대부분의 경우, 이 질문들은 바로 답할 수 있는 질문이 아니다. 정책이 아직 정리되지 않았고, 개발 범위도 확정되지 않았으며, 요구사항에 대한 결정이 언제, 어떻게 내려질지도 분명하지 않은 상태에서 가능 여부만 묻고 있기 때문이다. 이때 필요한 것은 답변이 아니라, 질문의 위치를 다시 잡는 일이다.
그래서 기획자는 질문을 이렇게 바꿔 말한다.
“이 기능은 현재 기준으로 확정된 요구사항인가요?”
“이 요구사항은 언제까지 확정되는 건가요?”
“이 부분은 누가 최종적으로 결정하게 되나요?”
이 질문들은 기능을 묻는 질문처럼 보이지만, 실제로는 결정의 기준과 시점을 확인하는 질문에 가깝다. 그리고 이 질문들이 정리되기 시작할 때, 비로소 기획은 앞으로 나아간다.
질문을 정리하는 방식이나 형식은 중요하지 않다. 문서일 수도 있고, 메일일 수도 있다. 중요한 것은 지금 이 시점에서 무엇이 아직 정해지지 않았는지, 어디까지가 합의된 내용인지, 그리고 그 답을 누가 가지고 있는지를 분명히 하는 일이다. 이 과정은 답을 빨리 얻기 위한 절차라기보다 질문을 드러내고 기준을 남기기 위한 과정에 가깝다.
질문을 정리하는 일은 기획을 앞당기는 행동이 아니다. 오히려 기획이 무너지지 않도록 속도를 조절하는 일이다. 전제가 정리되지 않은 상태에서 서둘러 진행된 프로젝트는 결국 일정이나 범위를 다시 조정해야 하는 상황으로 이어지기 쉽기 때문이다.
이 장에서 말하고 싶은 말은 결국 하나다. 기획은 답을 잘하는 사람이 되는 일이 아니다. 질문을 제때, 올바른 위치에 놓는 사람이 되는 일이다. 그리고 그 질문들이 정리되는 순간, 비로소 이 프로젝트는 ‘시작할 준비가 되었다’고 말할 수 있다.
다음 장에서는 ‘전원 상주’라는 조건이 왜 위험 신호가 될 수 있는지 다뤄보려 한다.
상주는 일을 빨리 하는 방식이 아니라, 기획을 더 오래 끌고 가게 만드는 방식이 될 수도 있다.