메모 (feat. 외주 개발사와 대화하기)

 

#1

개발사 또는 개발자는 당신의 프로젝트에 관심이 없다. 따라서 투자자에게 설명하듯 장황하게 설명할 필요 없다. 그리고 본인이 준비하는 사업이 얼마나 매력적인지, 왜 이 사업을 하려는지, 누가 이 사업을 도와주고 있는지는 궁금하지 않다. 만들려는 것이 무엇이고, 일정과 예산이 궁금할 뿐이다. 무엇을 언제까지 만들고 싶은지 명확히 정리하자.

사업의 파트너를 찾는 것과 개발사를 찾는 것은 분명 다르다. 개발사 입장에서 ‘파트너’라는 단어는 ‘싸게 해달라’는 의미밖에 안된다. ‘나중에 잘 해주겠다’는 얘기도 역효과다. 당신은 개발사와 처음 일해볼 가능성이 크지만 개발사는 수많은 사업가와 기업 대표, 직장인들을 상대해왔다.

.

#2

개발자 또는 개발사가 성의와 능력을 갖추고 있다고 가정했을 때, 가급적 하나의 프로젝트로 진행하기보다는 두세 번으로 나눠서 진행하는게 좋다. 핵심적인 사용자 플로우만 구현해서 버그 수정까지 완료된 ‘클린 버전’을 하나 만들고, 그 동안 정리해놓은 주요 기능들을 하나씩 구현해서 업데이트하는게 좋다. 프로젝트 설계 시점에 가장 중요한 의사결정이라고 생각한다.

중요한 주제인만큼 좀 더 얘기해보자.

보통 모바일 서비스 하나를 기획하는데 1달 정도의 시간이 걸린다. 보통 1달의 시간이면, 기본적인 기능들을 배치하고, 중요한 UX를 결정할 수 있다. 이 정도가 완료되면 디자인이 시작된다. (상황에 따라서는 기능 명세서가 완료되어, 개발이 디자인과 함께 시작될 수도 있다.) 경험적으로는 1달 분량이 넘어가는 기획은 프로젝트에 참여하는 전체 인원이 한번에 이해하기 어렵다. 그만큼 시행착오가 생기고, 프로젝트 종료 시점에 테스트해야할 분량이 많아진다. 당연히 개발자가 사소하게 잘못 이해했던 부분이 크게 돌아오기도 한다. 내가 생각하는 적정 분량은 기획 1달, 디자인 1달, 개발 3개월이다. 기획은 독립적으로 이루어지고, 디자인과 개발은 동시에 진행될 수 있다. 이 정도면 클라이언트가 쉽게 얘기하는 ‘A 서비스를 기본으로 B, C, D 와 같은 차별화 포인트가 핵심인 서비스’를 만든다고 할 때, 기본이 되는 A 정도를 만들 수 있다. 어쩌면 A의 기본 뼈대만 구현할 수 있는 시간이기도 하다.

어쨌든 기본 뼈대가 완성되면 몇 가지 긍정적인 결과가 생겨난다.

  • A를 완성하는 과정에서 개발팀이 비로소 서비스의 구조를 이해한다.
  • 따라서 개발팀은 B, C, D를 꽤나 효율적으로 개발할 수 있다.
  • 운이 좋다면 개발팀은 서비스에 흥미를 갖을 수 있다.
  • 프로젝트 전체가 실패할 가능성이 줄었기 때문에 어느정도의 심리적 안정감이 생긴다.
  • 클라이언트가 영업, 마케팅, 투자 등으로 ‘드디어’ 바빠지기 시작한다.

.

그게 아니라 원하는 기능을 한번에 구현하고자 한다면 다음의 조건이 필수적이다.

  • 프로젝트 전체를 디테일하게 이해하고, 의사결정할 수 있는 풀타임 PM이 있어야 한다.
  • PM은 가급적 클라이언트에 소속되는 것이 좋고, 온전히 한 프로젝트만을 담당해야 한다.
  • PM을 지원할 수 있는 QA 담당자가 필요하다. 풀타임 참여가 아니어도 좋다.

.

만약 역량있는 풀타임 PM과 그를 지원할 QA 담당자가 없다면, 프로젝트는 거의 실패한다. 그리고 그들이 클라이언트에 소속되어야하는 이유는 간단하다. 아마도 개발자/개발사가 PM과 QA까지 지원하기에는 프로젝트 예산이 여유롭지 않을 가능성이 높기 때문이다. 당연히 그들은 의사결정 권한이 없기도 하다.

