क्या लंबी अवधि में आउटसोर्सिंग कोड अधिक महंगा है? क्या यह कोड गुणवत्ता को नुकसान पहुंचाता है? [बन्द है]


16

मैं एक ऐसी कंपनी के बारे में जानता हूं जो एक सभ्य सॉफ्टवेयर उत्पाद की बौद्धिक संपदा का मालिक है और प्रतिवर्ष लाइसेंस से एक उत्कृष्ट आय बनाती है। हालांकि, निदेशक (गैर तकनीकी) विकास टीम को बनाए रखने की लागत के बारे में शिकायत करता है, क्योंकि यह लाभ मार्जिन में महत्वपूर्ण रूप से खाता है, और अन्य देशों के लिए विशिष्ट मॉड्यूल के आउटसोर्सिंग विकास पर विचार कर रहा है जो कम दर पर चार्ज करते हैं।

व्यक्तिगत रूप से, मुझे नहीं लगता कि यह दीर्घकालिक में अधिक लागत प्रभावी समाधान होगा। इससे समस्याएँ होने पर संचार टूट सकता है, इसके अतिरिक्त विशिष्टताओं को पानी से तंग होना होगा जो कि वैसे भी अधिक समय लेने में समाप्त हो सकते हैं। मेरी राय में, जब टीमों में काम करना प्रमुख होता है - या क्या यह काम करने का एक प्रभावी तरीका है?


24
प्रोग्रामर के वेतन की लागत एक सॉफ्टवेयर कंपनी के लाभ मार्जिन में खा रही है? किसने सोचा था कि ऐसा होगा?!
दिमा

20
PHB अधिक पैसा चाहता है -> PHB को पता चलता है कि उसे मजदूरी का भुगतान करना है -> PHB ने सस्ते लोगों के लिए सभी से छुटकारा पाने का फैसला किया -> कंपनी ट्यूब से नीचे जाती है। यह एक पुराना रिकॉर्ड है।
स्टीवन एवर्स

2
"प्रोग्रामर्स के वेतन की लागत एक सॉफ्टवेयर कंपनी के प्रॉफिट मार्जिन में खा रही है? कौन इसे ठग लेगा?" उत्पाद। : - /
टिन मैन

19
यह काम कर सकता है, लेकिन आपको आवश्यक संचार के कारण कोर कंपनी को नए देश में स्थित होना चाहिए। आप शायद उस निदेशक पद के साथ-साथ आउटसोर्सिंग के लिए भी काफी पैसा बचाएंगे।
डायटबुद्ध

1
सबसे खराब उदाहरणों में से एक क्वार्क और क्वार्कएक्सप्रेस है, जो 95% बाजार हिस्सेदारी से लगभग कुछ भी नहीं था।
gnasher729

जवाबों:


41

मुझे यकीन है कि किसी के पास इस काम का एक उदाहरण है, लेकिन मैंने इसे नहीं देखा है।

मैंने कई वर्षों तक फॉर्च्यून 500 कंपनी में काम किया है, जहां उन्होंने विकास का एक बहुत कुछ किया है। मेरे पास एक आउटसोर्स परियोजना के उन वर्षों में एक भी उदाहरण नहीं है, जिसकी लागत हमने स्वयं (इन-हाउस) की तुलना में कम खर्च की हो।

जबकि उनकी प्रोग्रामिंग दरें हमारी तुलना में कम थीं, हमने आउटसोर्स टीम का प्रबंधन करने में 3 गुना समय खर्च किया, जबकि हम इन-हाउस टीमों के लिए करते थे। हमारी इन-हाउस टीम की जरूरतों और क्यूए में जोड़े गए अतिरिक्त समय की अपेक्षा आवश्यकताओं को अधिक विस्तृत करने के लिए आवश्यक अतिरिक्त समय के ऊपर है क्योंकि कोड कभी भी सही होने के करीब नहीं था।


1
+1 - मेरा भी ... मुझे आश्चर्य है कि यदि सभी निगम एक ही प्ले बुक का उपयोग करते हैं।
अली

यह बहुत ज्यादा है जो मुझे उम्मीद थी।
सेठ

