거시적 관점과 미시적 관점의 서비스 개발 기획 산출물 차이

거시적 관점은 서비스 개발 프로젝트를 진행하는 개발자, 디자이너와 기획자가 협업에 관한 것으로 대표적 서비스 개발 기획 산출물은 스토리보드입니다. 이에 반해 미시적 관점에서는 기획 자체 업무 프로세스를 의미하고 이때 스토리보드는 맨 마지막 산출물이 됩니다. 

 

 

협업 관점의 서비스 개발 기획

 

프로젝트 전체 관점에서 서비스 개발 기획을 보면 서비스 개발을 위해 투입된 인력 코딩을 할 수 있고 화면을 디자인할 수 있게 하는 문서를 의미합니다. 그래서 스토리보드가 기획 문서가 됩니다.

 

하지만 기획 관점에서 보면 스토리보드를 만들기 위한 기본 기획 문서가 기획 난이도가 높은 문서입니다. 기획 부서 관점에서 보면 스토리보드는 기획 실무 실행 문서라 할 수 있습니다. 어떤 부서에서 다른 부서와 업무 협력을 위한 구체적 문서를 부서장 같은 리더가 생성하지는 않고 실무 담당자가 작성하는 것과 같은 이치입니다.

 

그러나 협업을 해야 하는 다른 부서가 보는 것은 해당 기획 부서 내부 문서가 아닌 실무자가 작성한 협의 문서만입니다. 이를 기획 부서의 문서로 인식하게 되는 것입니다.

 

프로젝트 상 서비스 개발 기획에서 스토리보드가 바로 회사의 기획 부서가 다른 부서와 협업을 하기 위해 만들어 공유하는 실무 문서에 해당하는 것입니다.    

 

 

스토리보드만 주로 인식되는 이유

 

서비스 개발 프로젝트가 기획만으로 진행되는 것이 아니기 때문입니다. 게다가 프로젝트를 참여해 보면 개발, 디자인 등 참여 기능 인력 중 기획자가 가장 적은 경우가 대부분입니다.  

 

내부 프로젝트인 경우는 다를 수 있지만 외주(외부 개발) 형 서비스 개발 프로젝트에서 고객은 주로 기획을 담당하고 PM 및 영업에서 고객의 기획 내용을 요구 사항의 형태로 정리하여 WBS를 만들면, 이에 맞추어 기획을 진행하게 됩니다. 이 과정에서 기획 프로세스의 상당 부분 진행 완료됩니다.

 

이런 이유로 주로 서비스 개발 프로젝트에서 기획자의 투입은 주로 개발 실행을 위한 실무 문서의 필요로 인해 진행되게 되는 것입니다. 스토리보드가 기획 산출물의 중심이 될 수밖에 없는 이유가 여기에 있는 것입니다.

 

 

기획 문서를 만들지 못하는 기획자가 프로젝트 기획을 리딩 하는 이유와 결과

 

그러나 프로젝트가 반복되다 보면 이러한 이유가 아닌 습관적으로 과정이 서비스 개발 프로젝트에 적용되게 됩니다. 여기서 서비스 개발 기획의 문제가 발생하게 됩니다. 

 

고객도, PM에서도 관습적으로 요구사항과 WBS를 작성하다 보면 서비스 개발 기획 실무 문서인 스토리보드를 작성하기 위한 미시적 프로세스 관련 내용들이 부족하게 됩니다. 

 

요구사항에서 WBS에 이르는 전체 과정인 거시적 개발 프로세스 관점에서만 반복 진행되다 보면 개발자가 중심이 되는 외주(외부 개발) 형 서비스 개발 프로젝트의 특성상 기획 부분이 간과되게 됩니다. 

 

그래서 개발자 또는 다자이너, 영업, 사이트 운영자가 경력이 쌓이게 되면 기획 업무를 맡게 되는 경우가 많이 발생합니다. 문제는 이들은 과거 기획 부서에서 경력을 쌓아온 게 아닌 협력 부서에서 경력을 쌓아왔기 때문에 기획 부서 안에서 기획을 위한 프로젝트 미시적 기획 과정을 경험해 보지 않았다는 점입니다. 단지 여러 프로젝트를 기획자와 함께 하면서 협업을 위한 실무자의 문서만 보아온 것입니다.

 

협업을 위한 실무 문서만 보아온 사람은 그것이 기획의 전부라 인식하게 됩니다. 기획자나 디자이너가 개발자와 수년간 함께 일하면서 코드를 자주 보아서 알게 된 함수를 써서 코드를 흉내 낼 수 있다고 가정합니다. 그래서 기획자나 디자이너가 알게 된 함수로 코딩을 해서 개발자에 준다면 개발자는 어떤 느낌을 받을까요?

 