.

#3

묻기전에 검색은 한 번 해보자.

.

#4

미팅보다는 전화로, 전화보다는 이메일로 연락하자. 외부에서 미팅 한번 하고나면 퇴근시간이다. 그리고 친한 사이가 아니라면 카카오톡은 지양하자. 페이스북 메시지도 좋지 않다. 이메일을 보내고, 필요하다면 전화를 하자. 이메일 회신이 느리거나, 이메일을 통해 명확히 커뮤니케이션할 수 없는 개발사라면 함께 일하지 않는게 좋다.

.

#5

프로젝트를 하고 안하고는 고객의 선택이다. 하지만 선택을 했다면 명확히 알려주는게 좋다. ‘준비해서 다음 주, 다음 달에 연락하겠다’는 얘기는 안하는게 좋다. 차라리 ‘잘 모르겠으니 시간을 갖고 고민해보겠다’고 솔직하게 얘기하자. 그리고 고민 끝에 다시 연락했다면, 다시 원점으로 돌아가지 말자. 같은 얘기를 무한히 반복하는건 서로에게 피곤한 일이다.

실제로 이런 일은 자주 있다. 문의 > 논의 > 견적 > 고민의 무한 루프에 빠지는 사람이 많다. 고민은 견적을 받고 하는것이 아니라 문의하기 전에 하는 것이다.

.

#6

기획은 기획자가, 디자인은 디자이너가, 개발은 개발자가 하는 것이다. 처음 기획하는 스타트업 대표가 온갖 꿈과 희망을 담아 만들어놓은 기획안은 사실 쓸모가 없다. ‘기획은 완료되었고…’로 시작하는 프로젝트를 가급적 피하는 이유가 있다. 그 외에도 피해야할 단어들은 많다. 가급적 프로젝트의 난이도와 기간을 표현하는 ‘형용사’는 쓰지 말자. ‘심플하게…’로 시작하는 문장을 듣는다면, 그 프로젝트도 가급적 피하려 노력한다.

오히려 어려운 것을 어렵게 표현하는게 좋다. 개발자라면 어느정도는 새로운 기술과 도전에 열려있다. 어려워보이지만 의외로 쉽게 해결되는 기능들이 많다. 원하는 것을 정확하게 전달하면서, 개발자에게 해결책을 요구하는 것이 좋다.

.

그렇다면, 처음 개발을 의뢰해야하는 입장에선 어떻게 접근하는게 좋을까. ‘난 내가 원하는게 무엇인지 모르겠다’에서 출발하는게 가장 합리적이다.

.

1단계.

전문 프리랜서 기획자를 고용한다. 전체 기획안을 의뢰하기보다는 1주일에 정해진 시간만큼의 기획 업무와 한 차례의 미팅을 요청한다. 즉, 기획자의 기획 속도가 내가 생각하고, 고민하는 속도를 넘어서지 않도록 만드는 것이 중요하다. 기획자가 한 페이지를 기획했다면, 난 1주일 동안 그 한 페이지를 놓고 고민하고, 그 결과를 다음 미팅에서 피드백한다. 이 과정을 무한히 반복한다. 두세달 정도가 지나면, 어느정도 단단한 기획안이 만들어질 수 있다. 이 때는 돈이 좀 들더라도, 좋은 기획자를 고용하는 것이 좋다.

.

2단계.

디자인을 의뢰한다. 이 때는 한 명의 디자이너를 고용하기보다는 99designs와 같은 서비스를 이용하는 것도 좋다. 디자인은 1단계에서 작성한 기획안을 수정하지 않는 범위에서 제한적으로 진행한다. ‘좋은 디자인 아이디어’를 발견하더라도 기획안과 다른 부분이 있다면, 다음으로 미루는 것이 좋다. 디자인은 기획안에 색을 입히고, 폰트와 라인을 정리하는 개념으로 진행한다. 이런 식의 디자인이라면 한 달안에 마무리될 수 있다.

.

이제 기획안도 있고, 디자인도 있다. 개발만 남았다. 이제 개발을 진행하기 전, 해야할 일이 하나 남았다. 1) 이걸 정말 개발할 것인지 다시 한번 고민한다. 2) 그리고 기획안에 포함된 기능들을 A.필수, B.필요, C.욕심으로 나눈다.

  • A.필수는 ‘내가 테스트해보고 싶은 서비스의 핵심’ 기능을 의미한다.
  • B.필요는 ‘앱/웹 서비스라면 보통은 다들 가지고 있는 보편적’ 기능을 의미한다.
  • C.욕심은 ‘기술적 차별화를 위한 모든 기능’을 의미한다.

