외주 잘 맡기는 방법 3부: 외부 업체와 Co-working 하기

[외주 잘 맡기는 방법] 시리즈 보러가기 ▼

외주 잘 맡기는방법 1부: 외주 계약 전에 꼭 보세요!

외주 잘 맡기는방법 2부: 분쟁과 리스크를 줄이는 9가지 팁

<BPO[1], Business Process Outsourcing>

외주 인력을 효과적으로 활용하기 위해 검토해야 할 것

외주 인력의 경우 프로젝트 단위로 일정 기간만 계약을 맺고, 일을 진행하기 때문에 기간 내 인력을 잘 활용하기 위한 준비가 필요합니다. 외주 잘 맡기는 방법 마지막 3부에서는 외주와 협업하는 프로젝트에서 실제 나왔던 현장의 소리와 검토 사항을 전달해드립니다. 

1. 업무의 지침이 되는 요건과 기능 정의서를 사전에 전달합니다.

클라이언트의 생각을 명확하게 하여 서비스 구현의 방향성을 정리한 내용이 바로 요건 정의서 혹은 요건 정의 명세서입니다. 이 요건 정의서는 클라이언트 측에서 반영하고 싶은 기술 기능, 그리고 트렌드 등을 목록화하는 작업입니다. 외주 인력 입장에서는 명확한 요건을 전달받으면 투입 시, 바로 진행할 수 있어 실제 화면 기획, 디자인, 개발하는데 소모되는 시간을 단축할 수 있습니다.

2. 프로젝트 착수 시, 문서 양식이나 작업 방법을 전달해 재작업 없이 업무가 진행되도록 합니다.

별도의 문서 양식이 없거나 프로젝트 내 커뮤니케이션 방법과 작업 툴이 정해지지 않은 상태라면, 프로젝트 발주와 함께 바로 구현 방법을 빠르게 논의하여 계약 기간을 허비하지 않길 바랍니다. 예컨대 외주 기획자는 투입 시 어떤 문서도 제공받지 못해 자체적으로 UI 가이드라인 문서를 작업하고 있었는데, 작업 중간에 새로운 작업 형태를 지시받으면 재작업 공수가 발생합니다.

3. 내부 확인이 완료된 상태로 업무를 요청해주세요.

프로젝트에 얽혀있는 현업 담당자는 여러 명인 경우가 대다수이고, 간혹 이들끼리도 커뮤니케이션 미스로 요건이나 방향성이 다른 경우도 발생합니다. 예를 들어, PM이 구분한 로드맵[2] 속 메뉴 구분과 기획 PL이 전달해준 메뉴 구분이 달라 외주 인력 입장에서는 혼동이 발생한다거나 하는 일입니다.

4. 비즈니스 기획과 서비스, UX/UI 기획은 다릅니다.

계약과 상황에 따라 외주 기획자가 요건과 기능 정의를 직접 정리하며 화면 개발을 하는 경우도 있지만, 보통 외부 인력이 KPI 수립과 비즈니스 기획을 포괄하여 진행하기는 어렵습니다. 비즈니스의 방향성은 해당 서비스의 히스토리와 이해 관계자, 회사 내부 상황 등을 면밀히 파악하고 있어야 하기 때문입니다. 특정 스타트업은 사업 기획 담당자가 서비스, UX/UI 기획을 진행하는 경우도 있지만, 외주 업체에 기획 업무를 의뢰하는 경우라면 사업 기획 업무를 배제한 서비스, UX/UI 기획을 맡긴다고 보면 좋습니다.

외주를 주고 적극 지원해야 하는 이유

한 가지 예시를 들어보겠습니다. IT 프로젝트에서 개발 진행 경험이 없는 모 팀장은 플랫폼 서비스 개발을 진행해야 하는 상황입니다. 그러나 회사 개발 부서에서는 내부 개발 인력의 업무가 포화 상태라 인력 활용이 어렵다는 답을 받습니다. 이에 따라 IT 개발 전문 업체에 해당 프로젝트를 발주합니다. 이 프로젝트는 회사 자체 서비스와의 연동을 구현해야 하는 부분을 포함하고 있습니다. 따라서 내부 개발 인력의 긴밀한 협력이 필요합니다. 예를 들어, API 연동 규격서를 주고받거나 결제 정산을 어떻게 처리할지 등의 정책을 빠르게 확인하여 외부 개발 업체에 전달되어야 하는 것입니다. 또한 단순 문서 전달을 넘어 회사 내부의 누군가는 Bridge역할을 하며 기술적인 대화를 통해 개발을 도와야 하는 것입니다. 

그러나 이러한 사정을 모르는 모 팀장은 적절한 조치를 취하지 못했고, 외부 개발 업체는 계속해서 API 연동 규격서와 대응해 줄 내부 담당 인력을 요청합니다. 그렇게 시간이 흐르고 개발 문서 전달과 커뮤니케이션이 충분히 이루어지지 않아, 특정 요건의 개발이 안된 채로 계약 일정이 완료됩니다. 마무리가 될 때 즈음 해당 서비스 연동이 안된 것을 알게 된 모팀장은 외주 개발 업체에게 이를 건의하며, 계약 기간 외 하자 유지 보수 기간을 넉넉히 잡아 해당 요건을 제작할 것을 요청합니다. 외주 개발 업체는 계약 완료 후에 추가 요건을 반영하는 일은 모두 인건비가 발생하며, 추가로 기간을 산정하더라도 개발 가능한 일인지에 대해 의문을 표합니다. 이 논의 이후, 모팀장은 외주 개발 업체 담당이 일을 제대로 마무리하지 않았고 대표의 개인적인 욕심으로 추가 비용을 요청한다고 상부에 보고합니다. 

