अनम्य प्रोग्रामर से निपटना


17

कभी-कभी प्रोग्रामर जो लंबे समय तक एक प्रोजेक्ट पर काम करते हैं, वे अनम्य हो जाते हैं, और उनके साथ तर्क करना मुश्किल हो जाता है। यहां तक ​​कि अगर हम उन्हें समझाने का प्रबंधन करते हैं, तो भी वे हमारे सुझावों को लागू करने की संभावना नहीं रखते हैं।

उदाहरण के लिए, मैं हाल ही में एक परियोजना में शामिल हुआ, जहाँ निर्माण और रिलीज़ की प्रक्रिया बहुत जटिल है और इसमें अनावश्यक बाधाएँ हैं।

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

मैं दूसरों को समझाने में कामयाब रहा और मैं अवधारणा का प्रमाण विकसित करने के प्रयास में लगा हूं। लेकिन 'वरिष्ठ' डेवलपर तैयार नहीं है, संभवतः क्योंकि वर्तमान प्रक्रिया उसे अधिक मूल्यवान बनाती है।

टीम में घर्षण पैदा किए बिना हम इस स्थिति को कैसे संभालेंगे?


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

"वे बोर्ड पर सुझाव लेने के लिए अड़े रहेंगे" - क्या आपका मतलब है "बोर्ड पर सुझाव लेने के खिलाफ ??
ozz

स्पष्टीकरण के लिए धन्यवाद, यह प्रश्न को अधिक मूल्यवान और उपयोगी बनाता है, IMO। +1!
डीन हार्डिंग

2
मैंने अक्सर सोचा है कि लंबे समय तक प्रोग्रामिंग करने के परिणामस्वरूप अंततः मानसिक अस्पताल में रखा जाएगा।
मार्सी

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

जवाबों:


21

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

ठीक है, कुछ व्यावहारिक सलाह:

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

कार्यप्रणाली के इतिहास को समझें। इसका अस्तित्व क्यों है? उस समय क्या समस्या हल हो रही थी? सुनिश्चित करें कि आपका समाधान वास्तव में टीम के लिए एक लाभ है। हो सकता है कि आपके परिवर्तन बेहतर हों, लेकिन वे वास्तव में एक समस्या को हल नहीं कर सकते हैं जो टीम के पास है।

अपनी बाधाओं को जानने के लिए। उनके प्रतिरोध और उन वस्तुओं पर काम करने के कारणों का पता लगाएं।

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

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


कार्यप्रणाली के इतिहास को समझने के लिए +1। कई उदाहरणों में ऐसी चीजें हैं जो अतार्किक दिखाई देती हैं जिनका अत्यधिक तर्कसंगत आधार है। अक्सर समस्या यह नहीं है कि प्रक्रिया गलत है, यह है कि यह है, और इसके पीछे के कारणों को बुरी तरह से समझाया गया है, क्योंकि यह मौजूदा टीम के लिए दूसरी प्रकृति है, जिसके परिणामस्वरूप एक नवागंतुक को समझाने की आवश्यकता नहीं है ।
जॉन हॉपकिंस

1
@ जॉन हॉपकिंस: वैकल्पिक रूप से, प्रक्रिया गलत है, लेकिन यह वास्तविक समस्याओं के लिए बुरी तरह से कल्पना की गई प्रतिक्रिया के बारे में आया। या तो मामले में, नवागंतुक के प्रस्तावों को पूरी तरह से वैध आधार पर खारिज कर दिया जाएगा कि वह वास्तविक समस्याओं को नहीं समझता है, और नवागंतुक की एकमात्र उम्मीद इतिहास और उन समस्याओं को समझना है जो वर्तमान प्रक्रिया का नेतृत्व करते थे।
डेविड थॉर्नले

@ डेविड - यह निश्चित रूप से संभव है, लेकिन हमारी बात वही है जो मुझे लगता है - विस्तार और इतिहास को मत मानो, कोशिश करो और समझो और फिर कॉल करें।
जॉन हॉपकिंस

2
मुझे अभी तक तकनीकी अज्ञानता के अलावा किसी भी कारण से एक टीम को "गलत तरीके से करते" देखना है। यह अभी तक एक और मामला है, जहां "नया आदमी" हर किसी से बेहतर जानता है, लेकिन इस "क्रेडिट" मुद्दे के कारण नहीं सुनी जाएगी, इसलिए हर कोई इसे साकार करने के बिना चीजों को गलत करना जारी रखेगा।
वेन मोलिना

@Wayne: अगर यह सिर्फ तकनीकी अज्ञानता थी, तो केवल ज्ञान के अंतराल को इंगित करना पर्याप्त होगा। यह देखते हुए कि ऐसा नहीं है, यह अज्ञान से कहीं अधिक है। कई लोग, उनकी प्रकृति और स्थिति से, परिवर्तन के लिए प्रतिरोधी हैं। कारणों के लिए, बहुत सारे। "क्यों लोग परिवर्तन के लिए प्रतिरोधी हैं" की एक सरल खोज बड़ी संख्या में उपयोगी परिणाम देगी।
जिम रश

