개발외주 금액에 맞춘 기획 내가 원하는 서비스인가

 

서비스를 만드는 방법에는 직접, 팀빌당, 채용, 외주 네 가지 방식이 있습니다.

​

1. 직접

내가 기획자, 디자이너, 개발자라면 할 수 있는 작업을 직접 합니다.

​

2. 팀빌딩

내가 할 수 없는 부분의 작업을 할 수 있는 작업자를 구해 팀을 구성합니다.

팀빌딩에 참여하는 이유는 일하는 기간 동안 월급을 받기 위함이 아닌 내 서비스 내가 키워 내가 혜택을 보겠다는 주인의식이 있기 때문입니다.

​팀빌딩은 초기 서비스 제작 시 인건비가 들지 않아 팀 전체 구성원이 기술이 있고 마음만 있다면 부담없이 시작할 수 있다는 최고의 장점이 있습니다.

​

3. 채용

기술이 있는 인력을 채용해 6개월에서 1년 동안 서비스를 만들게 됩니다.

기획자, 디자이너, 개발자를 각 1명씩 총 3명을 각각 월 300만원 급여를 지급하는 조건으로 채용할 경우 1년동안 4대보험을 제외하고 인건비 만으로 1억 이상이 필요합니다.

​직원은 일정기간 동안 일정 장소에서 일정한 일을 하는 조건이 있어 법정 근무시간 동안 오로지 사용자를 일에만 집중할 수 있는 장점이 있습니다.

​

4. 외주

서비스를 제작하기 위한 견적과 일정을 받아 계약 하면 비상식적인 추가 작업이나 변경 작업을 요청하지 않는 한 추가적인 비용이 발생하지 않으며 사무실, 사무집기, 컴퓨터, 작업 소프트웨어도 필요하지 않습니다.

​서비스가 제대로 만들어지지 않았을 시 지급한 비용도 되돌려 달라는 소송을 할 수도 있습니다. 대부분은 적당한 선에서 작업을 완료하고 비용도 조정해서 지급하고 끝냅니다.

​가능성을 검증해야 하는 초기 서비스를 제작할 때는 가능한 저비용으로 시도하는 것이 좋기에 좋은 제작 방식은 직접 - 팀빌딩 - 외주 - 채용 순입니다.

​

1. 직접

직접 만들기 위해서는 내가 제작 가능한 현업 작업자여야 합니다. 배워서 할 수 있겠지! 배워서 할 수 있습니다. 1년 후에

​모든 것을 직접 할 수 없다면 할 수 있는 것은 하고 할 수 없는 부분은 팀구성원을 찾습니다. IT 업계에 있는 사람일 가능성이 높기 때문에 기술을 가진 팀동료를 찾는 것이 그리 어렵지는 않습니다.

​

2. 팀빌딩

알고 있는 사람이 의기투합하여 서비스를 만들기로 했다면 의무와 권리, 책임만 합의하면 됩니다. 그러나 수입 없이 1년 동안 풀타임으로 일을 할 수 없다면 파트타입으로 작업하고 여러 개인 사정으로 작업이 지연되어 팀빌딩 후 1년 이내 서비스를 오픈하면 훌륭하다고 할 수 있습니다.​

강제성이 없는 팀빌딩 방식에는 적합한 사람이 따로 존재합니다. 좋은 직원이 좋은 창업가는 아니므로 자칫 회사의 S급이 팀창업의 D급이 되기도 합니다.

많은 좋은 동료가 공동창업으로 의절하는 경우가 흔합니다.​

팀빌딩 방식은 좋은 방식이나 매우 어려운 방식입니다. 좋은 사람이어야 하고 작업 능력이 있어야 하며 자기 관리가 가능한 창업자의 자질도 갖추고 있어야 합니다.

​IT현업자가 아니라면 팀에 합류할 사람을 찾기도 어렵고 하려고 하는 서비스를 이야기 해 동료로 만들기도 힘듭니다. 보석이 좋은 것은 알지만 평생 보석만 찾아 헤매고 있다가는 정작 하고자 하는 일은 시작도 못하게 됩니다.

​

3. 채용

돈이 많이 듭니다.

​

4. 외주

프로젝트 단위의 계약으로 일정한 금액으로 일정한 기간 내 서비스를 제작 완료할 수 있습니다. 큰 기업의 대부분은 외주로 서비스를 제작하고 운영하고 관리됩니다.​

외주는 정해진 기간 내 일정 금액만 지출하여 서비스를 만들어 낼 수 있으나 큰 변수가 존재하니 앞 선 작업 기간이 늘어날 수록 개발 기간이 짧아진다는 것입니다.​

​

어떻게 외주 프로젝트가 망가지는가

 

처음 계획은 기획 1개월, 디자인 1개월, 개발 3개월로 5개월 계획을 세웠습니다.

 

 