मैंने अपने पुराने कार्यस्थल पर इसे देखा है। उन्होंने अंत में अधिक पैसा खर्च किया, क्योंकि उन्हें दूरस्थ डेवलपर्स का प्रबंधन करने के लिए आगे और पीछे उड़ना पड़ा। कंपनी किसी भी सॉफ़्टवेयर विकास को किसी भी अधिक नहीं करती है: वे एम $ उत्पादों को अनुकूलित करते हैं।
जियोर्जियो

31

आप जल्दी कर सकते हैं, आप इसे सस्ते में पा सकते हैं, या आप इसे अच्छी तरह से कर सकते हैं। आपके पास तीनों नहीं हो सकते हैं, और मेरा तर्क है कि तीन में से दो भी एक खिंचाव हो सकते हैं।


18

एक सॉफ्टवेयर कंपनी के लिए, यह सिर्फ सादा बेवकूफ है। निकटतम वे एक उचित बुद्धिमान निर्णय के लिए मिल सकता है कंपनी को किसी अन्य स्थान पर ले जाना होगा जिसमें सस्ती प्रतिभा है।

एक सॉफ्टवेयर कंपनी अपने सॉफ्टवेयर विकास को आउटसोर्स करने वाली सॉफ्टवेयर कंपनी अब नहीं है। मैं तर्क दूंगा कि अर्जित कोई भी लाभ अल्पकालिक होगा, क्योंकि आप अपनी खुद की प्रतियोगिता बना रहे हैं। एक बार जब उन्हें पता चलता है कि वे उत्पाद को आपसे बेहतर जानते हैं, तो उन्हें भी एहसास होता है कि उन्हें अब आपकी जरूरत नहीं है।


9
+1 जैसा कि यह नियम "कभी अपनी मूल योग्यता को आउटसोर्स नहीं करता है" पर छूता है
स्पार्कली

बहुत कुछ इस बात पर निर्भर करता है कि विकास क्या है - उदाहरण के लिए, हम स्क्रिप्टिंग रिपोर्ट और डैशबोर्ड को आउटसोर्स कर रहे हैं जो हमारे समय श्रृंखला डेटाबेस उत्पाद के एपीआई का उपयोग करते हैं, क्योंकि हमारे पास घर में सभी अलग-अलग स्क्रिप्ट या ग्राहक अनुकूलन करने के लिए पर्याप्त कर्मचारी नहीं हैं। । कोर उत्पाद विकास आउटसोर्सिंग, हाँ, लेकिन सभी सॉफ्टवेयर विकास कोर योग्यता नहीं है।
पीट किर्कम

13

किसी अन्य देश की कंपनी को आउटसोर्सिंग करने का मेरा एकमात्र अनुभव मेरा आखिरी होगा। जिस कंपनी को काम पर रखा गया था, वह अपने काम को समय पर पूरा करने में नाकाम रही या दूर से भी विनिर्देशों को पूरा करने में विफल रही, और इसके परिणामस्वरूप हमें घर में फिर से बहुत कुछ फिर से लाना पड़ा।

हालाँकि, यदि आप एक विश्वसनीय कंपनी पा सकते हैं, जिस पर आप भरोसा कर सकते हैं (यानी आपने अन्य लोगों से उनके बारे में अच्छी बातें देखी / सुनी हैं) तो शायद यह सार्थक है।


क्या अनुबंध में क्लॉस नहीं थे जो अंतिम उत्पाद को निर्दिष्ट करते थे?
snmcdonald

16
@snmcdonald: उस तरह के खंड जो पर्याप्त रूप से निर्दिष्ट करने के लिए बहुत कठिन हैं, और अंतरराष्ट्रीय सीमाओं पर लागू करने के लिए बहुत कठिन हैं। और अगर आउटसोर्सिंग फर्म बस वितरित नहीं करती है, तो इससे कोई फर्क नहीं पड़ता कि अनुबंध में क्या है: आप खराब हो गए हैं। यहां तक ​​कि अगर आप उन्हें एक पैसा नहीं दे रहे हैं, तो भी आपने अपना खुद का प्रयास और उस सभी कैलेंडर का समय शौचालय के नीचे डाला है।
बॉब मर्फी

