자체 앱 개발 기획과 외주 앱 개발 기획 차이에 대해 알아보자

이 부분은 기획 개념에 해당하는 이야기됩니다. 먼저 온라인 서비스를 계획했을 때 앱으로 서비스하는 것을 결정했고, 이 서비스 과정 중 개발에 해당하는 파트의 기획입니다. 여기서 1차로 기획 목표가 설정됩니다. 또한 자체 앱으로의 관점과 외주 개발자로 앱 관점에서 기획의 목표가 달라지게 됩니다.

 

 

 

자체 앱 개발 기획과 외주 앱 개발 기획의 근본적 차이

 

결론부터 짧게 말하고 시작하겠습니다.

 

자체 앱 개발 기획은 문제 해결 기획에 더 가깝습니다. 그러나 외주 앱 개발 기획은 효율적 개발 완료에 대한 기획에 더 가깝습니다.

 

이런 차이는 일종의 TFT와 기존 생산 공정에서 나타나는 현상과 비슷합니다.

 

즉, 자체 앱 개발 기획은 사용자 문제 해결을 위해 문제 해결 조직으로 다양한 상호 보완적 인력들의 협업을 디자인하고 관리합니다. 그러므로 실제 코딩되는 속도는 느립니다. 그러나 앱 사용자 문제 해결안이 도출됩니다.

 

이어 반하여 외주 앱 개발 기획은 고객에 의해 디자인된 사용자 문제 해결 방법을 개발로 구현합니다. 이를 위해 체계적으로 공정을 설계하고 합리적으로 관리합니다. 이와 관련한 대표적 도구가 WBS입니다.

 

 

 

자체 서비스 문제 해결 기획과 외주 개발의 효율 기획의 차이

 

이하 각 상황 기획 차이에 대한 것은 제가 일을 하면서 경험한 내용과 대학에서 배운 내용을 토대로 정리한 것입니다. 

 

과거 자체 서비스를 개발하다 외주 개발 기획자로 프로젝트를 하면서 개발자와 디자이너와 협업을 하면서 기획을 했던 경험과 PM/PL의 요구로 작업을 해야 했던 경험을 대학 때 배운 학문과 연결해 분석/정리해 보았습니다.  

 

그리고 외주 관리하뎐 시절 외주사들의 고민 상담을 해 주면서 경험한 사항, 프리랜서로 관리를 받았던 내용을 서로 비교하여 그때 외주사들이 왜 이런 고민을 이야기했는지에 대한 사항도 반영하여 정리하였습니다.   

 

 

 

문제 해결 기획

 

앱 사용자 문제 해결을 위한 기획은 생산성보다는 창의성에 기반합니다. 그리고 개성이 뚜렷하고 자존감이 높은 각 분야 전문성이 높은 인력의 보완적 상호 작용이 유기적으로 이루어지도록 관리합니다. 이때 갈등은 필연적으로 발생합니다. 이 갈등이 창의적 문제 해결의 기폭제가 될 수 있도록 설계합니다. 

 

문제 해결을 위한 팀에게 문제는 정해저 있지만, 해결 방법은 정해져 있지 않습니다. 이 해결 방법이 찾는 게 미션인 것입니다. 그러므로 과정을 설계할 수 없습니다. 기획자는 상호 작용을 설계하고, 이 상호 작용이 문제 해결을 위한 방향으로 움직일 수 있도록 하는 작업을 합니다.

 

    

 

개발 효율 기획

 

외주 개발 시 먼저 요구 사항을 분석한 후 기능정의. 화면정의와 프로세스를 설계 후 스토리보드를 작성하고 개발하는 것은 과정을 기획하는 것입니다.

 

무엇을 어떻게 해야 하는지 미리 기획하고 개발을 진행한다는 말입니다. 이렇게 하는 것은 개발의 효율, 생산성을 높이기 위한 것입니다.

 

정리하면, 문제 해결 단계와 다르게 외주 개발 시에는 개발의 문제뿐 아니라 이 문제 해결을 위해 어떻게 개발 진행해야 하는지 미리 알고 작업한다는 것이 됩니다.

 

• 외주 개발 시 문제 - 개발할 앱 (계약 시 확정)
• 외주 개발 작업 과정 - WBS

 

즉 외주 개발에서 기획은 문제의 답을 찾는 게 아닙니다. 이미 답은 정해져 있습니다. 단지 답까지 도달하는 과정을 빠르고 정확하게 진행하는 것을 기획하는 것입니다.

 

이를 효율화 시스템 설계라 합니다.

 

  

 

덧붙이는 글 : 외주 앱 개발이 실패하는 주요 이유 

 

외주 앱 개발사는 같은 개발 내용을 더 적은 인력으로, 더 빨리 개발할 수 있을 때 경쟁 우위를 지닙니다.  물론 이때 개발 결과 앱의 수준은 같다는 것을 가정합니다.

 

그러나 외주 개발을 하는 SI, 웹에이전시의 개발자, 기획자, 디자이너는 월급을 받습니다. 그러므로 5달보다 6달이 해당 앱 개발로 받는 돈의 총액이 더 큽니다. 이런 이유로 투입된 인력은 더 빠르게 개발을 할 유인이 없는 것입니다. 

 

또한 1명의 개발자가 여러 일을 한다고 해서 월급을 더 주는 것은 아닙니다. 더 적은 일을 하고 같은 월급을 받는 게 외주 개발 투입 인력에게 더 좋은 것입니다. 그러나 일을 하는 것처럼 보여야 합니다. 그래서 문서의 양을 많이 하고 그럴듯하게 포장합니다. 코드도 일단 길고 복잡하게 작성하고, 디자인도 조금 수정으로 여러 개를 작성합니다.

 

미국의 어느 컨설팅 회사 광고 중 기존 컨설팅 회사를 비판하는 내용이 있었습니다. 이 광고 내용이 PPT 1000장 만들기와 ctrl+V와 ctrl+C만 있으면 컨설팅 보고서가 만들어진다는 내용이었습니다.

 

실제 내용을 판단할 수 없다면 그럴듯하게 디자인된 양이 많은 작업물이 더 그럴듯하게 보일 수 있습니다. 외주 인력 입장에서 그렇다면 실제 개발과 상관없는 산출물을 많이 만들게 됩니다.

 

이런 상황은 고객사가 설계한 사용자 문제 해결 방법을 앱으로 설계하여 개발하는 프로세스의 관리가 이루어지지 않은다는 것을 의미합니다.

 

과거 어떤 생산 공장에서 작업자들이 유튜브 보면서 작업하고, 제품들을 발로 차고 해서 문제가 된 적이 있습니다. 이 경우 당연히 해당 공장 생산 제품에서 불량이 많이 나올 것입니다.

 

외주 앱 개발 시에도 버그가 많이 발생하는 것은 바로 이 때문입니다. 고객사 문제 해결 방법 개발에 적절하지 않은 기획에 기반한 개발, 개발을 위해 필요한 연결 공정에 대한 이해 부족, 관리자가 개발 공정을 이해하지 못해 투입 인력을 형식적으로 관리하는 상황 등에 의해 개발은 실패하게 됩니다.

 

이런 상황에서 외주 개발 투입 인력은 일을 잘해 바야 나중에 곤란한 일만 겪게 됩니다. 개발을 혼자 하는 것이 아니니 깨문입니다. 여러 사람의 협업의 결과가 연결되어 작동되는 시스템에서 다른 누군가의 잘못은 시스템 버그를 발생시킵니다. 이를 이해 못 하는 관리자는 문서나 코딩 양에 따라, 자신과 친한 정도에 따라 판단하게 됩니다.