आउटसोर्सिंग में जोड़ी प्रोग्रामिंग: ग्राहक तकनीकी विशेषज्ञों के साथ आपसी समझ हासिल करना

शायद, आईटी आउटसोर्सिंग के क्षेत्र में काम करने वाली लगभग किसी भी कंपनी को एक ऐसी स्थिति का सामना करना पड़ा है, जहां न केवल व्यापारिक उपयोगकर्ता, बल्कि तकनीकी विशेषज्ञ भी ग्राहक पक्ष में परियोजना का प्रतिनिधित्व करते हैं। आमतौर पर यह स्थिति परियोजना के कार्यान्वयन को जटिल बनाती है, क्योंकि परियोजना टीम दो सज्जनों के सेवक में बदल जाती है: आपको एक ही समय में व्यापार और तकनीकी दोनों की आवश्यकताओं को पूरा करना होगा, और अक्सर ये आवश्यकताएं एक दूसरे के विपरीत होती हैं।

हालांकि, हम व्यावसायिक उपयोगकर्ताओं को अकेला छोड़ देंगे और ग्राहक के तकनीकी विशेषज्ञों और उन कठिनाइयों पर ध्यान केंद्रित करेंगे जो वे परियोजना में लाते हैं।

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

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


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

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

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

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

दरअसल, हमने जोड़ी प्रोग्रामिंग की मदद से आपसी समझ हासिल करने का फैसला किया। बेशक, जोड़ीदार प्रोग्रामिंग में विदेशी सहयोगियों को "लुभाने" का कार्य अपने आप में एक आसान काम नहीं है, लेकिन अगर यह सफल होता है, तो परिणाम अद्भुत होने का वादा करते हैं। किसी भी मामले में, यह वास्तव में महान निकला।

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

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

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

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

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

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

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

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