위의 사례는 실제 현장에서 턴키로 일을 맡아 외부 프로젝트를 진행할 때 일어났던 일들을 각색한 내용입니다. 위 사례의 외주 개발 업체는 개발에 필요한 정책과 문서를 지속적으로 요청했기 때문에 이슈 사항이 없으며, 이미 만들어 놓은 서비스에 대한 하자 보수가 아니기 때문에 추가 비용을 요청한 것은 합당합니다. 반면에 외주를 맡긴 모팀장의 대응에는 여러 가지 아쉬움이 남습니다.

• 가능한 계약 기간에 맞추어 인력을 활용하세요. 

인건비는 물론 서버 비용, 사무실 대여비 등 여러 부대 비용이 발생하는 것을 염두해야 합니다. 하염없이 인력을 활용하여 일을 진행할 순 없습니다.

• 요건 별로 담당자를 지정하고 외주 개발을 꼼꼼하게 지원해야 합니다.

PM은 단순 일정 관리와 진행 상황을 체크하는 역할을 하는 것이 아닙니다. 개발이 완료되고 정상적으로 해당 기능이 작동하는지 확인하는 순간까지 모든 업무를 지원하는 것이 PM의 업무입니다. 만일 서비스의 규모가 큰 경우, 요건 별로 해당 업무를 누가 대응해줄 것인지 정확하게 지목합니다. 담당자 지정이 있어야 외주 업체가 필요한 것을 신속하게 전달하고 세세한 부분까지 챙겨서 일을 진행할 수 있습니다. 다시 말씀드리지만, 외주 개발 업체는 알아서 일을 뚝딱 만들어주는 업체가 아니라 함께 일을 만들어가는 BP(Business Partner)입니다.

계약 완료 후 인계받을 목록 체크하기

일의 모든 결과물들은 발주를 준 회사의 자산에 포함되기 때문에 프로젝트 완료 후 계정, 문서, 소스 등을 빠짐없이 전달받아야 합니다. 턴키로 일을 맡아 진행하던 외주 업체든 상주 형태로 계약이 된 외주 인력이든 외주 개발, 디자인, 기획 인력과 프로젝트를 진행 후 아래와 같은 자료를 확인합니다.

기획

• UI 기획 프로젝트: IA메뉴 구조도, UI 가이드라인 혹은 UI 스토리보드 문서, 피그마 계정(*피그마 작업 시), QA 테스트, 통합 테스트 파일, 서비스 매뉴얼
• UX 리서치: 각 Raw Data Excel, 보고서

개발

• Aws 계정, Git 계정, Aos 소스(R Native), Ios 소스(R Native), 하드웨어 프로토콜(*하드웨어 연동 서비스인 경우), DB 설계서(각 데이터 필드 정의서), API 개발 정의서(HW/SW 연동 규격서). QA 테스트 검증 문서 및 결과

디자인

• 디자인 BI, AI 파일, UI PSD 파일, 디자인 가이드, 무드 모드, 제플린, XD 계정(*외주사와 협력 시에는 제플린 계정을 분리하여 사용해 외부에 내부 다른 프로젝트 자원과 사항이 누설되지 않도록 합니다.)

 (*참고! 회사마다 시스템마다 상황마다 인계 받을 문서는 다를 수 있습니다. 위의 케이스는 참고만 해주세요!)

마무리하며

외주 인력과 일하다 보면 서로 방어적으로 변해가기 쉽습니다. 일의 책임 소재 때문일까요? 어떤 것을 전달해야 할지, 어느 부분을 검토해야 할지를 분명하게 안다면 상대방에 대한 오해나 불신은 쌓이지 않을 것입니다. 더불어 간혹 외주 업체를 내부 직원처럼 대하는 분들을 목격합니다. 개발자, 기획자, 디자이너 구분할 것 없이 IT 인력들은 전문 영역에 대한 기술을 가지고 있고, 이에 자부심을 느끼며 일하는 분들이 많습니다. 그들의 전문성을 인정하고 격려해준다면 일을 더 잘할 수 있는 환경이 되지 않을까요? 수동적이고 방어적인 모습을 이끌어내기보다는 그들이 전문성을 적극 발휘할 수 있도록 리딩 해보시길 바랍니다.

[1]BPO (Business Process Outsourcing)는 비용을 최소화하고 작업 효율성을 높이기 위해 외부 조직에 일을 위탁 처리하는 것을 말합니다. 서비스의 사업 전략적 가치 등과 관련된 성과 평가 기준으로 업무의 기획과 운영의 S/W적 처리 과정을 일부 외부의 전문 기업에 맡깁니다.

[2]로드맵: "무엇"을 "언제까지"달성하고, "중간 목표"는 무엇이며 "목표 달성을 위한 방법"은 무엇인지 기술한다. What(무엇), When(일정), Milestone(주요 분기점), Procedure(절차), Method(방법)을 포함한다.