기획도 같습니다. 기획 부서에서 본부장, 부장, 차장, 과장, 대리, 사원을 거치면서 기획 문서가 어떻게 생성되고 협업 기획 문서가 만들어지기까지 어떤 과정을 통해 기획 산출물이 만들어지고 이들이 어떤 관계에 따라 실무 문서에 영향을 주는지 파악하지 못한 상태에서 최종 협업 문서를 만든다면 그것은 기획자나 디자이너가 개발자의 어깨너머로 자주 보아 알게 된 함수로 코딩을 한 개발 산출물과 다를 것이 없습니다.       

 

기획 부서에 신입 기획자로 들어가게 되면 맨 처음 배우는 것이 회의록 작성과 품의를 위한 문서 작성 등 아주 기본적인 문서 작업을 배우게 됩니다. 이런 기본적인 문서 작업을 통해 내용을 파악하고 정리하는 법을 배우게 됩니다. 이런 과정을 통해 서비스 개발 프로젝트의 미시적 기획 관점의 기획 사고 과정이 향상되게 됩니다.

 

그래서 기획자가 만든 문서 몇 장만 보면 이 사람이 기획자로 어떤 수련 과정을 거쳐 왔고, 어떤 스타일의 기획자인지가 파악할 수 있는 것입니다.

 

최근 서비스 개발 프로젝트를 참여해 보면 기획 리더인데 아주 기본적인 기획 사고나 업무를 처리하지 못하는 경우를 꽤 보게 됩니다. 회의를 하면 회의 내용을 이해하지 못하고, 기본적인 회의록 정리나 기획과 관련한 문서를 만들지 못하는 경우도 보게 됩니다. 그냥 스토리보드 문서만 예쁘게 만드는 것에 치중합니다. 회의 내용이나 기획 단계에 따른 산출물은 이해하지 못합니다.

 

회의를 했는데 이때 나온 내용을 기획 리더가 이해 못 하기에  그냥 스토리보드에 적용되는 것이 아닌 문서만 기획 리더 개인적 취향에 따라 예쁘게 만들기를 기획자에 요구하는 경우도 있습니다. 심한 경우 함께 회의에 참여한 기획자 입장에서 회의 내용을 정리해서 전달해 주어도, 이런 기본적인 기획을 위한 업무 참여와 문서 작업을 해본 적이 없기에 기획 리더가 정리 내용을 엉망으로 수정하기도 합니다. 기획 리더가 정리한 회의 내용으로는 회의에 참석 안 한 개발자, 디자이너 누구도 회의의 주요 내용을 파악할 없게 됩니다.

 

 

서비스 개발 프로젝트 실패의 시작

 

서비스 개발 프로젝트에 프리랜서 기획자로 참여를 해서 보면 망해가는 프로젝트는 기획 리더가 기획에 대해 모르는 경우가 대부분입니다. 기획 리더인데 기획을 말로 하고 어떤 기획을 위한 과정 문서도 생성하지 않습니다. 이런 서비스 개발 프로젝트의 기획 리더는 주로 거시적 관점의 기획 산출물만 강조하고 미시적 기획 산출물은 이야기하지도 않습니다.

 

이는 기획 부서에 부서장, 차장, 과장, 대리 등의 상급자 없이 사원만 있는 것과 같습니다. 만약 어떤 기업 기획실에 사원 혼자만 있고 이 사원이 이 기업 전체 기획을 책임지고 있다고 하면 과연 그 기업이 진행 중인 여러 사업이 잘 될 것이라 생각되시나요?  

 

서비스 개발 프로젝트에서도 미시적 관점의, 기획 부서에서 협업 기획 산출물을 내기 위한 과정 없는, 기획 과정 산출물 없이 최종 산출물이 나오는 것은 사원만 있는 기업의 기획실이고 이 기획실의 산출물에 따라 기업 전체가 움직이는 것과 비슷합니다.

 

만약 기획 리더가 기획 과정 문서 작성을 못한다면 기획 부서에 사원으로 근무한 경험도 없는, 그냥 다른 부서에서 기획부서 문서를 받아서 작업했던 경험만 있는 것과 같다 보면 됩니다. 

 

이 프로젝트는 서비스 개발 기획에서부터 이미 개발의 방향성과 목적물 구체화에 실패해 있는 것입니다.