1
@snmcdonald हां अंतिम उत्पाद स्पष्ट रूप से निर्दिष्ट किया गया था, प्राथमिकता के आधार पर व्यक्तिगत भागों के साथ। जब उनके पास यह आया कि उन्होंने हमें 3 महीने तक लाइन में खड़ा किया, तो प्रोडक्ट रिलीज़ होने से लगभग 2 हफ्ते पहले, उन्होंने हमें एक अधूरा अधूरा संस्करण भेजा, जिसमें कुछ ऐसी चीजें शामिल थीं, जिनकी हमें बहुत खराब कार्यान्वयन के साथ जरूरत नहीं थी महत्वपूर्ण (यदि वे वहाँ थे)। कुल मिलाकर बहुत महंगा और निराशाजनक!
adamk

10

निर्देशक अपने कुछ अनुभवी स्थानीय डेवलपर्स को दूर देश में उन लोगों के साथ बदलना चाहता है जिनकी विशेषज्ञता वह न्यायाधीश के लिए सक्षम नहीं है, जिनके पास कोड के साथ कोई अनुभव नहीं है, और जो किसी को भी प्रत्यक्ष रूप से देखरेख या सलाह नहीं दे सकते हैं जो जानते नहीं हैं कोड।

मैं उस के माध्यम से दो बार गया है। दोनों ही मामलों में, सस्ती विदेशी कंपनियां पर्याप्त गुणवत्ता के साथ समय पर डिलीवरी करने में विफल रहीं। जब स्थानीय डेवलपर्स ने सुना कि काम विदेशों में चल रहा है, तो उन्होंने प्रतीक्षा किए जाने के बजाय अन्य नौकरियों को अनावश्यक पाया। जैसे-जैसे विशेषज्ञता का रक्तस्राव जारी रहा, अनुसूचियां फिसलती गईं, महत्वपूर्ण कीड़े ठीक नहीं हुए, ग्राहकों को गुस्सा आया और प्रतिस्पर्धियों के पास बदल गया, और अंततः दोनों कंपनियां मुड़ीं।

संचार, अपेक्षाओं और संस्कृति के साथ अजीब समस्याएं भी थीं। उदाहरण के लिए, एक विदेशी टीम बहुत कोड में जाँच नहीं कर रही थी या तुरंत ईमेल का जवाब दे रही थी। यह पता चला कि स्थानीय आईटी प्रबंधक को लागत कम रखने के लिए एक बोनस मिला, इसलिए उसके पास कम गति वाले इंटरनेट कनेक्शन पर पूरा कार्यालय था। दूसरी बार, तीसरी दुनिया के क्यूए परीक्षकों ने नियमित रूप से एक ही बग रिपोर्ट में कई बेतहाशा अलग-अलग कीड़े डाल दिए; उनके प्रबंधक बग संख्या से बाहर चलने से डरते थे।

सस्ती जगहों की कुछ टीमें ठीक हैं। मैं जो सुनता हूं, उससे लगता है कि Red Hat बीजिंग में एक बहुत ही सक्षम टीम है। लेकिन उनके पास पहले से ही टेलीकॉम के माध्यम से दुनिया भर के लोगों के साथ काम करने का अनुभव था, इससे पहले कि वे ऐसा करना शुरू कर दें, और बीजिंग में लोग Red Hat के कर्मचारी हैं, न कि एक आउटसोर्सिंग फर्म।


9

हाँ - आप जो भी भुगतान करते हैं वह आपको मिलता है।

मेरे अनुभव में, जब तक आपके बाज़ार और विकास की ज़रूरतें इतनी सरल नहीं होती हैं, तब तक उन्हें आसानी से ईमेल के माध्यम से किसी भी डेवलपर को एक संभावित भाषा अवरोध के साथ समझाया जा सकता है, और इतना सरल कि एक डेवलपर भी जो वास्तव में कंपनी में निवेश नहीं करता है, अभी भी सफल हो सकता है एक गुणवत्ता वाला उत्पाद बनाने पर, फिर हाँ आपके उत्पाद को नुकसान होगा

मैंने एक कंपनी में काम किया, जहां हमारे पास एक बड़ी स्थानीय विकास टीम थी, और हमारे उत्पाद को बस इसलिए झेलना पड़ा क्योंकि प्रबंधन टीम ने बिक्री में अधिक पैसा और प्रयास डाला। क्योंकि बिक्री में बहुत प्रयास किए गए थे, ऐसा प्रतीत हुआ कि हम "ठीक" कर रहे थे - लेकिन इसका मतलब राजस्व अर्जित करना था जिसे हम बिक्री प्रक्रिया में पैसा और संसाधन डालना चाहते थे।

