환영합니다

TECHNEST / 블로그

오프쇼어 개발 파트너 선정: 설계 검토에서 협업 역량 확인하기

범위를 명확히 정한 설계 검토를 통해 오프쇼어 파트너의 업무 이해도, 설계 판단의 근거, 피드백 대응 방식을 확인하는 방법을 소개합니다.

회사 소개서와 실적 자료는 오프쇼어 개발 파트너 후보를 추리는 데 도움이 됩니다. 하지만 업무 시스템을 맡기기 전, SIer와 CTO, PM은 정보가 부족하거나 의견이 다를 때 상대 팀이 어떻게 협업하는지도 확인해야 합니다.

한 가지 방법은 범위를 작게 정한 설계 검토를 진행하는 것입니다. 파트너가 어떻게 질문하고, 선택의 근거를 설명하며, 피드백에 따라 제안을 수정하는지 관찰하는 데 목적이 있습니다.

1. 비교할 수 있도록 공통 자료를 준비합니다

익명화한 업무 흐름 하나를 선정하고 현재 구조도, 개선 목표, 주요 제약 조건을 제공합니다. 확인된 사실과 가정을 구분하고, 이번 검토에서 설계하지 않아도 되는 범위도 명시합니다.

여러 후보를 평가한다면 동일한 자료와 기준을 사용합니다. 소요 시간, 참석자, 사전 준비 수준, 비밀 유지, 비용 발생 여부를 미리 합의합니다. 완성된 설계서를 무료로 요구하면서 이를 평가 과제로 삼는 방식은 피하는 것이 좋습니다.

2. 실제 개발을 담당할 예정인 사람과 대화합니다

영업 담당자뿐 아니라 참여 예정인 기술 책임자나 개발 조율 담당자도 초대합니다. 해결책을 소개하기 전에 문제를 어떻게 이해했는지 설명해 달라고 요청합니다.

요구사항과 가정을 구분하는지, 의사결정권자가 누구인지 묻는지, 일본 측에 확인할 사항을 파악하는지 살펴봅니다. 방안을 제시할 때 운영, 변경 범위, 유지보수성 측면에서 장점과 제약을 설명할 수 있는지도 확인합니다.

3. 피드백에 대응하는 방식을 평가합니다

가상 사례: 한 기업이 내부 승인 시스템 개선을 검토하고 있습니다. 후보 파트너는 사용자 작업을 단순화하기 위해 두 승인 단계를 합치는 방안을 제안합니다. 그런데 검토 중 일본 측에서 두 단계가 각각 다른 부서의 책임에 해당한다는 정보를 추가합니다.

처음부터 정답을 맞혔는지만 평가하지 말고 새로운 정보를 어떻게 다루는지 살펴봅니다. 목표를 다시 확인하고, 영향을 받는 설계 부분을 짚고, 대안을 제시한 뒤 누가 결정할 수 있는지 확인하는지가 중요합니다. 처음 제안을 고수하는 것보다 새로운 정보에 맞게 수정하는 태도에 주목해야 합니다.

4. 간단한 결정 기록을 요청합니다

논의 후에는 합의된 이해, 검토 중인 방안, 미해결 질문, 담당자와 다음 행동을 정리해 달라고 요청합니다. 고객이 아직 확인하지 않은 내용은 미확정 상태로 명시해야 합니다.

이 기록으로 일본–베트남 간 협업 방식도 살펴볼 수 있습니다. 용어가 일관적인지, 책임이 명확한지, 회의에 참석하지 않은 사람도 다음에 해야 할 일을 이해할 수 있는지 확인합니다.

5. 관찰한 근거를 선정 판단에 활용합니다

업무 이해도, 설계 판단의 근거, 피드백 대응, 결정 사항 관리라는 네 가지 기준으로 정리할 수 있습니다. 각 기준에 대해 실제로 관찰한 사례와 추가 확인이 필요한 사항을 기록합니다.

한 번의 검토는 여러 판단 자료 중 하나이며, 프로젝트 전체의 품질을 보장하지는 않습니다. 실제 투입 인력, 품질 관리 방식, 협업 조건, 인력의 연속성도 함께 확인해야 합니다.

구체적인 업무 과제로 TECHNEST와 대화를 시작하세요

TECHNEST는 일본 시장과 오랜 기간 협업하며 업무 시스템 설계·개발, 레거시 시스템 현대화, 일본 컨설팅 파트너와의 협력을 수행해 왔습니다.

익명화한 업무 흐름을 바탕으로 범위와 협업 방식부터 논의할 수 있습니다. 소프트웨어 아웃소싱 서비스를 살펴보거나 TECHNEST에 문의하여 다음 단계를 상담해 보세요.

TECHNEST 블로그

블로그 글 전체 보기
블로그

레거시 현대화: 다시 만들지 않을 기능부터 결정하기

시스템 재구축을 맡기기 전에 유지해야 할 기능, 추가 조사가 필요한 기능, 폐지 후보를 구분하세요. 판단 근거와 승인자를 기록하면 개발 범위를 구체화할 수 있습니다.

기사 보기