기획자가 본 앱, 웹 개발에 실패하는 이유

많은 개발 프로젝트에 기획자로 참여를 하여 본 개발에 실패하는 프로젝트는 공통점이 있습니다. 물론 이 공통점은 기획자 관점에서 보이는 것이고, 개발자 관점에서는 또 다를 것입니다. 최소한 기획에서 이 부분만 조심한다면 개발 성공률을 높일 수 있을 것이라 생각합니다.

 

 

단순함과 복잡함

문제가 있는 개발 프로젝트의 문제의 시작은 너무 복잡하게 기획을 시작했다는 것입니다. 개발 과정 중 문제는 반드시 생깁니다. 이 문제가 해결 가능하면 일시적인 문제일 뿐입니다. 그러나 너무나 복잡한 개발 상태는 문제를 정확히 파악조차 할 수 없게 합니다. 문제 해결은 불가능에 가깝습니다. 그래서 처음부터 다시 개발을 하게 되기도 합니다.

 

이런 프로젝트의 기획은 매우 복잡하게 진행됩니다. 그리고 기획 결과물이 많기는 하지만 무언가 정밀하지가 않습니다. 시작할 때는 모르나 기획이 진행되면 될수록 기획자 자신도 복잡함에 잡아먹히게 됩니다. 그러다 보면 전체적인 구성의 연결성이나 통일성을 고려하기 어려워집니다. 그래서 기획자는 문서 한 장 한 장에만 집중하게 됩니다. 

 

이런 기획서의 경우 문서 한 두 장만 보면 잘 만든 기획서 같습니다. 그러나 이 기획서를 가지고 개발을 하려고 하면 어떻게 개발하라는 것인지 파악이 잘 안 됩니다. 그리고 개발 관련 빠진 내용도 나오게 됩니다. 분명 화면 설계는 있는데 요구 사항을 따라 개발하다 보면 기획서의 화면처럼 개발할 수 없을 때도 있게 됩니다. 주로 외부 API, 설루션을 이용할 경우 이 케이스가 종종 나타나기도 합니다. 기획자가 자기 생각대로 화면을 그려 넣은 것입니다.    

 

보통 기획에서 개발에 적합한 단순화 능력을 일머리라 합니다. 일머리가 없는 기획자의 작업 내용은 일단 복잡합니다. 때로는 단순한 일도 복잡하게 만들어 작업하기도 합니다. 그리고 많은 일을 했다고 스스로 생각합니다. 결국 모르기에 복잡한 것입니다. 그러나 스스로를 합리화하기에 일을 많이 했다고 주장하는 것입니다.

 

과거 개발 프로젝트 현장에서 무조건 오래 일해야 인정받던 시기도 있었습니다. 일이 없어도 무조건 야근을 해야 하고, 같은 업무도 2~3번 반복해야만 했습니다. 이런 사람은 무언가 열정적이고 기업을 사랑하는 직원이라 인정받기도 했습니다. 오히려 일을 빨리 끝내면 성실하지 못하고 조직 충성도가 낮다고 평가받기도 했습니다. 물론 일을 오래 했어도 작업 양이 적으면 안 됩니다. 그래서 일단 작업 문서는 많이 만들었던 시절도 있습니다.

 

개발에 문제가 있는 프로젝트 스토리보드는 깔끔하게 잘 정리된 수 백장인 경우가 많습니다. 그런데 개발을 하기 위해 보면 이 깔끔한 문서는 너무 복잡해서 무엇을 개발하라는 것인지 내용을 파악하기 어렵습니다. 내용이 아니라 양과 정리에 중요성을 둔 기획서로 개발하는 프로젝트는 문제가 생길 수밖에 없는 것입니다.

 

 

보고를 위한 기획과 개발을 위한 개발

기획서가 복잡한 것은 프로젝트 자체가 복잡한 이유도 있겠지만, 기획자가 개발을 모르기 때문이기도 합니다. 기획자는 개발자에 비해 당연히 개발을 모를 수밖에 없습니다. 이는 협동 작업을 통해 해결할 수 있습니다. 그러므로 기획자가 개발을 모른다는 말의 의미는 협업할 수준이 안된다는 것이 되는 것입니다..

 

개발 프로젝트에 참여를 해 보면 어떤 기획자는 개발 내용과는 상관없이 화면만 설계하고 있기도 합니다. 문서에 화면을 그리고 있다는 말이 더 정확할 것입니다. 여기에는 개발 대상에 대한 정의나 작동 설명이 없는 것은 당연합니다. 다른 앱/웹들을 이용하면서 보았던 화면을 조금 수정해서 그리기도 합니다.

 

