장기적으로 아웃소싱 코드가 더 비쌉니까? 코드 품질에 해를 끼치나요? [닫은]

적절한 소프트웨어 제품의 지적 재산권을 소유하고 매년 라이센스를 통해 많은 수입을 얻는 회사를 알고 있습니다. 그러나 비 기술적 책임자는 개발 마진이 이익 마진에 크게 영향을 미치기 때문에 개발 팀을 유지 관리하는 비용에 대해 불평하며 낮은 속도로 청구되는 다른 국가에 특정 모듈 개발을 아웃소싱하는 것을 고려하고 있습니다.

개인적으로, 이것이 장기적으로 더 비용 효율적인 솔루션이라고 생각하지 않습니다. 이로 인해 문제가 발생했을 때 통신 장애가 발생할 수 있으며, 사양은 방수가되어 더 많은 시간이 소요될 수 있습니다. 제 생각에, 팀에서 일할 때 의사 소통이 핵심이거나이 일을하는 효과적인 방법이 있습니까?

누군가 가이 작업의 예를 가지고 있다고 확신하지만 그것을 보지 못했습니다.

나는 포춘지 선정 500 대 기업에서 수년간 근무하면서 많은 개발을 아웃소싱했습니다. 아웃소싱 프로젝트의 그 해에 우리가 직접 (사내) 수행 한 것보다 적은 비용이 드는 단일 사례는 없습니다.

그들의 프로그래밍 속도는 우리보다 낮았지만, 우리는 사내 팀보다 아웃소싱 팀을 관리하는 데 3 배의 시간을 보냈습니다. 코드가 정확하지 않기 때문에 사내 팀 요구보다 요구 사항을 더 자세히 설명하는 데 필요한 추가 시간과 QA에 필요한 추가 시간이 중요합니다.

당신은 빨리 가질 수 있고, 싸게 가질 수 있거나, 잘 할 수 있습니다. 당신은 세 가지를 모두 가질 수 없으며, 세 가지 중 두 가지조차도 스트레칭이 될 수 있다고 주장합니다.

소프트웨어 회사의 경우 이것은 단순한 바보입니다. 그들이 합리적으로 현명한 결정을 내릴 수있는 가장 가까운 것은 회사를 더 저렴한 인재를 가진 다른 장소로 옮기는 것입니다.

소프트웨어 개발을 아웃소싱하는 소프트웨어 회사는 더 이상 소프트웨어 회사가 아닙니다. 나는 당신이 자신의 경쟁을 만들고 있기 때문에 벌어 들인 이익은 오래 가지 않을 것이라고 주장합니다. 그들이 당신보다 제품을 더 잘 알고 있다는 사실을 깨닫고 나면 더 이상 필요하지 않다는 것을 알게됩니다.

다른 나라에있는 회사에 아웃소싱하는 유일한 경험은 나의 마지막 일 것입니다. 고용 된 회사는 정시에 작업을 완료하지 못하거나 사양을 원격으로 충족하지 못하여 회사 전체를 다시 사내에서 다시 수행해야했습니다.

그러나 신뢰할 수있는 회사를 찾을 수 있다면 신뢰할 수 있습니다 (예 : 다른 사람들로부터 좋은 소식을 보거나 들었음).

감독은 경험이 풍부한 현지 개발자 중 일부를 판단 할 수있는 전문 지식이없고, 코드에 대한 경험이 전혀 없으며, 아는 사람이 직접 감독하거나 멘토 할 수없는 먼 나라의 사람들로 교체하려고합니다. 코드.

나는 그것을 두 번 겪었습니다. 두 경우 모두, 저렴한 외국 회사는 적절한 품질로 정시에 인도하지 못했습니다. 현지 개발자들이 해외로 일자리가 가고 있다고 들었을 때, 그들은 여분의 일자리가되기를 기다리는 대신 다른 일자리를 찾았습니다. 전문 지식 출혈이 계속됨에 따라 일정이 미끄러지고 중요한 버그가 수정되지 않았으며 고객이 화를 내고 경쟁 업체로 전환했으며 결국 두 회사가 모두 접혔습니다.

의사 소통, 기대, 문화에도 이상한 문제가있었습니다. 예를 들어 외국 팀이 많은 코드를 체크인하거나 이메일에 즉시 응답하지 않았습니다. 현지 IT 관리자가 비용을 낮추는 데 도움이되는 보너스를 얻었으므로 사무실 전체를 저속 인터넷 연결로 사용했습니다. 또 다른 시간에, 제 3 세계 QA 테스터는 일상적으로 동일한 버그 보고서에 여러 가지 다른 버그를 배치했습니다. 그들의 관리자는 버그 번호가 부족한 것을 두려워했습니다.

저렴한 장소의 일부 팀은 괜찮습니다. 내가들은 바에 따르면, Red Hat은 베이징에서 매우 유능한 팀을 보유한 것으로 보입니다. 그러나 그들은 이미 그 일을 시작하기 전에 재택 근무를 통해 전 세계에서 일하는 사람들과 수년간의 경험을 가지고 있었고 베이징의 사람들은 아웃소싱 회사가 아닌 Red Hat 직원입니다.

예-당신은 당신이 지불하는 것을 얻습니다.

내 경험상, 시장과 개발 요구가 너무 단순하지 않으면 가능한 한 언어 장벽이있는 개발자에게 전자 메일을 통해 쉽게 설명 할 수 있으며, 회사에 실제로 투자하지 않은 개발자도 여전히 성공할 수있을 정도로 매우 간단합니다. 양질의 제품을 만들면 제품에 문제가 생길 수 있습니다 .

