플랫폼 전문 개발사가 중요한 이유
견적서의 근거를 생각해본 적이 있나요?
제가 신기한 사실 하나 알려드릴게요.
저희는 항상 '가격'에 대한 의문을 하며 살아갑니다. 식당,마트,백화점 등에서 말이죠.

근데 유독 '인건비'기반의 가격은 묻는 것 자체를 실례라고 생각하곤 합니다.
실력좋은 도공이 빚은 도자기를 보더라도, 비싸서 못 살지언정 '감히' 가격을 흥정하려고 하지 않죠.

개발사의 견적도 마찬가지입니다. '인건비'를 기반으로 하기때문인지 "왜 이렇게 비싸죠?"라는 문의를 받아본 적이 거의 없습니다. 예산이 부족해 계약을 못하더라도 말이죠.

근데 그럼 이유도 정확하게 모를 그 견적을 얼마나 신뢰하시나요?
프로젝트의 규모는 정확하게 어디까지인지 알고 계신가요?

그래서 저희는 많은 고민과 설문을 통해 고객도 합리적으로 판단을 하실만한 '견적산출 프로세스'를 만들었고, 이를 기반으로 모든 프로젝트의 견적을 산출해볼 계획입니다.
아, 물론 '인건비'를 증명할 방법은 저희에게도 없습니다. 저희 직원들 머리위에 CCTV가 하나씩 달려있거나, 직원들 컴퓨터 화면이 실시간 공유가 된다는건 상상만으로도 끔찍합니다 :(



# 만들어질 서비스를 정확하게 보여드립니다.


조금 더 풀어서 설명드리자면, 견적을 내기 전 (물론 계약 전입니다.) '선 기획'을 해보려 합니다.

기존엔 '추상적인' 클라이언트의 요구사항을 보고 견적이 산출하였고, 이를 토대로 계약이 되었습니다.
계약 이후 '추상적이었던 요구사항'을 기반으로하여 기획을 통해 구체적인 규모가 완성되는데, 이 과정에서야 클라이언트는 서비스의 본 모습을 제대로 보게됩니다.

그렇기에 기존엔 생각하지 못했던 여러가지 아이디어가 샘솟아 꽤나 많은 기획,기능을 요구하시죠.


"이 페이지에서 저 페이지로 쉽게 이동하는 버튼이 필요하겠네요."
"지금 보니까 OO기능이 필요하네요. 추가해주세요."


눈으로 보이면 그때부턴 욕심이 생기기 마련이고, 충분히 동감합니다. 
하지만 이런일은 이슈를 동반하죠. 미리 합의된 내용에서 벗어나는 내용들이니까요.

그렇다면 미리 합의한 내용을 당시의 클라이언트는 '제대로' 인지 했을까요?
아마도 아니었을 겁니다. 설명을 10번 했더라도, 전문분야가 아닌지라 이해하시기 쉽지 않으셨겠죠.

그래서 저희는 순서를 바꿔 접근해보기로 하였습니다.
'선 기획'을 통해 프로젝트의 규모를 먼저 공유한 다음 견적을 산출함으로써, 견적에 대한 합리성을 늘려보고자 합니다.

그렇게되면 견적에 대한 문의를 '산출물'을 통해 하게 되실 것이기에, 기존의 견적 산출 방식에 비해 훨씬 합리적인 결정이 되지 않을까 예상하였습니다.
기존의 '추상적'이었던 규모가 '정확하게' 보여지면 저희또한 견적을 설명드리는게 오히려 훨씬 편리할 것 같습니다.



# 추가견적은 '절대' 없습니다.


많은 분들이 겪어보셨지만, 많은 업체들이 프로젝트 중간에 '추가견적'을 요구하곤 합니다.
이러한 현상을 겪으신 클라이언트분들과 이야기하면 보통 '업체'탓을 하며 억지로 견적을 산출했다고 생각하십니다.

물론 그런 질 나쁜 업체도 있을 수 있지만, 대부분의 개발사들은 일부러 그런 것은 아닐겁니다.
(그렇다고 저희가 그랬다는 것이 아닙니다. 스프린트는 단 한번도 추가견적을 발행한 적이 없습니다.)

위에서 설명드렸듯 대부분 클라이언트들은 '추상적'으로 머릿속에만 있던 아이디어가 기획 작업을 하며 구체화되는 과정에서 프로젝트가 눈에 들어오기 시작했을겁니다.

그래서 '전에는 몰랐었지만 이제보니' 필요한 페이지가 생겼고, 기능이 생겼을 겁니다.
개발사는 당연히 처음 요청주시는 내용이니 견적이 추가되는 것이죠.

저희가 제안 드리는 방식은 계약 전 '선 기획'을 통해 먼저 프로젝트의 규모를 확정하고 90%이상의 기능을 확정 짓게됩니다. 그 이후 견적을 논의하고 계약을 논의하기때문에, 절대로 추가견적이 산출될 수 없는 형태입니다.



# 리스크 때문에 대충해주는 것 아닌가요?


클라이언트 입장에선 견적제안 전 '선 기획'이 진행되는 건, 기존방식보단 상대적으로 무조건 나은 선택이시리라 생각합니다. 하지만 저희에겐 리스크가 생긴 셈이죠.

'기획작업'은 실제 작업자의 공수가 필요한 작업이기에 계약 이후 진행하는게 보통 방식이었꼬, 저희는 계약 이전에 실제 작업자의 공수가 사용되는 것이니 커다란 리스크를 안고 운영을 하는 셈입니다.


'선 기획'을 진행하고 계약이 안되면 어떻게 하냐구요?


어쩔 수 없죠. 근데 저희는 그런 상황을 오히려 기다립니다.
저희는 단순히 플랫폼을 만들고자 하는게 아닌 클라이언트의 '비즈니스 파트너'가 되려고 합니다.
그래서 저흰 '무조건' 출시하는 서비스는 성공해야한다고 생각합니다.

선기획으로 서비스의 형태를 모두 확인을 하였으나 계약까지 진행되지 못했다면 저희가 '두가지' 이유로 클라이언트를 만족시키지 못한 것일 겁니다.

경쟁력에 비해 견적이 비싸거나, 프로젝트를 잘 못 제작하였거나.
이유가 무엇이든 저흰 클라이언트를 만족시키지 못한 것일테고, 억지로 계약이 되었다해도 최종적으로 만족하지 못 하셨을 수도 있습니다.

이는 저희가 가진 가치관과 맞지 않기에, 초기에 계약에 실패한다는건 오히려 리스크보단 시간을 버는 일이 될 겁니다. 어차피 만족하지 못하시는 '실패한 프로젝트' 빠르게 분석하여 피드백 할 수 있으니까요.



저희가 새롭게 만든 프로세스로, 저희와 한번 일 해보실래요?
윈도우 타이틀
rsrv_cancel
삭제하기
확인
signup_vehicle_later
signup_vehicle_regist
취소
확인
Toast Title
Toast Contents
수정
삭제