PART1. 시작할 것인가, 말 것인가
제안요청서를 보면 문서는 대체로 깔끔하다. 구조가 잡혀 있고, 항목은 빠짐없이 정리되어 있으며, 표현도 단정하다. 그래서 이런 문서를 마주하면 프로젝트 역시 이미 어느 정도 준비가 끝난 것처럼 느껴진다. 이제 남은 일은 정리된 내용을 구현하는 것뿐이라는 인상을 준다. 그러나 경험상 이 인상은 오래가지 않는다.
제안요청서가 완성돼 보이는 이유는 대부분 정리가 잘 되어 있기 때문이다. 하지만 정리가 잘 되어 있다는 것과, 요구사항을 뒷받침하는 정책이나 기준까지 내부적으로 확정되었다는 것은 전혀 다른 이야기다. 문서는 요구사항의 결과만 보여줄 뿐, 그 요구사항이 어떤 논의 끝에 지금의 형태로 정리되었는지까지는 담고 있지 않다. 무엇을 포기했고 무엇을 선택했는지, 그리고 그 선택이 더 이상 번복되지 않을 결정인지에 대한 정보는 대개 빠져 있다.
그래서 잘 정리된 제안요청서라고 하더라도 기획자는 한 번 더 멈춰서 보게 된다. 문서만으로는 이 요구사항이 실제로 확정된 상태인지, 아니면 진행 과정에서 다시 논의될 수 있는 여지가 남아 있는지를 분명히 알기 어렵기 때문이다. 이 구분이 명확하지 않은 상태에서는, 문서의 완성도와는 별개로 프로젝트 진행 과정에서 추가적인 조율이 반복될 수 있다.
제안요청서, 어디까지 믿어도 되는가
제안요청서는 대개 고객사 내부에서 진행된 협의의 결과를 담고 있다. 하지만 그 협의가 더 이상 바뀌지 않는 최종 결론인지, 아니면 이후에 다시 논의될 수 있는 중간 정리인지는 문서만으로는 분명하지 않은 경우가 많다.
실제로 제안요청서가 최종 확정된 요구사항의 형태로 전달되는 경우는 드물다. 겉으로는 모든 것이 정리된 것처럼 보이지만, 대부분은 “일단 이 방향으로 정리해둔 상태”에 가깝다. 이 차이를 구분하지 못한 채 프로젝트를 시작하면, 이후의 변경은 단순한 추가 요청이 아니라 다시 검토해야 할 문제로 돌아온다.
겉보기에 잘 정리된 제안요청서에는 또 하나의 특징이 있다. 바로 질문할 여지를 줄여버린다는 점이다. 문서가 깔끔할수록 이미 고객사 내부에서 충분히 협의가 끝난 내용처럼 느껴지고, 그만큼 기획자는 질문을 망설이게 된다.
“이 기능은 이 방향이 맞는 거죠?”
“이 기능은 어디까지를 염두에 두고 계신 건가요?”
이런 질문조차 괜히 하는 것은 아닐지 스스로 조심스러워진다.
하지만 이 질문들은 이 기능이 어느 지점까지 확정된 것인지, 어디까지를 전제로 움직여도 되는지를 확인하기 위한 최소한의 질문에 가깝다. 오히려 이 확인이 생략되면 판단은 문서가 아니라 각자의 이해와 기억에 맡겨지게 되고, 그 차이는 프로젝트가 진행될수록 점점 더 크게 드러난다.
그래서 제안요청서를 볼 때 기획자는 문서의 완성도보다, 문서가 답하지 않는 질문을 먼저 본다. 아직 정리되지 않은 부분은 무엇인지, 이후에 다시 논의될 가능성이 있는 부분은 어디인지, 지금은 넘어갔지만 반드시 다시 체크해야 할 항목은 무엇인지. 이런 질문들이 정리되지 않은 상태에서 프로젝트를 시작하면, 프로젝트는 명확한 기준 없이 각자의 이해를 바탕으로 진행되기 쉽다.
완벽해 보이는 제안요청서는 프로젝트를 쉽게 시작하게 만든다. 하지만 동시에 프로젝트를 어렵게 끝나게 만들 수도 있다. 그래서 기획자는 문서를 그대로 믿고 구현에 들어가기보다, 이 문서를 어디까지 믿어도 되는지부터 가늠해야 한다.
이 장에서 말하고 싶은 것은 결국 하나다. 제안요청서는 완성된 설계도가 아니다. 완성된 것처럼 보이는 중간 결과물에 가깝다. 이 문서를 그대로 옮겨 제안서를 쓸 수 있다고 생각하는 순간, 프로젝트는 이미 첫 번째 착시 위에서 출발하게 된다. 이러한 착시에서 벗어나려면, 요구사항과 전제를 기획자의 기준으로 다시 정리하는 일이 필요하다.
다음 장에서는 일정이 빠듯하다는 신호를 어떻게 읽을 것인지 다뤄보려 한다.
숫자보다 먼저 확인해야 할 것은, 이 일정이 어떤 기준으로 만들어졌는지다.