हमारे पास एक दूरस्थ टीम थी लेकिन हमने उन्हें पूरी तरह से कंपनी में एकीकृत कर दिया और उन्होंने हमारी स्थानीय टीमों के समान ही भाग लिया। यही एकमात्र तरीका है कि यह काम कर सकता है । मैं उनके लिए स्थानीय टीम लीडर था और हमने नियमित रूप से उनके साथ साइट पर काम करने के लिए उड़ान भरी। हमने उन्हें स्थानीय टीमों की तरह ही कंपनी की शर्ट और जैकेट दिए। सभी बातों पर विचार करने के बाद, शायद इससे हमें 20-30% की बचत हुई। यदि आप एक ऐसा सिस्टम लगाते हैं जो लागत से अधिक कटौती करने का प्रयास करता है, तो आपके उत्पाद को उसी के अनुसार नुकसान होगा।


3

यदि आप एक गुणवत्ता आउटसोर्सिंग टीम के साथ काम कर रहे हैं, और प्रबंधन स्वीकृति मानदंडों को संप्रेषित करने और लागू करने के लिए तैयार है।

तब लागत एक घर में विकसित उत्पाद के रूप में उसी दर के बारे में होगी।

यदि आप भाग्यशाली हैं, तो आपको भी वही गुणवत्ता मिल सकती है।

मैं थोड़ा पक्षपाती हो सकता हूं क्योंकि मेरी कंपनी एक इन-हाउस डेवलपमेंट स्टाफ रखती है, और किसी भी उत्पाद विकास को आउटसोर्स नहीं किया है। मुझे उन अनुभवों पर संदेह है जो हमने एकीकरण भागीदारों के साथ किए हैं जिन्होंने विकास को आउटसोर्स किया है, उस निर्णय के साथ कुछ करना था।


3

मेरे अनुभव में, बेहतर मार्जिन प्राप्त करने की कोशिश में एक परियोजना का सबसे अच्छा समाधान आउटसोर्सिंग।

काम के दौरान हमारे पास ऐसा कुछ था और अच्छा चल रहा था, जैसा कि अन्य लोगों ने भी कहा, हमने होल चीज़ को फिर से किया और प्रोडक्शन सर्वर पर बनाए रखा। मामले पर निष्कर्ष, यह दो बार के रूप में ज्यादा लागत आई।

इस मामले पर मेरी राय यह है कि यदि आप मार्जिन आउटसोर्सिंग के विकास के बारे में कुछ करने की कोशिश कर रहे हैं, तो आप अपने निवेश को फेंक सकते हैं। यदि आप इसके बारे में सोचते हैं, तो उत्पाद की सफलता के रूप में काम करने वाली चीजों का एक हिस्सा है, इसलिए यदि आप देव-टीम बदलते हैं, तो चीजें बदसूरत हो सकती हैं।


1

अच्छी तरह से नियोजित / किया गया ओपन सोर्स सॉफ्टवेयर आपका उत्तर हो सकता है, क्योंकि यह अत्यधिक लाभदायक हो सकता है और रखरखाव कुछ हद तक एक समुदाय को सौंप दिया जाता है, लेकिन सफलता का कोई नुस्खा नहीं है। सबसे अच्छी सलाह जो मैं दे सकता हूं, वह यह है कि वास्तव में खुला स्रोत और उसके शिलान्यास के बारे में कई वार्ता की सिफारिश की जा रही है:

  • जेरेमी रुस्टन (बीटी) http://vimeo.com/856110 द्वारा "ओपन सोर्स प्रोजेक्ट कैसे शुरू करें"
  • क्रिस डिबोना (Google) http://www.youtube.com/watch?v=hmZyBVbkOQ द्वारा "ओपन सोर्स मैजिक है"
  • जोनो बेकन (कैनोनिकल) http://www.youtube.com/watch?v=zKOrWubmzAY द्वारा "एंगेज ऑफ कम्युनिटी"
  • "ओपन सोर्स प्रोजेक्ट्स और ज़हरीले लोग" बेन कॉलिन्स-ससमैन और ब्रायन फिट्ज़पैट्रिक (Google) http://www.youtube.com/watch?v=ZSFDm3UYkeE
  • "मेरे लिए यह क्या है? ओपन सोर्सिंग कोड से लाभ" बेन कॉलिन्स-सूसमैन और ब्रायन फिट्ज़पैट्रिक (Google) http://www.youtube.com/watch?v=ZtYJoatnHb8&feature=related