이런 기획서를 만드는 이유 중 하나는 보고를 위해서입니다. 어차피 보고를 받는 사람들도 개발에 대해서는 모릅니다. 그래서 정리가 잘된 문서를 선호하기도 합니다. 개발 내용이 기획서에 적혀 있는 기획서보다, 개발을 할 수 없지만 깔끔한 기획서를 더 선호하는 경우도 있습니다.

 

만약 최종 기획서 검토자가 개발을 알고 지적을 한다면 화면 이미지만 있고 기획서는 통과되지 못할 것입니다. 화면 작동 로직이 없는 기획서를 허용하지 않을 것입니다. 

 

그런데 만약 고객이나 의사 결정자가 개발 프로젝트 기획 산출물로 이런 문서를 원하고, 개발 과정 중 기획서 컨펌도 문제없이 이루어진다면 개발에 화면만 있는 기획서로 개발을 해야 되는 상황이 만들어집니다.

 

심하게는 메인 화면에 상품 5개가 노출된다고 화면 구분이 되어 있는데 어떤 상품 노출 규칙은 어떠한지, 얼마 동안 노출되고 변경되는지 등의 대한 내용은 없는 경우도 있습니다. 스토리보드에는 그냥 예쁘게 메인 화면의 노출 상품 5개의 위치가 디자인되어 있기만 하기도 합니다.

  

 

정치와 스펙

결국 이런 상황은 기획자들 사이에서는 물론, 기획자와 개발자 간에도 갈등이 생기게 될 수밖에 없습니다. 이때 이런 유형의 기획자는 살아남기 위해 정치를 하게 됩니다.

 

대표적 기획 문서라 할 수 있는 스토리보드를 작성하기 위해서는 앞선 글에서 이야기했든 많은 기획 자료가 필요합니다. 보통 요구사항 내용을 토대로 작업하기도 합니다. 그러나 엄밀히 요구 사항은 어떤 앱/웹의 개발을 원한다는 것과 어떤 기준에 마지에 개발하라는 등의 전반적의 규정 사항일 경우가 큽니다.

 

그러나 개발을 위해서는 요구사항보다 더 세부적인 정의가 필요합니다. 그래서 보통 경험 있는 기획자는 요구사항 상세화 작업을 진행하고, 고객이나 사업부의 니즈를 파악하기 위한 질문을 합니다. 그리고 부족한 부분을 확인하여 보완을 요구하기도 합니다.

 

대부분의 고객이나 담당 부서, 임원은 알아서 빠르게 개발해 주기를 희망합니다. 스스로 잘 모르기 때문에 이런 질문이 불편할 수도 있습니다. 그러다 보니 질문 없이 문서 정리를 깔끔하게 보고하는 기획자가 편하게 느껴질 수 있습니다. 그리고 마음에 조금 남아 있는 불안감은 기획자의 스펙으로 잠재웁니다.

 

문제는 스펙도 상당히 부풀려지거나, 실제로는 현재 개발과 맞지 않는 내용일 수 있습니다.

 

대형 프로젝트나 대기업 프로젝트의 경우 많은 부서와 인력이 참여합니다. 대기업 내 부서라도 그냥 보조적 역할만 하는 인력도 생각 이상 많습니다. 참여 인력도 3차나 4차 협력사에서 단순 작업만 했을 수도 있습니다. 그러나 이들도 프로젝트 문서 접근은 가능합니다. 문서 관리가 타이트하지 않는다면 자신의 레퍼런스를 위해 문서를 가지고 나올 수도 있습니다. 

 

이들은 이후 프로젝트에서는 자신이 모든 것을 다 한 것처럼 이야기하기도 합니다. 간단한 시나리오, 시뮬레이션, 인바스켓 등 방법으로 검증을 해 보면 이런 기획자의 스펙 부풀리기는 금세 들통이 납니다. 그런데 기획 PL이나 PM도 기획을 모르는 경우가 많아 그냥 넘어가는 것입니다.

 

과거 피처폰 시대 개발로 성공한 기업이 스마트폰 시대가 되면서 적응 못한 기업도 있습니다. 그러나 반대로 피처폰에서는 별로였다가 스마트폰 시기가 오자 성공한 기업도 있습니다.

 

온라인 IT와 같이 빠르게 변하는 시장에서는 과거 스펙이 현재 개발 작업의 발목을 잡는 경우가 종종 있습니다. 마치 피처폰의 성공이 스마트폰에서 실패를 만든 것 같이 말입니다.

 

그러므로 스펙은 현재 개발에 필요한 역량이 될 때만 의미가 있습니다. 이 또한 평가를 해야 합니다. 만약 스펙만 보고 정확한 평가를 하지 않는다면 그 프로젝트는 정치적으로 변하게 됩니다. 프로젝트 참여 기획자, 개발자에게는 이 기간 작업이 밥벌이 이기 때문입니다.