7

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

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

एक टीम के निर्माण की रणनीति के रूप में, मैं सात सप्ताह में सात भाषाओं को उन लोगों के लिए सुझाऊँगा जिनसे आप परेशान हैं।

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

(1) एक डोमेन मॉडल (एक साधारण एक) (2) दो अलग-अलग भाषाओं (यानी जावा और लिस्प) का उपयोग करके इसे लागू करें

फिर, यह इस धारणा के तहत है कि वे उपरोक्त कार्य करने के लिए प्रेरित हैं और इसे प्राप्त करने के लिए अपना स्वयं का निवेश करने के लिए तैयार हैं।

उम्मीद है की यह मदद करेगा


1
कृपया "इस पुस्तक" के बजाय लिंक में पुस्तक के शीर्षक का उपयोग करें। यह उन लोगों के लिए एक कम कदम है जो पाठकों को यह तय करने के लिए कि क्या क्लिक करना है या नहीं। विशेष रूप से वे जो पहले इसे पढ़ चुके हैं।
हपरनिकेतेस

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

4

मैं यहां पूरी तरह से गलत रास्ते पर हो सकता हूं, लेकिन मुझे लगता है कि समान समस्याएं व्यापक पैमाने पर आम हैं, और मानव रूढ़िवाद से संबंधित हैं। लोग अक्सर ज्ञात व्यवहार पैटर्न को बदलने से इनकार कर रहे हैं, ऐसे कारणों से जिनका उल्लेख करने के लिए बहुत सारे हैं।

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

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

मेरा मानना ​​है कि आपके विचार के स्पष्ट लाभ के बाहर लचीला होना, यहां आपका जादू हो सकता है।


जहां क्रेडिट बकाया है, वहां क्रेडिट दिया जाना चाहिए। वरिष्ठ व्यक्ति सिस्टम के कार्यान्वयन पर अभी भी नेतृत्व कर सकता है, लेकिन फिर भी उस व्यक्ति को श्रेय देना चाहिए जिसने सुझाव दिया और कार्यान्वयन के अधिकांश विवरणों पर काम किया। यह उचित ही है।
Htbaa

वह नैतिकता है, जिस पर हमेशा विचार किया जाना चाहिए। लेकिन नियमों का एक बहुत ही रणनीतिक सेट होने के नाते, नैतिकता तत्काल परिणाम के लिए जरूरी नहीं है।
etranger

2
@ हतबा - वास्तव में काम पूरा करना शायद अधिक महत्वपूर्ण है यह सुनिश्चित करना कि सभी को उचित क्रेडिट मिले। आइए इसका सामना करें: जीवन उचित नहीं है।
स्टीफन सी

मुझे लगता है कि आप सही हैं स्टीफन C
Htbaa

3

मैं दूसरों को समझाने में कामयाब रहा और मैं अवधारणा का प्रमाण विकसित करने के प्रयास में लगा हूं। लेकिन 'वरिष्ठ' डेवलपर तैयार नहीं है, संभवतः क्योंकि वर्तमान प्रक्रिया उसे अधिक मूल्यवान बनाती है।

वरिष्ठ विकासकर्ता के चरित्र (बुरी चाल) पर आकांक्षाओं के कास्टिंग के बजाय, शायद आपको यह समझने की कोशिश करनी चाहिए कि वह क्यों अनैतिक है:

  • शायद वह सोचता है कि आप उन लोगों में से हैं जो अपने विचारों की निगरानी करते हैं। हो सकता है कि उसे संदेह हो कि आप उन तक पहुंचा सकते हैं।

  • शायद वह सोचता है कि आप समस्याओं को बढ़ा रहे हैं। (वे उतना बुरा नहीं हो सकते ...)

  • शायद वह सोचता है कि आप तकनीकी जोखिमों को पूरी तरह से समझ नहीं पाते हैं।

  • शायद वह सोचता है (जानता है) अभी और भी महत्वपूर्ण काम करने हैं।

  • हो सकता है कि आप सिर्फ उसे गलत तरीके से रगड़ें।

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

यदि आप अभी "प्रक्रिया सुधार" लाइन को आगे बढ़ाना चाहते हैं, तो मेरी सलाह है कि इसे धीरे-धीरे, छोटे चरणों में करें।

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


2

विशेष रूप से किस बारे में संस्थागत? टेक्नोलॉजीज, पैटर्न, प्रथाओं?

यदि वे लंबे समय से संगठन / परियोजना में हैं, तो संभावना है कि वे वरिष्ठ डेवलपर्स हैं और उन कॉल करने के लिए ज़िम्मेदारियों / अनुभव हैं, और परियोजना में केवल 5 बंदरों के प्रयोग की तरह ही अनुभव किया गया था ।

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


1

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

पहले जांच करें, और फिर आगे आएं। यह भी ध्यान दें, कि आप यह कैसे सुझाते हैं कि यह कैसे सुधार किया जा सकता है, यह हैंडवाविंग से बेहतर है।


1

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

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

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


0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.