और शायद:

  • Roan Lavery (FreeAgent) http://vimeo.com/5588154 द्वारा "बिजनेस मॉडल कैसे चुनें"

खुले स्रोत के बारे में, मेरी राय में, न केवल आपके लिए बल्कि सभी के लिए मूल्य और रुचि का कुछ निर्माण करना है, खुले स्रोत की शक्ति समुदायों के भीतर निहित है।

इसके अलावा, यदि आपका बॉस / कंपनी सॉफ़्टवेयर खोलने में अनिच्छुक है, तो बस अपने स्वयं के व्यावसायिक तर्क की बारीकियों को जानें और जानें कि कैसे। तो, आप क्या कर रहे होंगे:

  1. अपने संसाधनों के साथ एक खुला स्रोत परियोजना से गुजरना
  2. एक समुदाय का विकास करें
  3. ???
  4. लाभ =)

हाँ, मैं गंभीर हूँ, और "???" क्या आप कभी भी पर्याप्त ब्याज इकट्ठा करने के बाद क्या रणनीति बनाना चाहते हैं, इसमें शामिल है। आज के टूल जैसे गितुब और ट्विटर से आप शब्द को आसानी से फैला सकते हैं, लेकिन मन यह है कि आपकी पहली छाप काफी दिलचस्प होनी चाहिए।

यदि आप वास्तव में खुला स्रोत नहीं चाहते हैं ( जिसे आपको इसे लागू करने से पहले एक व्यवसाय मॉडल के रूप में समझना चाहिए, यदि आप सफल होना चाहते हैं ), तो आप इसे हमेशा सेवा के रूप में लॉन्च कर सकते हैं, इसके लिए कार्सोनीफाइड वीडियो की जांच करें, लेकिन इसका मतलब है एक संपूर्ण आपकी कंपनी के लिए बहुत सी अन्य चीजें।

अंत में, खुला स्रोत होना या इसे एक सेवा के रूप में लॉन्च करना लंबे समय तक परियोजना को टिकाऊ बनाने के तरीके हैं।


1

मुझे इस उद्धरण के लेखक की याद नहीं है, लेकिन यह नाखून को मारता है।

" ढीली युग्मित टीमों को कसकर युग्मित घटकों पर एक साथ काम करना विफल रहता है। अनिवार्य रूप से "

आउटसोर्सिंग = शिथिल युग्मित टीमें।

अन्योन्याश्रित घटकों पर भौगोलिक रूप से विभाजन कार्य द्वारा लागत को कम करने की कोशिश हमेशा विफल होती है।

दूसरी ओर, मेरे अनुभव के आधार पर, सॉफ्टवेयर पोर्टफोलियो का एक पूरा हिस्सा काम कर सकता है, जिसका अर्थ है कि इसे कम लागत के साथ अच्छी गुणवत्ता में विकसित किया जा सकता है।


यह पूछे गए प्रश्न का उत्तर कैसे देता है?
gnat

सवाल का शरीर वास्तव में आउटसोर्सिंग = शिथिल युग्मित टीमों के बारे में है। अन्योन्याश्रित घटकों पर भौगोलिक रूप से विभाजन कार्य द्वारा लागत को कम करने की कोशिश हमेशा विफल होती है। दूसरी ओर, मेरे अनुभव के आधार पर, सॉफ्टवेयर पोर्टफोलियो का एक पूरा हिस्सा काम कर सकता है, जिसका अर्थ है कि इसे कम लागत के साथ अच्छी गुणवत्ता में विकसित किया जा सकता है।
मारोस अर्बनएक

1
@ मौरोसुर्बेक - आपकी टिप्पणी आपके उत्तर का हिस्सा होनी चाहिए। अपने आप से बोली एक जवाब के रूप में अपने दम पर खड़े होने के लिए वास्तव में पर्याप्त मजबूत नहीं है।

1
@MarosUrbanec +1 महान उद्धरण, मैंने आपकी टिप्पणी को उत्तर के शरीर में जोड़ दिया ताकि इसे और अधिक उत्तर-जैसा बनाया जा सके।
ट्यूलेंस कोर्डोवा
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.