사례를 통해 알아보는 기획과 기획 문서의 차이

기획은 목표를 향하여가는 과정과 이 과정을 운영/관리하여 목표를 달성 가능하게 하는 설계를 의미합니다. 이 과정 중 나오는 결과물이 바로 기획 문서라 할 수 있습니다. 기획 문서는 기획 내용에 대한 것이고 기획의 흐름에 대한 마일스톤입니다.

 

 

사례 1 : 멋진 스윙을 하는 사람은 LA 다저스 4번 타자가 될 수 있나?

 

어떤 일반인이 야구 배트로 너무나 멋진 스윙을 할 수 있다고 가정합니다. 그럼 이렇게 멋진 스윙을 할 수 있기에 이 일반인은 투수가 던지는 150km 전후 공을 잘 칠 수 있을까요?

 

이러한 멋진 스윙 폼을 가지고 있으면 투수의 공을 잘 칠 수 있고, 이 사람은 메이저리스 LA 다저스 같은 팀에서 4번 타자를 할 수 있다는 가정은 논리적으로 맞지 않다는 것은 누구나 잘 알고 있습니다. 만약 이 가정이 맞다고 말하는 사람을 본다는 야구를 모르는 사람일 것입니다.

 

그러나 일부 기획 현장에서는 문서를 만드는 것(야구 스윙)과 기획(투수의 공을 치는 것)을 같은 것으로 여기기도 합니다.

 

훌륭한 타자는 멋진 스윙 메커니즘을 가지고 있지만 멋진 스윙을 가지고 있다고 모두 훌륭한 타자가 아닌 것처럼 좋은 기획을 하기 위해서는 문서 작업을 잘할 수 있어야 하지만 기획 문서 작업을 잘한다고 좋은 기획을 하는 것은 아닙니다.     

 

기획 작업을 안다면 멋진 스윙을 한다고 해서 메이저리그 LA 다저스 4번 타자가 될 수 있다는 가정이 말이 안 된다는 것을 아는 만큼 기획 문서 작업을 잘한다고 좋은 기획자라 할 수 없다는 것은 압니다.

 

그러나 많은 기획 현장에서는 기획 문서 중 일부만 잘해도 좋은 기획자라 평가받기도 합니다. 기획이 달성하고자 하는 목표에 맞지 않은 문서 내용임에도 기획 문서라 이름 붙여진 문서를 잘 만들었다고 좋은 기획자라 하기도 합니다. 

 

이것은 타자가 공을 맞추지 못해도, 수비는 전혀 못해도, 공을 치고 달리지 못해도 스윙만 멋지게 하면 4번 타자라는 말과 같습니다.

   

 

사례 2 : 1/8 더하기 1/8은 1/4이라는 답을 쓰는 것과 아는 것의 차이

 

문제와 답은 아는데 문제를 푸는 방법은 모른다면 과연 안다고 할 수 있을까요?

 

이는 소년심판 등 학교와 학생이 나오는 드라마의 소재가 되기도 하고, 실제 중고등학교에서 나타나고 있는 문제기도 합니다. 그래서 시험 문제지를 훔쳐 문제와 답을 외워 시험을 보기도 합니다. 때로는 선생님이 문제를 바꾸면 이전 문제 답을 적기도 합니다. 문제를 보지도 않고 시험지의 문제 번호와 외운 이 번호에 대한 답을 적기만 하기도 합니다.

 

이런 상황이 말도 안 되는 것이라 모든 사람들은 생각할 것입니다.

 

그러나 온라인 서비스 개발 기획 현장에서는 이와 같은 일이 매우 빈번히 발생합니다. 기획자가 기획을 할 환경 상황과 자원 파악하지도 않고 스토리보드에 화면만 그리는 작업을 하기도 합니다. 그냥 인기 서비스나 최신 디자인 트렌드를 반영하여 피그마, 어도비 XD, 제플린, 스케치 등 디자인/프로토타이핑 툴로 작업하고 기획이 완료되었다고 말하는 경우도 있습니다.

 

온라인 서비스 기획의 과정 중에 화면 기획을 담은 스토리보드는 최종 결과물 중 하나입니다. 서비스 기능과 프로세스를 담은 스토리보드 또한 다른 형태의 최종 결과물 하나입니다. 이 최종 결과물 앞에는 더 많은 기획 과정 문서가 존재해야 합니다. 

 

이런 기획 과정 중 나와야 하는 단계별 문서의 내용과 의미를 이해하지 못한다면 서비스 개발 과정 중 문제가 발생할 수 있습니다. 개발자가 다른 서비스를 개발한다든지, 때로는 개발을 전혀 할 수 없을 수도 있습니다.

 

때로는 인기 서비스를 참고로 화면 디자인을 한 것을 바탕으로 서비스 개발을 하여 오픈하는 경우 디자인 특허 소송에 휘말리기도 합니다.          

 

 

기획 OJT, 도제 교육과 문서 작업의 관계

 

신입 기획자가 입사를 하면 OJT 과정과 사수, 부사수 관계를 통해 사내 도제 교육을 진행하게 됩니다. 이때 가장 먼저 하는 것이 문서 작업을 알려주는 것입니다.

 

문서 작업을 알려주는 방식에는 특정 문서를 작성하는 방식을 알려주는 것도 있지만, 프로젝트 또는 작업 과정 중에 어떤 문서를 생성하여 결제를 받아야 하는지도 알려 줍니다.

 

보통 과장 또는 대리 직급의 사수는 신입 사원인 부사수가 이 문서의 의미를 알 것이라 생각하고 알려주는 것은 아닙니다. 일단 문서 작성 시기와 방법을 알고 프로젝트를 몇 번 돌다 보면 자연스럽게 문서의 의미와 왜 작성해야 하는지 알게 되기에 시키는 것입니다.

 