지역 개발팀이 많은 회사에서 근무했는데 경영진이 더 많은 돈과 노력을 영업에 투입했기 때문에 제품이 어려움을 겪었습니다. 많은 노력이 영업에 부어 졌기 때문에 우리는 "정확한"일을하고있는 것처럼 보였습니다. 그러나 그것은 수익을 창출하기 위해 돈과 자원을 영업 프로세스에 계속 부어 주어야했습니다.

원격 팀이 있었지만 회사에 완전히 통합하여 현지 팀과 같은 수준으로 참여했습니다. 그것이 작동 할 수있는 유일한 방법 입니다. 나는 그들을위한 지역 팀장이었다. 그리고 우리는 그들과 정기적으로 현장에서 일하기 위해 날아 갔다. 현지 팀과 마찬가지로 회사 셔츠와 재킷을 제공했습니다. 모든 것을 고려한 후 20-30 %를 절약 할 수있었습니다. 그 이상으로 비용을 절감하려는 시스템을 구성하면 제품에 따라 어려움을 겪게됩니다.

품질 아웃소싱 팀과 협력하고 경영진이 수용 기준을 전달하고 의사를 밝힐 의향이있는 경우.

그러면 자체 개발 한 제품과 거의 같은 비용이 소요됩니다.

운이 좋으면 같은 품질을 얻을 수도 있습니다.

회사가 사내 개발 직원을 유지하고 제품 개발을 아웃소싱하지 않았기 때문에 약간 편견이있을 수 있습니다. 개발을 아웃소싱 한 통합 파트너와의 경험이 그 결정과 관련이 있다고 생각합니다.

내 경험상, 더 나은 마진을 얻으려고 할 때 프로젝트를 아웃소싱하는 것이 최상의 솔루션이 아닙니다.

직장에서 우리는 그와 같은 일을 계속했고 다른 사람들도 말했듯이 구멍 문제를 다시 수행하고 프로덕션 서버에 있던 것을 유지했습니다. 그 문제에 대한 결론은 두 배나 들었다.

이 문제에 대한 나의 의견은 개발 아웃소싱 마진에 대해 차이를 만들려고 생각하면 투자를 버릴 수 있다는 것입니다. 당신이 그것에 대해 생각하면, 제품 성공은 지정된대로 작동하는 문제이므로, dev-team을 변경하면 상황이 추악해질 수 있습니다.

잘 계획 / 완료된 오픈 소스 소프트웨어는 귀하의 답변이 될 수 있습니다. 높은 수익을 내고 유지 관리가 커뮤니티에 다소 위임 되기는하지만 성공을위한 레시피는 없습니다. 내가 줄 수있는 가장 좋은 조언은 실제로 오픈 소스와 셰 나니 간이 무엇인지에 대한 몇 가지 이야기를 추천하는 것입니다.

• Jeremy Ruston (BT)의 "오픈 소스 프로젝트를 시작하는 방법" http://vimeo.com/856110
• Chris DiBona (Google)의 "오픈 소스는 마법" http://www.youtube.com/watch?v=hmZyyBVbkOQ
• Jono Bacon의 "커뮤니티 엔진"(Canonical) http://www.youtube.com/watch?v=zKOrWubmzAY
• "오픈 소스 프로젝트 및 유독 한 사람들"Ben Collins-Sussman & Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZSFDm3UYkeE
• "무엇이 포함되어 있습니까? 오픈 소싱 코드의 이점" Ben Collins-Sussman & Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZtYJoatnHb8&feature=related

그리고 아마도 :

• Roan Lavery의 "비즈니스 모델을 선택하는 방법"(FreeAgent) http://vimeo.com/5588154

제 생각에 오픈 소스에 관한 것은 여러분뿐만 아니라 모든 사람에게 가치와 관심의 대상을 구축하는 것입니다. 오픈 소스의 힘은 커뮤니티 내에 있습니다.

또한 상사 / 회사가 소프트웨어를 열기를 꺼려하는 경우 비즈니스 로직과 노하우의 세부 사항을 분리하십시오. 그래서, 당신이하고있는 일 :

1. 리소스와 함께 오픈 소스 프로젝트를 배양하십시오
2. 커뮤니티 성장
3. ???
4. 이익 =)

그래, 난 진지하고 "???" 충분한 관심을 모은 후 추구하려는 전략을 포함합니다. Github 및 Twitter와 같은 오늘날의 도구를 사용하면 단어를 더 쉽게 전파 할 수 있지만 첫 인상은 충분히 흥미로워 야합니다.

실제로 오픈 소스를 원하지 않는 경우 ( 성공하려면 비즈니스 모델로 구현해야하며 성공하려면 ) 항상 Carsonified 비디오를 확인하기 위해 서비스로 시작할 수 있지만 전체를 의미합니다. 회사를위한 다른 많은 것들.

결국 오픈 소스가되거나 서비스로 시작하는 것은 장기적으로 프로젝트를 지속 가능하게 만드는 방법입니다.

이 인용문의 저자는 기억 나지 않지만 손톱에 맞습니다.

" 느슨하게 결합 된 팀이 밀접하게 결합 된 구성 요소를 함께 사용하면 실패합니다. 필연적으로 "

아웃소싱 = 느슨하게 연결된 팀.

상호 종속적 인 구성 요소에 대한 작업을 지리적으로 분할하여 비용을 절감하려는 시도는 항상 실패합니다.

반면에 제 경험을 바탕으로 소프트웨어 포트폴리오 전체를 옮기는 것이 효과가있을 수 있습니다. 즉, 적은 비용으로 좋은 품질로 개발할 수 있습니다.