PART1. 시작할 것인가, 말 것인가
제안요청서를 받으면 대부분은 기능 목록부터 본다. 무엇을 만들어야 하는지, 페이지는 몇 개인지, 관리자 기능은 어디까지 필요한지, 그리고 언제 오픈해야 하는지를 확인한다. 나 역시 처음에는 그랬다. 요구사항을 하나씩 체크하며 가능한지부터 따지고, 공수가 얼마나 되는지를 먼저 계산했다.
하지만 여러 프로젝트를 거치면서 제안요청서를 보는 순서는 조금 달라졌다. 이제 나는 기능보다 먼저, 이 프로젝트가 어떤 구조를 전제로 일정이 설정되어 있는지를 본다.
실무에서 반복해서 마주치는 제안요청서들에는 공통된 특징이 있다. 기능은 비교적 풍부하게 정리되어 있지만, 그 기능들이 어떤 기준으로 묶여 있는지는 쉽게 드러나지 않는다. 또한 어떤 기능이 핵심이고 어떤 기능이 부수적인 것인지도 명확하지 않다. 물론 서비스 특성에 따라 핵심 기능이 비교적 분명한 경우도 있다. 예를 들어 쇼핑몰이라면, 상품 전시와 판매와 같은 기능이 핵심이라는 점은 비교적 분명하다.
대부분의 제안요청서는 문서에 제시된 기능을 정해진 기간 내에 오픈하는 것을 전제로 작성된다. 그래서 문서를 처음 마주했을 때 기획자는, 이 기능들이 기한 내에 가능한지를 계산하기에 앞서, 이 일정이 어떤 구조를 전제로 만들어졌는지를 먼저 살펴보게 된다.
결정은 왜 항상 미뤄지는가
제안요청서를 검토할 때, 나는 기능보다 먼저 이 프로젝트의 구조를 본다. 여기서 말하는 구조는 화면이나 기능의 구조가 아니라, 결정이 만들어지고 확정되는 방식이다. 그리고 그 구조를 가장 단순하게 드러내는 질문은 의외로 하나다.
“이 프로젝트에서 결정은 누가 하는가.”
하지만 실제로 더 중요해지는 것은, 결정을 누가 내리는가보다 그 결정이 ‘확정되었다고 말할 수 있는 시점’이 언제인가다.
제안요청서에는 프로젝트의 담당자가 명시되어 있지만, 그 담당자가 결정을 확정할 수 있는 시점은 문서에 드러나지 않는 경우가 많다. 회의에서는 의견이 오가지만, 결정은 늘 “내부 검토 후”라는 말과 함께 다음 단계로 미뤄진다. 이 과정이 반복되면 프로젝트는 자연스럽게 지연되고, 쌓이고, 흔들리기 시작한다.
물론 제안요청서만 보고 결정이 언제 확정될지를 정확히 알 수는 없다. 다만 기획자는 이 문서를 통해 결정이 쉽게 확정되지 않을 구조인지는 가늠할 수 있다. 담당자는 있지만 최종 결정권자가 보이지 않는 경우, 의사결정 단계가 여러 부서로 흩어져 있는 경우, 혹은 결정 기준보다 일정만 먼저 제시되어 있는 경우에는 결정이 뒤로 밀릴 가능성이 높다.
그래서 기획자는 제안요청서를 읽으면서 기능보다 먼저, 이 프로젝트의 결정이 얼마나 오래 열려 있을 수 있는지, 그리고 그 불확실성을 감당할 준비가 되어 있는지를 살핀다.
일정은 정해졌는데, 왜 범위는 흔들리는가
불확실성은 곧 일정의 문제로 이어진다. 제안요청서에 적힌 일정은 대부분 이미 정해져 있다. 그래서 기획자는 일정의 적절성을 따지기보다, 이 일정이 어떤 기준으로 정해진 것인지, 그리고 어떤 조건과 요구사항이 아직 합의되지 않은 상태인지를 살핀다. 이런 전제가 정리되지 않은 일정은 결국 사람의 시간으로 유지되기 쉽기 때문이다.
다음으로 보게 되는 것은 요구사항 그 자체가 아니라, 요구사항이 바뀔 수 있는 여지다. 문서에 깔끔하게 정리된 요구사항일수록 오히려 더 주의 깊게 본다. 왜 이 기능이 필요한지, 왜 지금 이 시점인지, 왜 이 범위로 정리되었는지에 대한 설명이 빠져 있는 경우가 많기 때문이다. 이런 설명이 없다면 요구사항은 언제든지 바뀔 수 있다. 그리고 그 변경은 대부분 “생각보다 큰 변경”으로 돌아온다. 기획자는 이 지점에서 요구사항을 구현할 수 있는지보다, 이 요구가 어디까지 커질 수 있는지를 먼저 가늠한다.
여러 제안요청서를 보다 보면, 명시된 내용 외에 비어 있는 정보들이 보인다. 요청사항이 추가될 수 있다는 문장은 있지만, 변경이 발생했을 때의 기준이나 일정이 흔들릴 경우의 우선순위, 오픈의 기준과 범위는 빠져 있는 경우가 많다. 이 정보들이 비어 있다는 것은 아직 합의되지 않았다는 뜻이기도 하고, 아직 문제로 인식되지 않았다는 신호이기도 하다. 문제는 이런 빈칸들이 프로젝트가 진행될수록 더 큰 이슈로 돌아올 가능성이 크다는 점이다.
이렇게 제안요청서에는 결정, 일정, 요구사항과 관련된 많은 전제들이 문서 밖에 남아 있는 경우가 많다. 그래서 제안요청서를 검토하는 과정에서 기획자의 역할은 답을 정리하는 사람이 아니라 아직 정해지지 않은 것을 드러내는 사람에 가깝다.
“이 요구사항은 조금 애매합니다.”
“이 요구사항은 상황에 따라 범위가 커질 수 있습니다.”
“이 일정은 전제 조건이 정리되어야 할 것 같습니다.”
이 말들은 자칫 결정을 미루는 말처럼 들릴 수도 있다. 그러나 실제로는 결정을 피하는 말이 아니라, 결정이 가능해지기 위한 조건을 드러내는 말에 가깝다.
제안요청서를 읽으며 이 질문들을 던지다 보면 프로젝트의 성격은 생각보다 빠르게 드러난다. 구조로 풀 수 있는 프로젝트인지, 사람이 버텨야만 가능한 프로젝트인지, 지금 시작해도 되는 일인지…. 이 판단은 기획자가 혼자 내리는 결론이 아니다. 다만 이 판단을 가장 먼저 언어로 꺼내는 사람이 기획자일 뿐이다.
이 장에서 말하고 싶은 것도 결국 하나다. 제안요청서를 볼 때 기획자는 기능을 세는 사람이 아니라, 이 프로젝트가 어떤 전제로 움직이게 될지를 읽는 사람이다. 그 전제를 읽지 않고 시작한 프로젝트는 나중에 반드시 같은 질문을 다른 형태로 다시 만나게 된다.
"왜 요구사항이 계속 바뀌는가?"
"왜 일정이 흔들리는가?"
"왜 합의가 반복되는가?"
이 질문들은 대부분 제안요청서를 처음 받았을 때 이미 문서 안에 숨어 있었다. 그래서 나는 제안요청서를 받을 때마다 다시 한번 스스로에게 묻는다. 이 문서에 적힌 것보다 적히지 않은 것이 더 많은 프로젝트는 아닌가. 그리고 그 질문이 불편할수록 나는 조금 더 천천히, 조금 더 조심스럽게 프로젝트를 바라본다. 그렇게 제안요청서를 읽고 나면, 기획자는 한 번 더 자신의 언어로 문서를 다시 쓰게 된다. 그 작업이 바로 제안서를 쓰는 일이다.
다음 장에서는 ‘완벽해 보이는 제안요청서’가 만들어내는 오해에 대해 다뤄보려 한다.
프로젝트는 종종 그 오해 위에서 시작된다.