‘기획실패 사례’가 주는 교훈

게임 프로그래머인 shg님의 블로그 ‘나의 게임개발 회고록’ 중 ‘기획실패 사례’를 뜯어보면서 여러가지 생각이 들었다. 처한 입장은 상반되지만 왠지 모를 동질감이랄까? 그런 것들 … ^^;

 

화성에서 온 남자와 금성에서 온 여자의 결혼처럼 서비스(혹은 SW) 개발 프로젝트 역시 기획자와 개발자 간의 원활한 소통과 협조가 프로젝트의 성패를 좌우한다. 당연한 상식처럼 들리지만 이게 사실 쉽지 않다. 기획자와 개발자는 사고와 언어부터 틀리기 때문이다. 상대방의 언어와 의도를 이해하지 못하기 때문에 프로젝트라는 배는 산으로 가기 마련이다.

 

더구나 개발 프로젝트의 경우 대개 기획자(혹은 PM)가 개발자에게 업무 요청을 하는 방식으로 진행이 되기 때문에 정보 전달은 한 쪽 방향으로만 흐르기 쉽다. 기획자는 “산출물이 왜 이딴 식으로 나왔나? 기획서를 한 번이라도 들여다 본거냐?”고 따지고 “기획서대로 해줬는데 뭐가 불만이냐? 애초에 기획이 엉망인 걸 어쩌란 말이냐”는 식이다(완곡하게 썼는데 현실은 더 처참하다 ^^)

 

혹자는 말한다. “개발자는 기획 마인드를, 기획자는 개발(혹은 영업) 마인드를 가져야 한다”고.

 

말이 쉽지 그런 전지전능한(?) 인재가 있다한 들 왜 월급받아 먹고 있겠나? 조직 체계가 갖춰진 대기업의 경우 교육과 훈련을 통해 인재를 기르려 노력한다. 하지만 조직이 커지면 수직 계열화에 따른 벽도 단단해지기 마련이다. 부서 이기주의와 사내 정치로 인해 본질보다는 이해관계에 민감해 진다. 특히 기획자는 이런 눈치가 빠르다. 결국 책임몰이는 개발쪽으로 향하고 철야는 개발자의 몫으로 떨어지기 마련이다. 이쯤되면 회복이 어렵다. 그냥 가는 거지.

 

 

 

비관론 위주로 흘렀는데 … 사실 왕도는 없다. 팀 내에 shg님같은 개발자가 있다면 행운이지만 대개 그렇지 않다. 해보고 잘못된 점은 고치고 서로 격려하고 양보하고 희생하는 거지. 그래서 리더(혹은 중간 조정자)의 역할이 매우 중요하다.

 

의미를 되새기는 의미에서 인상 깊은 문구 몇 줄을 정리해 봤다.

 

• “프로그래밍과 마찬가지로 기획 역시 확장성을 고려해야 한다.
• “게임이든 웹서비스든 모든 기획의 핵심은 마이너스(빼기)다. 더해나가 완성하는 것이 아니라 더이상 뺄 수 없을 때 까지 정제하여 완성해 나간다.”
  : 그런데 페이스북은 예외인 것 같다. 도무지 이 공식에 맞지 않는다.
• “남들이 안하는건 괜히 안하는게 아니다, 남들도 다 해보고 안되니까 안하는 것이다.”
  : 물론 당신이 풍부한 경험을 가진 천재라면 예외.
• “기획서 디버깅은 반드시 필요하다. 프로그래머는 코드상의 버그가 아닌 기획서의 버그를 수정하는 존재다.”
  : 따라서 기획자는 겸손해야 한다. 산출물은 만드는 것은 기획자가 아니라 프로그래머라는 사실을 명심하라.
• “기획서의 한 줄이 코딩을 하고 작업을 하면 기획서 100장 분량으로 뻥튀기된다. 좋은 프로그래머는 좋은 기획자이기도 하다.”
  : 그렇다고 프로그래머에게 기획을 시켜서는 안된다. 왜냐고? 시켜보면 안다.
• “기획자의 언어를 잘 이해하는것이 그 어떠한 프로그래밍 테크닉보다 우선한다."
  : 물론 그 반대도 마찬가지다. 기획자도 프로그래머의 언어를 이해할 줄 알아야 한다. 적어도 시늉이라도 해라.
• “기획서는 디버깅하기가 매우 까다롭다. 회사가 망하고 월급이 밀리고 나서야 ‘이렇게 했어야 하는데 …’라고 말하지만 이미 지나간 일이다.”