आउटसोर्सिंग प्लस बैकसोर्सिंग माइनस समस्याएं

मैं कॉरपोरेट डेवलपर्स के लोगों को जानता हूं जो वास्तव में "अपने जीवन को तोड़" रहे हैं। जोरदार कपास का दरवाजा।
"हर किसी को एक प्रोग्रामर की ज़रूरत होती है," मैंने कहा, जूते लौट रहे हैं।

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

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





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



इसके अलावा, "खुद के डेवलपर्स" लंबे समय से बिखरे हुए हैं (अप्रकाशित)। वे निश्चित रूप से, स्क्रैम-ओम को खुश करेंगे ... (यह एक अलग डिमोटेशन सेट होगा)। लेकिन हमारा समाधान अब केवल समान नहीं है, बल्कि लगभग (अर्ध) तैयार है।



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



बाहरी दल का मनोविज्ञान समर कॉटेज निर्माण द्वारा अच्छी तरह से चित्रित किया गया है। किसी भी टीम ने बर्खास्त की जगह, पिछले नेताओं के काम के परिणामों को डांटना शुरू कर दिया। उनके पास वापस लड़ने का कोई मौका नहीं है।



इस तरह के "चार्ज" के बाद CIO के सिर में आशावाद की बैटरी रचनात्मकता की ऊर्जा उत्पन्न करती है, लेकिन आंतरिक डेवलपर्स के कंट्रोल्स को पूरी तरह से अलग आवृत्ति के लिए तैयार किया गया है। लेकिन यह ठीक आउटसोर्सिंग का कारण है!



इतने सारे मामलों में, "प्रोजेक्ट को साइड में देना" अपनी ही टीम पर नियंत्रण खोने के कारण होता है। हमारे बॉस कभी अच्छे डेवलपर नहीं रहे! वह लगातार हमारे मामलों में चढ़ता जाता है! उसकी समझ में नहीं आ रहा है कि वह क्या बात कर रहा है! उसी नस में जारी रखते हैं। तब शेफ मैकियावेली की शैली में प्रतिक्रिया देगा। दूसरी बाहरी टीम लेंगे।

हालाँकि बॉस अधिक कूटनीतिक व्यवहार कर सकता है। एलियंस आते हैं और चले जाते हैं, और उनका हमेशा रहेगा। "आउटसोर्सिंग" की कीमत पर, हमें अपने स्वयं के दोहन की आवश्यकता है ताकि हम अपनी अप्रासंगिकता / विशिष्टता को महसूस न करें, लेकिन आपको हमें क्रोध करने / अपमानित करने की आवश्यकता नहीं है।



समस्या विकास टीम ("बिल्लियों को कैसे चरना है") की नियंत्रणीयता "आउटसोर्सिंग" से आसानी से हल हो जाती है। लेकिन केवल सिद्धांत में और केवल उनके "विक्रेता" के साथ बातचीत में। एक अच्छे अनुबंध के लिए, वे डेवलपर्स की पीठ के पीछे लगभग वेबकैम का वादा करेंगे।



लेकिन परियोजना के पूरा होने पर स्थिति पूरी तरह से अलग होगी। केवल आनुवंशिक रूप से भोले लोगों को लगता है कि ग्राहक सब कुछ तय करता है। परियोजना की रुकावट, सबसे पहले, ग्राहक के लिए एक झटका है, क्योंकि उसका अपना बॉस भी है। इसके अलावा, CIO को न केवल एक परियोजना लेने / पैसे देने के लिए मजबूर किया जाता है, बल्कि इसे लागू करने और कई वर्षों तक इसका उपयोग करने के लिए भी मजबूर किया जाता है। यदि आपकी खुद की परियोजना रद्द करने के अधीन है, तो आप व्यापार प्रक्रियाओं (व्यावसायिक विचारों) और प्रबंधकों की जरूरतों को बदलने के मामले में "उद्देश्य वास्तविकता" को सही ठहरा सकते हैं। और अगर बाहरी लोगों के काम के परिणाम की आवश्यकता नहीं है, तो उन्हें कार्य सौंपा नहीं गया है। किसे दोष देना है? किसने कार्य निर्धारित किया है।



परियोजना की डिलीवरी होने पर, आप ग्राहक के हाथों को इतना मोड़ सकते हैं कि वह खामियों पर भी आंखें मूंद ले।



और अब, कॉरपोरेट प्रोग्रामर "और हमने चेतावनी दी है" के पुरुषवादी विशाल के तहत, उनके बॉस बैकसोर्सिंग पर निर्णय लेते हैं।



"बाहरी विकास" की सस्ताता और गुणवत्ता के बारे में मिथकों को आसानी से दूर कर दिया जाता है, अगर आप कोडिंग के बारे में विचारों से थोड़ा विचलित होते हैं और पैसे के बारे में सोचते हैं (इस विचार के सभी घृणा के लिए)। जो अभी भी भुगतान के संदर्भ में प्रोग्रामिंग के अर्थ के बारे में खुद को नहीं सोच सकते हैं, मैं अत्यधिक शादी करने और बच्चे होने की सलाह देता हूं।