이를 도제식 교육, 경험 학습이라고 합니다. 기획 학습이 공학 학습과 다르기에 이런 방식으로 신입 사원을 교육합니다.

 

신입 기획자 기획 교육 과정 중 문서는 깔끔하게 잘 만드는데, 문서의 작성 시기와 방향이 전혀 안 맞는 경우도 종종 생기게 됩니다. 이런 일은 기획자가 기획을 하는 대상 프로젝트의 전반적 내용과 흐름을 이해하지 못하기에 생기는 것입니다. 

 

문서는 깔끔하게 잘 만들어졌으나 기획 대상 프로젝트 내용과 흐름에 맞지 않게 작성된 문서를 기획 현장에서는 보통 일을 안 했다고 말합니다. 쓸데없는 문서 작업을 한 것입니다. 신입 사원이기에 이 또한 교육 과정 중 하나로 괜찮지만, 만약 대리나 과정이 이런다면 문제는 심각합니다. 

 

이런 사람을 일을 하면 할수록 일을 만듭니다. 그냥 아무것도 안 하는 것이 도와주는 것입니다. 보통 기업에서는 문제 직원입니다.

 

보통 기획의 특성상 업무에 따라 표준화된 작업 프로세스가 있을 수는 있지만 각 단계마다 분명한 답이 있는 것은 아니고 기획자가 상황 정보를 파악하고 분석하여 논리에 따라 정리를 해서 문서화해야 하기에 기획자의 기획 역량은 문서의 적절성에 매우 큰 영향일 미치게 됩니다. 

 

기획 문서의 적절성과 기획 문서 작성을 잘하는 것은 다른 개념입니다. 대규모 프로젝트 경쟁 입찰 시 국내에서는 때로는 문서가 이쁜 것도 점수화될 수 있기에 기획자가 기획 문서 작성을 한 후 문서 디자이너에 맡기기도 합니다.

 

이때 기획자가 작업한 것은 기획 문서는 적절성이 높은 것이고, 문서 디자이너가 작업한 것은 문서 작성을 잘한 것이라 말할 수도 있습니다.   

 

그럼 여기서 기획은 기획자가 한 것일까요? 문서 디자이너가 한 것일까요?

 

개발 프로젝트를 경험하면서 많은 개발 프로젝트 실패하는 이유 중 하나가 바로 기획의 부재 때문이었습니다.

 

국내에서 기획의 부재 이슈는 단지 서비스 개발 분야뿐 아니라 여러 산업 분야에서 언급되었던 것입니다. 광고, 마케팅, 영화, 연예인 매니징, 게임, 콘텐츠, 온라인 서비스 등 다양한 산업 분야에서 기획의 부재와 기획자 부족을 언급되었습니다.

 

그러나 기획 작업은 최종 결과물을 보여주는 것이 아니기에 넘어가는 경우가 대부분이었습니다. 기획만으로 서비스가 작동하는 것도 아니고, 보기 좋은 화면을 확인할 수 있는 것은 아닙니다. 이런 이유로 기획이 부족하지만 당장 여러 문제로 대부분 그냥 넘어갑니다. 

 

이렇게 넘어간 서비스 개발 프로젝트는 개발 초기에는 문제없이 넘어가지만 항상 마지막에 문제가 발생하게 됩니다. 몇몇 문제 프로젝트의 개발 마지막 시기 기획서 정리를 위해 투입된 경우 스토리보드 외에 기획 문서가 없는 것을 확인하게 됩니다.

 

스토리보드가 문제가 없다면 개발도 문제가 없었겠지만, 프로젝트 종료 전에 신규 기획자가 투입된다는 것은 스토리보드에 문제가 있다는 것을 의미합니다. 그럼 스토리보드 수정을 위한 기획 과정 문서가 있어야 합니다. 

 

그러나 보통 이런 프로젝트는 스토리보드 외에는 기획 과정 문서가 없습니다. 그리고 기존 구성원들은 서로 자기주장만 하고 있어 무엇이 맞는지 확인이 불가능할 정도인 경우가 대부분입니다. 결국 정리가 불가능하고 서로 책임을 전가하기 위한 문서를 요청합니다. 이미 누가 들어와도 개발은 불가능한 상황인 것입니다.

 

개발 프로젝트가 이런 극한 상황까지 몰리게 된 것은 기획 리더가 기획 업무를 해온 경험과 역량이 있는 기획자가 맡은 것이 아닌 스토리보드 작업을 해 보았던, 심한 경우 여러 프로젝트를 참여해 스토리보드를 많이 본 사람이기 때문입니다.

 

심한 경우 기획 리더가 선 투입되어 몇 달 동안 요구사항을 파악하고 상세화하여 정리하지 않고 화면만 그리고 있는 경우도 있습니다. 이런 개발 프로젝트에 시작 후 몇 달이 지난 후 기획자로 투입해 고객과 미팅을 해 보면 고객의 분노와 한숨만 미팅 내내 들립니다.

 

정리하면 기획 작업에 문서 작업이 꼭 필요하지만 기획 문서가 기획을 의미하지는 않습니다. 문서 작성 그 자체가 아니라 문서에 담긴 내용의 단계 적절성과 방향성이 기획 흐름에 맞아야 합니다.  흔히 이는 기획 로직에 대한 것이며 인풋과 아웃풋에 대한 기본 설계입니다. 기획 로직과 인풋과 아웃풋 변수와 관계를 모르는데 기획 문서가 작성 방향성과 내용 적절성이 확보되기를 바랄 수는 없습니다.