मेरे पुरातन सहकर्मी प्रश्न को संभालने में , विभिन्न लोगों ने सहकर्मियों से निपटने के लिए रणनीतियों पर चर्चा की जो टीम के साथ अपने वर्कफ़्लो को एकीकृत करने के लिए तैयार नहीं हैं ।
मैं, यदि संभव हो तो, एक सहकर्मी को "सिखाने" के लिए कुछ रणनीतियां सीखने के लिए, जो आधुनिक तकनीकों और उपकरणों से अनभिज्ञ है, और संभवतः थोड़ा उदासीन है।
मैंने एक प्रोग्रामर के साथ काम करना शुरू कर दिया है जो हाल ही में कंपनी के एक अलग हिस्से में, रिश्तेदार अलगाव में काम कर रहा है। उनके पास व्यापक डोमेन ज्ञान है और सबसे महत्वपूर्ण बात यह है कि उन्होंने अच्छी समस्या को सुलझाने के कौशल का प्रदर्शन किया है , ऐसा कुछ जो कई उम्मीदवारों की कमी लगती है।
हालाँकि, मैंने जो वास्तविक (C #) कोड देखा है, वह VB6 दिनों के लिए एक कमबैक है। प्रक्रियात्मक संरचना, हंगेरियन संकेतन, वैश्विक चर (दुरुपयोग static), कोई इंटरफेस नहीं, कोई परीक्षण नहीं, जेनरिक का उपयोग नहीं, फेंक System.Exception... आपको विचार मिलता है।
यह प्रोग्रामर मेरे से काफी बड़ा एक छोटा सा है और कम से कम पहले छापों द्वारा, सक्रिय रूप से सकारात्मक बदलाव की तलाश नहीं करता है । मैं बदलने के लिए प्रतिरोधी नहीं कहने जा रहा हूं , क्योंकि मुझे लगता है कि यह काफी हद तक एक मुद्दा है कि विषय कैसे भंग हो जाता है , और मैं तैयार रहना चाहता हूं।
प्रोग्रामर जिद्दी लोग होते हैं, और बन्दूक धधकते हुए और चीर-फाड़- द -श्रेड्स कोड की समीक्षा करते हुए और कड़ाई से लागू की गई नीतियों के साथ जाने वाले अंतिम परिणाम का उत्पादन करने की बहुत संभावना नहीं है । यदि यह एक नया किराया, एक जूनियर प्रोग्रामर था, तो मैं दो बार "मेंटर" रुख लेने के बारे में नहीं सोचूंगा, लेकिन मैं एक अनुभवी कर्मचारी को एक अव्यक्त नौसिखिया के रूप में इलाज करने से बहुत सावधान हूं (जो वह नहीं है - वह अभी नहीं है क्षेत्र में कुछ प्रगति के साथ तालमेल बनाए रखा)।
कोमल अनुनय और गैर-भौतिक प्रोत्साहन के माध्यम से मैं इस डेवलपर के कोड गुणवत्ता मानक डेल कार्नेगी के तरीके को बढ़ाने के बारे में कैसे जा सकता हूं? एक प्रतिकूल स्थिति पैदा किए बिना , सूक्ष्म, क्रमिक परिवर्तनों को प्रभावित करने के लिए सबसे अच्छी रणनीति क्या होगी ?
क्या अन्य लोग - विशेष रूप से अग्रणी डेवलपर्स - पहले इस प्रकार की स्थिति में थे? कौन सी रणनीतियाँ रुचि को उत्तेजित करने और एक सकारात्मक समूह को गतिशील बनाने में सफल रहीं? कौन सी रणनीतियाँ सफल नहीं थीं और इससे बचना बेहतर होगा?
स्पष्टीकरण:
मुझे वास्तव में लगता है कि कई लोग वास्तव में प्रश्न के सभी विवरणों को पढ़े बिना व्यक्तिगत भावनाओं के आधार पर उत्तर दे रहे हैं। कृपया निम्नलिखित पर ध्यान दें, जिसे निहित किया जाना चाहिए था लेकिन मैं अब स्पष्ट कर रहा हूं:
यह सहकर्मी उम्र के आधार पर केवल मेरा "वरिष्ठ" है। मैंने कभी नहीं कहा कि उनका शीर्षक, प्रभाव क्षेत्र, या संगठन में वर्षों से मेरा है, और वास्तव में, उन चीजों में से कोई भी सच नहीं है। वह एक LOB प्रोग्रामर है जो मुख्य विकास की दुकान में अवशोषित हो गया है। बस।
मैं एक नया भाड़ा, जूनियर प्रोग्रामर, या अन्य भोले बेवकूफ नहीं हूँ जो रातों-रात कंपनी को बदलने की भव्य योजना के साथ हैं। मैं मूल रूप से सॉफ्टवेयर प्रक्रिया का प्रभारी हूं, लेकिन जितने लोगों ने "लीड" के रूप में काम किया है, वे जानते हैं कि जिम्मेदारियां हमेशा ऑर्ग चार्ट के साथ सटीक संबंध नहीं रखती हैं।
मैं लोगों से नहीं पूछ रहा हूं कि कैसे अपना रास्ता , नर्क या ऊंचा पानी । मैं ऐसा कर सकता था अगर मैं चाहता था, तो शुद्ध परिणाम के साथ कि यह व्यक्ति नाराज हो जाएगा और / या छोड़ दिया जाएगा। कृपया यह समझने की कोशिश करें कि मैं ड्राइविंग परिवर्तन की सामाजिक , सहकारी पद्धति की तलाश में हूं ।
का उल्लेख है "... वैश्विक चर ... कोई परीक्षण नहीं ... फेंकने
System.Exception" का प्रदर्शित करने के लिए था कि समस्याएं सिर्फ सतही या सौंदर्यवादी नहीं हैं । अभ्यास जो अपेक्षाकृत छोटे CRUD ऐप के लिए काम कर सकते हैं, जरूरी नहीं कि वे बड़े एंटरप्राइज़ ऐप के लिए काम करें, और वास्तव में, अब तक कोड में से कोई भी वास्तव में एकीकरण परीक्षण पारित नहीं किया है।
कृपया, अंकित मूल्य पर प्रश्न लेने की कोशिश करें, स्वीकार करें कि मैं वास्तव में जानता हूं कि मैं किस बारे में बात कर रहा हूं, या तो उस प्रश्न का उत्तर दें जो मैंने वास्तव में पूछा था या उस पर आगे बढ़ गया था।
PS उन लोगों के प्रति मेरी ईमानदारी से आभार जताइए जो -did- आधार के साथ बहस करने के बजाय रचनात्मक सलाह देते हैं। मैं इसे थोड़ी देर के लिए खुला छोड़ने जा रहा हूं क्योंकि मैं वास्तविक दुनिया के अनुभवों के रास्ते में अधिक सुनने की उम्मीद कर रहा हूं।