서비스 기획을 진행하다보니 무엇이 좋을지 고민도 되고 더 나은 방법을 찾아 논의도 합니다. 비즈니스 모델도 세우고 하나 하나 결정하다 보니 0.5개월 동안 기획을 더 했습니다.

​디자인을 받았는데 마음에 들지 않고 수정 작업을 두 번 요구해 0.5개월이 더 소요되었습니다.

​외주의 특성상 작업 기간은 정해져 있으니 앞 선 작업의 늘어난 기간은 개발 작업의 단축으로 맞출 수 밖에 없습니다.

​서비스 규모가 2/3로 줄어들었다면 개발 기간도 줄어들겠으나 대부분의 서비스는 더 좋게 만들기 위해 서비스의 크기도 커지고 이용 방식도 더 좋아지므로 개발 기간은 오히려 늘어납니다.

 

정해진 개발 기간에 작업을 완료하려해도 작업은 완료될리 없습니다.

개발자를 더 추가하면 되지 않는가 싶겠으나 동시에 할 수 있는 작업이 있는 가 하면 동시에 할 수 없는 작업들이 있어 작업자를 추가해서 해결할 수 없습니다.​

작업자가 늘어나는 경우 작업에 대한 내용을 전달하고 파악하는 기간이 존재하므로 단기 작업의 경우 작업자 추가로 기간 단축의 효과를 볼 수 없습니다.

​2개월 동안 개발한 내용으로 테스트를 시작하니 오류도 많고 원하던 서비스 방식과 다르게 만들어진 부분도 발견이 됩니다.​

개발은 원래 계획되었던 3개월을 모두 사용하고 제작 기간은 6개월이 되었지만 이렇게 오픈할 수 있을까 싶은 수준으로 완성이 됩니다.

​

짧아진 개발 기간은 결과물에 영향을 미칩니다.

- 오류가 많다.

- 완성도가 떨어진다.

- 결론은 서비스를 오픈할 수 없다.

 

 

여전히 잘못된 부분을 수정하고 완성도를 높이기 위해 1개월 동안 더 개발합니다.

제작 기간은 7개월이 되었습니다.

제작 기간을 2개월을 더 들이더라고 원하던 서비스가 만들어졌다면 행복합니다.​

처음부터 기획, 디자인 작업 추가 기간 만큼 한 두달 더 연장해서 차분히 제작했다면 생기지 않았을 문제도 급하게 작업하는 바람에 결과물을 엉망으로 만들어버리는 결과가 되기 일쑤입니다.

​결과물에 끝내 마음에 들지 않는다면 재 작업에만 프로젝트 기간 만큼 들 수 있다.

​

​

외주 기간에 맞춘 기획은 내가 원하는 서비스인가

기획이 디자인과 개발 작업에 영향을 주지 않기 위해 정확하게 1개월 내에 서비스 설계를 완료하려면 수정 작업을 감안해 2, 3주 내 화면 설계를 완료하고 1주 동안 수정하여 확정해야 합니다.

​고민할 시간이 없습니다. 유사한 서비스의 화면을 나열해야 합니다. 화면을 리뷰 후 결정도 하루 이틀만에 확정해야 하며 수정 작업도 반복할 수 없습니다. 마음에 들지 않아도 기간에 맞추려면 어쩔 수 없습니다.

​좋은 아이디어에 인생을 걸고 야심차게 만드는 서비스인데 기간에 쫓겨 급하게 결정한 설계로 몇 천 만원 들여 서비스를 제작할 수는 없습니다.

​마음에 들지 않는 부분이 있어도 기간에 맞추어 오픈 할 것인지, 오픈일을 늦추더라도 서비스를 보강할 것인지의 선택에 있어서는 99% 서비스 보강을 선택합니다.

 

외주 서비스 제작의 일정은 대부분 3, 4개월이며 실제 제작 기간은 6개월, 오픈은 1년 내 하면 잘 한 것입니다.

​

​파국으로

기간 연장에는 비용이 수반됩니다. 누가 비용을 댈 것인가.

​발주자 입장에서 추가 비용을 댈 것 같으면 처음부터 여기 맡기지 않았을 것입니다.

제작사 입장에서 추가 비용 없이 인건비를 지출하면서 작업해야 한다면 가장 낮은 금액의 인력으로 어떻게든 빨리 완료시키게 될 것이고 이는 제대로 된 결과물을 보장할 수 없는 상태가 됩니다.

​끝내 원하는 수준의 서비스를 만들어 낼 수 없을 것 같다는 생각이 들면 엉킨 실타래를 푸는 것은 새로 만드는 것이 쉽다고 마음의 평안을 위해서도 손해를 무릅쓰고 이미 만든 결과물을 버리고 새로 만들기도 합니다.

맛 없는 음식을 끝까지 먹고 탈 나기보다 다른 곳에서 좋은 음식으로 행복해 지는 결정을 하는 것입니다.

​

​

안전한 외주

가장 안전한 방법은 달걀을 한 바구에 담지 말라는 격언처럼 기획, 디자인, 개발 작업을 한 번에 계약하지 않고 단계마다 계약해서 진행하는 것입니다.