예를 들어 최근에 개발을 완료한 온라인 커머스의 경우 A.필수는 로그인/회원가입, 상품 리스트, 상품 세부, 카트, 주문서, ‘할부 결제’다. 여기서 핵심은 상품을 보고, 할부 금융을 통해 결제할 수 있는 시스템이 개발되는 것이었다. 따라서 과거 주문 내역, 프로필 정보 수정, 배송 추적, 배송지 관리, 쿠폰 및 적립금 등은 B.필요 사항으로 분류되었다. 거의 모든 커머스 서비스가 제공하는 매우 일반적인 기능들이지만, 이번 프로젝트에서는 우선순위가 낮았고, 이 중 일부는 개발 범위에 포함되지 않았다. C.욕심 사항에서는 할부 금융을 이용할 때 해당 ‘제2금융권’ 시스템과 연동하는 작업이었다. 즉, 사용자가 상품을 골라 할부 금융을 신청하면, 할부 금융 업체의 내부 심사 프로세스와 연동되는 형태였다. 서비스의 성격을 설명할 수 있는 중요한 기능이지만, 그만큼 개발 난이도가 높은 영역일 수 있다.

.

3단계.

개발을 의뢰한다. 반드시 A.필수 항목의 개발만 요청한다. 그럼 누구와 개발을 해야할까. 개인적인 경험으로는 다음과 같다. 좀 우울한 결론이지만 현실이 이렇다.

  • 회사의 크기는 개발 결과물과 연관성이 없다.
  • 견적의 크고, 작음 역시 결과물과 연관성이 없다.
  • 기간의 길고 짧음도 결과물과 연관성이 없다.
  • 회사가 보유한 유사 서비스 개발 경험도 결과물과 연관성이 없다.

.

내가 생각할 때 가장 의미있는 방법은 ‘회사가 보유한 유사 서비스 개발 경험’을 확인하고, 그 프로젝트에 참여했던 개발자가 이번 프로젝트를 진행할 수 있는지 확인하는 것이다. 같은 회사라도 어느 개발자가 진행하는지에 따라 전혀 다른 결과물이 나올 수 있다. 하지만 현실적으로 개발자를 확인하는 것이 불가능에 가깝기 때문에 프로젝트는 실패할 수 있다는 (원하는 만큼의 결과가 제시간에 완료되지 못하는) 가능성을 충분히 감안하고 진행하는게 좋다.

실패하더라도 피해가 최소화될 수 있게 준비하는게 현실적이다. 그 후에 해당 개발이 성공적이라면 그 개발사와 남은 개발건을 지속하는 것이 좋다.

  • 첫 개발 프로젝트는 최소 Scope으로 진행한다.
  • AWS, Github, Google 등 필요 계정은 직접 만들어서 전달한다.
  • 초기 기획안에 대한 변경은 어떠한 경우에도 요구하지 않는다.
  • 문서화에 대한 요구는 반드시 계약서에 명시하고, 꼼꼼하게 챙긴다.
  • 테스트는 직접 진행한다.

즉, 개발사가 개발을 중단하더라도 다음 개발자/개발사가 개발을 이어갈 수 있도록 문서화하는 것이 매우 중요하다. 그리고 모든 계정은 직접 만들어서 관리한다. 예를 들어 개발사의 Github 계정이 아니라 내가 직접 Github 계정을 만들고, 여기에 개발자들을 초대한다면 개발사가 변경되더라도 소스 코드의 히스토리를 그대로 보존할 수 있다.

그리고 기획안을 변경하지 않아야하는 이유도 몇 가지가 있는데, 가장 큰 이유는 문서화다. 기획안 = 디자인 = 코드가 유지되어야 의미가 있다. 다른 개발사가 개발하던 프로젝트를 넘겨받은 경우가 몇 번 있었지만 위에서 언급한 일관성이 유지된 케이스는 단 한번도 없었다. 이 경우, 개발자가 코드와 DB 구조를 파악하는데 엄청난 시간이 소요된다.

.

늘 그렇듯, 쓰다보니 내용이 산으로…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s