ऑफशोरिंग विवादास्पद हो सकती है, यदि डरावनी नहीं है, लेकिन हम इसे अपने लिए कैसे उपयोगी बना सकते हैं?
हाई स्पीड इंटरनेट कनेक्शन के साथ, रैले, उत्तरी कैरोलिना में काम करने वाला एक डेवलपर और पुणे, भारत में काम करने वाला एक डेवलपर वस्तुतः अप्रभेद्य हैं। क्या आप जानते हैं कि जिन लोगों के साथ आप ईमेल का आदान-प्रदान करते हैं वे वास्तव में कहाँ रहते हैं? शायद नहीं। यह बताना और भी कठिन है कि वे अब कार्यालय में काम कर रहे हैं या घर पर। फिर भी अमेरिका (या फ़्रांस या जापान या...) में डेवलपर को भारत (या रूस, या चीन या...) में डेवलपर की तुलना में 4 गुना वेतन मिल सकता है क्योंकि हमारी जीवन-यापन की लागत बहुत अधिक है। जब तक हम उस वेतन को उचित नहीं ठहराते, वह टिकाऊ नहीं है। तो हम इसे कैसे करते हैं?
एक सहकर्मी ने आज मुझे यह बताया उसका 70% समय अगले संस्करण पर काम करने के बजाय सॉफ़्टवेयर के पुराने संस्करण को बनाए रखने में खर्च किया जाता है। रखरखाव से मेरा मतलब है ग्राहकों द्वारा बताई गई समस्याओं की नकल करना, बग्स को ठीक करना, हॉट फिक्स और सर्विस पैक बनाना, शिकायतों के समाधान के लिए प्रदर्शन में बदलाव करना, इत्यादि। इससे कोई फर्क नहीं पड़ता कि आप परीक्षण में कितना समय बिताते हैं, अक्सर देर से आने वाली इन समस्याओं में भारी लोड, या बड़ा डेटा, या ऐसे ऑपरेशन शामिल होते हैं जो आपके द्वारा घर पर किए जा सकने वाले ऑपरेशन से अधिक जटिल होते हैं। मल्टी-थ्रेडेड एप्लिकेशन विशेष रूप से समस्याग्रस्त हैं क्योंकि अक्सर आपके पास रुक-रुक कर समय-संवेदनशील समस्या होगी जो कुछ शर्तों के पूरा होने तक बिल्कुल भी दिखाई नहीं देगी।
क्या यह परिचित लगता है? आपके पास नवीन विचारों और सुविधाओं की एक लंबी सूची है जिन्हें आप अगले संस्करण में रखना चाहेंगे, लेकिन आपको समय नहीं मिल पा रहा है। प्रबंधन का वादा है कि जैसे ही ये रखरखाव संबंधी चीज़ें ख़त्म हो जाएंगी, आपको समय दिया जाएगा। लेकिन उन्होंने कभी हार नहीं मानी. प्रबंधन आपका शेड्यूल साफ़ करने, रखरखाव को टीम के हिस्से तक सीमित रखने और आपको कुछ सांस लेने का मौका देने का वादा करता है। लेकिन फिर अगले दिन एक उच्च प्राथमिकता वाला 'अभी-होना होगा' दोष आ जाता है। अनुभवी, उच्च योग्य और उच्च वेतन पाने वाले डेवलपर्स एक आपात स्थिति से दूसरे आपात स्थिति में भागते हुए अग्निशामक बन जाते हैं। इस बीच दूरस्थ टीमों को, जिनके पास ऐसा कोई बोझ नहीं है, नई परियोजनाएं और विकास के अवसर मिलते हैं, और त्वरित परिणाम देते हैं क्योंकि वे इसे पूर्णकालिक कर सकते हैं।
यह है अविश्वसनीय रूप से निराशाजनक, और मुझे लगता है कि यह बिल्कुल पीछे की ओर है। मैं चाहता हूँ भूमिकाएं बदलो.
हम वही प्रस्तावित करते हैं जिसे हम कहते हैं"स्थिरता टीमें". जैसे ही कोई उत्पाद संस्करण एक निश्चित चरण में पहुँच जाता है, चाहे वह बीटा हो या रिलीज़ उम्मीदवार या प्रारंभिक रिलीज़ या पहला जहाज, उस संस्करण की ज़िम्मेदारी पूरी तरह से स्थानीय विकास टीम से दूरस्थ स्थिरता में स्थानांतरित कर दी जाती है टीम। स्थिरता टीम कोड सीखती है और उस संस्करण के शेष जीवनचक्र के लिए सभी बग फिक्सिंग और ट्विकिंग कर्तव्यों को संभालती है। यह कठिन लेकिन अच्छी तरह से परिभाषित कार्य है, अनुभव बढ़ाने का एक अच्छा तरीका है। और, महत्वपूर्ण बात यह है कि उन्हें अगले संस्करण के डिजाइनरों को उनके द्वारा खोजे गए विरोधी पैटर्न और समस्या क्षेत्रों पर प्रतिक्रिया भेजने का मौका मिलता है।
समय क्षेत्र अंतर वास्तव में यहां आपके पक्ष में काम करते हैं। संचार भौतिक और लौकिक पृथक्करण द्वारा सीमित है, जिससे स्थिरता टीम को खोजबीन करने के लिए मजबूर होना पड़ता है और सीखें कि हॉल में जाने और विकास में बाधा डालने के बजाय सब कुछ अपने आप कैसे काम करता है टीम। एक टीम अपने कार्य दिवस के अंत में प्रश्नों की एक सूची लेकर आ सकती है, जिसे अगली टीम के कार्य के लिए रिपोर्ट करने का इंतजार रहेगा। अगले दिन फिर दूसरी टीम को पहली टीम के वापस आने पर उनके लिए उत्तर तैयार करने में पूरा समय लग सकता है काम।
इस बीच वे निराश लेकिन प्रतिभाशाली डेवलपर्स और आर्किटेक्ट हैं जो अच्छी नई चीजों पर काम करने के लिए बस थोड़ा-बहुत प्रयास कर रहे हैं। आजाद करना नवाचार और ग्राहक मूल्य प्रदान करना लगभग 100% समय।
तो आप क्या सोचते हैं? यदि आप यह पहले से ही कर रहे हैं, तो यह कैसे काम कर रहा है?