기획이 1개월 걸릴 줄 알았는데 1.5개월 걸리고 디자인이 1개월 예정에 2개월 걸려도 개발은 계약이 되지 않았으므로 기간 압박을 받거나 비용 손해도 생기지 않습니다.

​디자인의 경우 마음에 드는 디자인이 나올 때 까지 짧게는 1개월, 길게는 몇 개월, 끝내 원하는 디자인을 얻지 못할 수도 있다. 각 단계의 작업이 나머지 작업 기간에 영향을 미치지 않게 하는 분리 발주는 외주의 위험성을 낮추어 줍니다.

​​

번거로움

기획, 디자인, 개발 각각의 작업자를 각각 찾아야 하고 견적과 일정도 각각 받아 계약하는 번거로움이 있지만 번거로움을 감수해서 서비스 제작 실패로 인한 비용과 시간, 스트레스를 줄일 수 있다면 번거로움을 감당할 수 있는 보험입니다.

​서비스 기획이 완성되지 않은 상태에서 개발은 위험합니다.

개발된 것을 변경하는 것은 날아가는 화살의 방향을 바꾸는 것 처럼 어렵습니다. 바꾸는데 많은 시간과 노력이 들고 그 결과는 추가 비용이 됩니다.

​​

스트린트 활용

1주일 단위의 리뷰와 검토를 반복하는 스프린트는 화면설계 만으로 개발 할 서비스 범위를 정할 수 있는 방식입니다.

​서비스 기획의 화면설계를 1주일 단위로 리뷰하고 수정해 나가며 확신이 드는 서비스 방식으로 서비스 설계를 완성하고 나서 서비스 설계 문서(스토리보드)를 가지고 디자인, 개발 견적과 일정을 업체로부터 받을 수 있습니다.

​서비스 기획 외주는 대부분 스프린트 방식으로 이루어집니다.

​​

외주 견적, 일정

서비스 설계도인 스토리보드 없이 개발 견적, 일정을 정확하게 산출할 수 없습니다.

이야기만 들으면 쉽게 만들 수 있을 것이라 생각이 드나 무엇을 어떻게 얼마나 만들어야 하는지는 상상만으로 정할 수가 없습니다. 생각은 모든 사안을 항상 실제 보다 작고 간단하게 정의합니다.

​​

분리 발주로 주도적인 서비스 제작

처음에 너무 좋았던 아이디어도 서비스 제작 과정에 계속 할지, 말지의 고민이 계속됩니다. 비용가 시간을 적게 들이면 번복할 수 있으나 모든 것을 다 쏟아 부으면 결정에 끌려가게 됩니다.

​제작의 모든 기간, 모든 상황에 옳은 결정을 할 수 있도록 번거롭지만 현명한 분리발주를 권합니다.

​​

서비스 기획 :

내가 꿈꾸는 서비스에 대해 충분히 논의하고 설계한 화면을 리뷰하면서 자신의 서비스가 완성되었을 때 어떻게 사용하게 될지 이해할 수 있어야 합니다.

​서비스 기획 전문 업체, 디지털 에이전시에 기획만, 프리랜서 서비스 기획자에게 맡길 수 있습니다.

​​

시안 디자인 :

복수의 디자이너가 복수의 시안을 제출할 수 있는 디지털 에이전시, 라우드 소싱을 이용해 시안을 받고 결정합니다.

시안 디자인을 요청하려면 서비스 설계(스토리보드) 화면 중 주요 5페이지를 제시합니다.

​​

페이지 디자인 :

결정된 시안대로 모든 페이지를 디자인 합니다. 시안 작성자가 아닐지라도 시안에 따른 페이지 디자인을 할 수 있습니다. 페이지 디자인은 페이지의 양에 따라 작업양이 결정되므로 서비스 설계(스토리보드)를 제시하여야 견적과 일정을 받을 수 있습니다.

​

​백 엔드, 프론트 엔드 개발 :

개발을 위해 서비스 설계(스토리보드)를 전달하고 리뷰 후 개발자의 질의응답을 받아 서비스를 이해시키고 개발이 시작될 수 있도록 합니다.

​질문하지 않는 개발자는 반드시 문제를 발생시킵니다. 질문이 없다는 것은 다 알아서가 아니라 내용 파악 없이 마음대로 작업하겠다는 것입니다.

​가장 안정적이고 널리 사용되는 환경과 언어로 개발합니다.

제작 후 운영 시 필요한 작업자가 동일인이 아니므로 개발한 내용을 전달받아 서비스를 수정, 유지 할 수 있도록 보편적이고 관리에 용이한 방식으로 개발을 진행합니다.

​개발 견적을 받은 후 개발사 또는 개발자를 정할 때 무엇으로 어떻게 개발할 것인지 설명을 듣고 내용을 문서로 받아 놓으며다. 계약 시에 해당 내용을 첨부합니다.