1. जब हम किसी बाहरी परियोजना के पैसे पर विचार करते हैं, तो वे आंतरिक कर्मचारियों के लिए समय की लागत को आउटसोर्स करने में मदद नहीं करते हैं, कम से कम टीके को आकर्षित करने के लिए।
2. विकास की लागत कोड की गुणवत्ता से निर्धारित होती है। सिस्टम को बनाए रखने / संशोधित / विकसित करने की लागत को कम करने के लिए कोड की गुणवत्ता की आवश्यकता होती है। लेकिन यह "उनके" करने के लिए आवश्यक है, न कि "बाहरी"।
3. विकास की गुणवत्ता परीक्षण की डिग्री पर निर्भर करती है। लागू विकास में, केवल विषय क्षेत्र से परिचित लोग ही मामले लिख सकते हैं। यहां, जैसा कि यह था, इस तरह के आउटसोर्सिंग की मांग करना अशोभनीय है।
4. एक विशिष्ट परियोजना के लिए नेतृत्व का समय नए व्यापारिक विचारों को उत्पन्न करने की अवधि के साथ सराहनीय है, इसलिए यह संभव है (आगे, अधिक संभावना है) कि फाइनल में आपको कार्यक्षमता के संदर्भ में एक पूर्व-पुराना सिस्टम दिया जाएगा।
5. प्रणाली का लचीलापन और परिवर्तनशीलता वास्तुकला द्वारा निर्धारित की जाती है। बाहरी समाधानों की वास्तुकला अक्सर डिस्पोजेबल होती है। मशीन पर सार्वभौमिक पुन: प्रयोज्य इकाइयों को पीसने के लिए छड़ से "हार्ड-वेल्डेड" निर्माण करने के लिए प्रलोभन बहुत शानदार है।

यदि आप उपरोक्त बिंदुओं को उल्टा करते हैं, तो आप आसानी से रचनात्मक टीम के भीतर विकास को बनाए रखने की आवश्यकता को सही ठहरा सकते हैं। बस अपने आईटी अधिकारियों के साथ संबंधों को बढ़ाने की जरूरत नहीं है, ताकि आउटसोर्सिंग विद्रोह के प्रतिशोध का उपकरण न बने।

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

अधिकांश विशेषज्ञ तुरंत कहेंगे - आपको अच्छे / उचित दस्तावेज की आवश्यकता है! एक शतरंज के खेल की रिकॉर्डिंग चालों ने कभी भी लड़ाई को रोका नहीं, बल्कि उकसाया।



आउटसोर्सिंग में शामिल होना, आपको बैकसोर्सिंग के बारे में सोचना होगा, अर्थात मूल कंपनी की तह में परियोजना लौटाएँ। किसी भी स्तर पर इसके लिए तैयार रहना सबसे अच्छा है।



बेशक, आप आउटसोर्सिंग के खिलाफ तर्कों का लाभ उठा सकते हैं और इसे दफन कर सकते हैं। लेकिन कोई फर्क नहीं पड़ता कि आपको इसे कैसे खोदना है (हां, मजाक के रूप में)।



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

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

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

यह कई बार चला गया, पुराने समय की रिपोर्टस्मिथ, क्विकपोर्ट, रेव रिपोर्ट याद है। हर बार प्रौद्योगिकी ने निकाल दिया, और फिर रिलीज की दौड़ में खड़ा नहीं हो सका। और केवल चौथी बार हमने एक साझीदार फास्ट रिपोर्ट्स प्राप्त की, जो नए फ्रेमवर्क और मल्टी-प्लेटफ़ॉर्म पर काम करते हुए सिंक्रोनस रिलीज़ का उत्पादन करती है।

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

AnyDAC डेटा एक्सेस लाइब्रेरी के मामले में, हम आउटसोर्सिंग नहीं देखते हैं, सिवाय इसके कि डेल्फी के खुलेपन ने बाहरी समाधान जारी करने का मौका दिया। लेकिन आप फायरडैक में फिर से ब्रांडिंग के साथ प्रौद्योगिकी के "बायबैक" का पालन कर सकते हैं। इसने मल्टी-प्लेटफॉर्म दृष्टिकोण के क्रांतिकारी विकास के दौरान बुनियादी और अतिरिक्त प्रौद्योगिकी के विकास को फिर से सिंक्रनाइज़ करने की अनुमति दी।

एक पर्यवेक्षक की उपस्थिति में संविदात्मक पहल का कार्यान्वयन होता है। आउटसोर्सिंग लेता है - हाँ - क्लासिक टीके, लेकिन अंदर से पर्यवेक्षण और मार्गदर्शन के तहत। इस प्रकार, शैली सहित स्रोत कोड के स्तर पर घटकों की एकता और गुणवत्ता नियंत्रण का सम्मान किया जाता है। यहां हम पहले से ही "आउटसोर्सिंग" और "बैकसोर्सिंग" की प्रारंभिक योजना के बारे में बात कर सकते हैं।

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

• मुख्य टीम पर भार कम करना;
• प्रौद्योगिकी का तेजी से व्यापक विकास;
• मुख्य वास्तुकला / ढांचे की गुणवत्ता के हितों का अनुपालन;
• तकनीकी कार्यान्वयन की एकरूपता;
• टीम में दक्षताओं के पृथक्करण की रोकथाम;
• संसाधनों के पुनर्वितरण में स्वतंत्रता की एक और डिग्री।

कम व्यक्तित्व कारक, अधिक निष्पक्षता।



अब कई कॉर्पोरेट टीमों के लिए एक मुश्किल क्षण आता है। मोबाइल विकास के लिए नई दक्षताओं की आवश्यकता है। मोबाइल व्यवसाय समाधान के लिए अनुबंध के लिए आउटसोअर सीधे टूटने के लिए तैयार हैं। यदि यह सक्षमता की कमी के कारण है, तो डेवलपर्स शिकार बन जाते हैं, भले ही यह मूल रूप से योजनाबद्ध नहीं था। एक ही स्रोत कोड आधार पर Android और iOS के लिए मोबाइल एप्लिकेशन के लिए मल्टी-प्लेटफॉर्म डेवलपमेंट टूल पर ध्यान दें। अपनी क्षमता को अलग या नष्ट न करें। अन्यथा, अन्य लोग ऐसा करेंगे।