आप एक सूचना जमाखोरी से कैसे निपटते हैं? [बन्द है]


29

हम सभी को उनके बारे में पता होना चाहिए - डेवलपर्स जो उम्र के लिए आसपास रहे हैं और उनके पास एक शानदार डोमेन ज्ञान है और फिर भी वे अपनी टीम के साथ उस ज्ञान को साझा करने में विफल हैं।

टीम को ज्ञान साझा करने की सख्त जरूरत है, लेकिन वे इसे होर्डर से बाहर नहीं निकाल सकते।

किन तरीकों से टीमों ने इस समस्या को सफलतापूर्वक हल किया है?


2
क्या प्रबंधन आपको वापस करता है?

एक सूचना जमाकर्ता सिर्फ जानकारी इकट्ठा करता है, होर्डिंग का मतलब यह नहीं है कि वे साझा नहीं करेंगे। शायद आपके कहने का मतलब यह है कि गुप्त, पागल या सुरक्षात्मक व्यक्ति से कैसे निपटें?
asoundmove

वास्तव में नहीं, एक सूचना होर्डर परिभाषा किसी के द्वारा है जो खुद को जानकारी रखता है। इसलिए वे उन सूचनाओं का संरक्षण कर रहे हैं जो वे पहले से ही बता रहे हैं।
अनाम टाइप

@ थोरबॉर्न - हाँ। प्रबंधन समस्या देख सकता है। लेकिन वे बहुत ही क्रूरता से अभिनय करने से घबराते हैं।
शेखजाबूटी

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

जवाबों:


35

टीम से कोड-स्वामित्व निकालें। काम का बोझ फैलाएं। कोड-समीक्षाएं करें। ज्ञान हस्तांतरण सत्र आयोजित करें, कुछ सत्रों की प्रतीक्षा करें और फिर उन्हें अपने क्षेत्र पर एक प्रस्तुति करने के लिए कहें।

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

इसके अलावा, उनके प्रबंधक को उनके साथ बैठना चाहिए और समझाना चाहिए कि इससे उनकी नौकरी को कोई खतरा नहीं है। क्योंकि वह ऐसा कर रहा है।

व्यक्ति के लिए सभी ज्ञान का फ़ॉन्ट होना एक अच्छी बात है । यह उसे अन्य, अधिक रोचक, चीजें करने के लिए मुक्त करता है।


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

1
@ l0b0 - अगर कोई कंपनी सफल होती है, तो हमेशा कुछ और करना पड़ता है, बैकबर्नर पर अन्य प्रोजेक्ट। मुझे उम्मीद है कि एक प्रबंधक कंपनी को बेचने के लिए पर्याप्त विश्वास करता है।
पीडीआर

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

8
@Xcaliburp - फिर, यदि आप उस पर ध्यान केंद्रित कर रहे हैं तो वह विरोध करेगा। यदि आप इसे टीम नीति बना रहे हैं, तो वह केवल इतनी देर तक पकड़ बना सकता है। अगर वह सीधे इनकार करता है तो उसे निकाल दिया जाना चाहिए। मैं उन कंपनियों में गया हूं, जिन्होंने किसी को अपरिहार्य रूप से खो दिया है और आप जानते हैं कि क्या है? हम बच गए।
पीडीआर

9
आपकी टीम के लिए हानिकारक कुछ भी करना आपकी नौकरी खोने का एक कारण होना चाहिए।
जेएफओ

33

मेरा मानना ​​है कि गेराल्ड वेनबर्ग ने इस सटीक प्रकार के व्यक्ति का उल्लेख किया था जब उन्होंने द साइकोलॉजी ऑफ़ कंप्यूटर प्रोग्रामिंग में टिप्पणी की थी (क्योंकि मेरे सामने पुस्तक नहीं है), यदि आप एक प्रोग्रामर को अपरिहार्य बनाने की कोशिश कर रहे नोटिस करते हैं, तो आग उसे तुरंत। 25 साल बाद जब उन्होंने पुस्तक को फिर से प्रकाशित किया, तो उन्होंने टिप्पणी की कि किसी अन्य सलाह ने उन्हें उतना धन्यवाद नहीं दिया जितना कि यह।

तो वह एक उपाय है।


1
यह इतनी शानदार बोली है, काश मैंने यह किताब पहले ही पढ़ ली होती।
अनाम टाइप

अजीब बात है कि आप यह कहते हैं .. मेरे पास हमारी कंपनी के सीईओ ने मुझे यह बताया था और वह स्विट्जरलैंड (अमेरिका नहीं) से है। यह एक अंतरराष्ट्रीय भावना प्रतीत होती है कि अगर कोई खुद को अपरिहार्य बनाने की कोशिश कर रहा है, तो उन्हें आग लगा दें।
ब्रायन

1
यह बहुत अच्छा होगा यदि मैं एक से अधिक बार उत्थान कर सकता हूं। मैं बोली के लिए आपको कम से कम +20 दे दूंगा।
जसक प्रुसिया

12

उन्हें वह दें जो वे चाहते हैं - उन सभी रखरखाव कार्यों और कार्यों को असाइन करें जो केवल उसके पास है / उसे करने के लिए ज्ञान है।

नहीं, वे नया काम नहीं कर सकते क्योंकि कोई भी अन्य इन महत्वपूर्ण रखरखाव कार्यों को नहीं कर सकता है।

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

जब तक आप उनमें से एक को दिखाना चाहते हैं कि यह कैसे करना है ...।


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

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

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

11

यह इस लेख को रैंड्स इन रिपोज से याद दिलाता है ।

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

उन मुद्दों में से कुछ को गैर-टकराव की चाल से हल किया जा सकता है:

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

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

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


9

मुझे यकीन नहीं है कि 'मना' अक्सर सही शब्द है, आमतौर पर वे बहुत व्यस्त होते हैं और स्पष्ट (उन्हें) समझाने के लिए बहुत समय निकालने के लिए खाली समय (या झुकाव, या सामाजिक कौशल) नहीं होता है। ) n00bs को।

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

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

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

यह मत भूलो कि यदि आपके पास किसी भी प्रकार का सुपर-कॉम्पलेक्स सिस्टम है (जो आप करते हैं, या नए लोगों को यह पता लगाने में सक्षम होना चाहिए) तो ज्ञान-हस्तांतरण एक बहुत लंबी प्रक्रिया है। ऐसा कोई तरीका नहीं है कि कोई भी व्यक्ति बैठ सके और किसी को पूरी तरह से गति प्राप्त कर सके, मेरे स्थान पर ऐसा काम करने में न्यूनतम 6 महीने का समय लगेगा, और फिर भी .. बिल्ली, मैं अभी भी सामान सीख रहा हूं कि हमारा उत्पाद क्या करता है और मैं क्या कर रहा हूं यहाँ लगभग एक दशक!


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

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

1
@Xcaliburp: सौभाग्य है कि 'देव जो डोको से प्यार करता है!' :)
gbjbaanb

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

@Xcaliburp: ज़रूर, लेकिन क्या आप मुझे बता रहे हैं कि आप ऐसे टन दस्तावेज़ लिखना चाहेंगे, जिन्हें हर कोई आसानी से समझ सकता है, लेकिन कोई नहीं पढ़ेगा, आप भी नहीं? ;)
फिलिप

5

प्रत्येक टीम के सदस्य के लिए संचार को एक प्रतिबद्धता बनाएं और वार्षिक समीक्षा के भाग के रूप में उनका मूल्यांकन करें।

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

सुनिश्चित करें कि संचार के लिए कोई ब्लॉक नहीं हैं, सुनिश्चित करें कि डॉक्स लिखने और जानकारी साझा करने के लिए प्रक्रिया और प्रणालियां हैं; उदाहरण के लिए विकी, शेयर पॉइंट साइट, डिज़ाइन डॉक्स आदि के लिए निर्धारित डिलिवरेबल्स।


सभी अच्छी तरह से और अच्छा है, लेकिन यह जानकारी की जमाखोरी को नहीं रोकता है। होर्डियर अभी भी ऐसे वातावरण में पनप सकता है। और एक बार जब कोई जमाखोरी करना शुरू कर देता है, तो उन्हें दंड देना कठिन होता है क्योंकि वे बहुमूल्य ज्ञान की चाबी रखते हैं।
eda-qa mort-ora-y

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

4

सुनिश्चित करें कि सभी परियोजनाओं में कम से कम दो प्रोग्रामर हैं जो इस पर काम कर सकते हैं। यह सुनिश्चित करने के लिए कि आपके पास हमेशा बैकअप होता है जब कोई फर्म छोड़ देता है।

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


3

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


5
कनिष्ठ सहायक को भूल जाओ। उसके साथ काम करने के लिए एक अनुभवी, स्मार्ट, जानकार व्यक्ति प्राप्त करें। वे शब्द के अर्थ में सहयोगी बन जाते हैं, और व्यक्ति # 2 प्रलेखन लिखता है। याद रखें, लोगों की ताकत को पुरस्कृत करें, उनकी कमजोरी को दंडित न करें।
क्रिस्टोफर महान

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

3

मेरे अनुभव में, सूचना होर्डर्स को दो प्रकारों में वर्गीकृत किया जा सकता है: जो लोग अपने ज्ञान को साझा करना पसंद करते हैं और दूसरों की मदद करने से संतुष्टि की भावना प्राप्त करते हैं, जैसे दूसरों की मदद करना, और जो लोग नहीं करते हैं। जाहिर है।

अब, दोनों पक्षों के पास अपने कारण हैं, और जो अपने ज्ञान को साझा करना पसंद करता है वह शायद ही कभी यह सब एक ही कारण के लिए बाहर कर देगा, जो अपने ज्ञान को साझा नहीं करते हैं: वे आसपास के लोगों को बनाने की कोशिश कर रहे हैं उन्हें बेहतर, और मेरी पक्षपाती राय में, वे ऐसा करने में सही हैं। (निश्चित रूप से, आपके पास वे भी हैं जो ज्ञान को केवल अपने आप को अपरिहार्य बनाने के लिए साझा नहीं करते हैं, और यह गलत कारणों के लिए है, और उन्हें दूर किया जाना चाहिए क्योंकि वे आमतौर पर उस महान के साथ शुरू नहीं होते हैं)

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

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

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

वास्तव में इनमें से एक को प्राप्त करने का केवल एक ही तरीका है जो अपने ज्ञान को स्वेच्छा से अपने ज्ञान को साझा करने के लिए पसंद नहीं करता है: इसके योग्य बनें। आमतौर पर ज्ञान है कि उनके पास पर्याप्त नहीं है (लेकिन ऐसा करना कठिन है)। Quid pro quo और वह सब। अन्यथा, बकरियों के एक जोड़े को खरीदने और में गोता लगाने।


@Phoenix - दोस्तों को बताइए कि वह खुद इसका पता लगाए और यात्रा उनके कौशल को बनाएगी? मुझे लगता है कि हर बादल में एक चांदी का अस्तर होता है ;-) मैं कहीं और काम करूँगा जहाँ मुझे कुत्ते को खाने से मदद और समर्थन मिला ...
sheikhjabootie

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

इसके अलावा, मैं सिर्फ यह सोच रहा था: यह वास्तव में "कुत्ते खाओ कुत्ते" नहीं है, क्योंकि वे व्यक्तिगत प्रोग्रामर के बीच प्रतिस्पर्धा को बढ़ावा देने की कोशिश नहीं कर रहे हैं, इसके बजाय, वे प्रोग्रामर और ज्ञान के बीच प्रतिस्पर्धा को बढ़ावा देने की कोशिश कर रहे हैं।
फीनिक्स

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

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

2

मालिक कौन है? यह कहाँ समाप्त होता है? आपको जानकारी साझा करने की आवश्यकता नहीं है। आपको प्रलेखन प्रदान करने की आवश्यकता नहीं है। लगातार चीजों को समय पर पूरा करने में विफल। कोडिंग मानकों का पालन न करें। या तो किसी को लगता है कि यह महत्वपूर्ण है या वे नहीं करते हैं। इसके परिणाम होने चाहिए। वे मूल रूप से कंपनी से चोरी कर रहे हैं।


2

जो लोग "मुझे एक गुप्त खेल मिल गया है" खेलते हैं वे सबसे बुरे हैं। ये कविताएँ असुरक्षित हैं और संकट की स्थिति में पैदा होती हैं या पनपती हैं ।

मैं उन्हें सिस्टम में किए गए हर बदलाव या संशोधन का दस्तावेज बनाऊंगा। मैं भी उन्हें शामिल करने के लिए विकसित प्रत्येक फिक्स के लिए एक पोस्टमार्टम प्रदान करूंगा ...

  • क्या हुआ
  • ऐसा क्यों हुआ
  • इसे कैसे रोका जाए
  • क्या अन्य सिस्टम एक ही बग के लिए असुरक्षित हैं

मैं इस व्यक्ति को भी ज़िम्मेदार बनाऊंगा ...

  • कोडिंग मानकों का विकास करना
  • एक कोड लाइब्रेरी बनाए रखना

1

शामिल ज्ञान के प्रकार पर बहुत कुछ निर्भर करता है; चाहे वह सीधे कोड हो, या व्यावसायिक प्रक्रिया उन्मुख हो। आमतौर पर उत्तरार्द्ध व्यवसाय में कहीं और उपलब्ध होता है ... और इसका अधिग्रहण किया जा सकता है।

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


-2

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


जिस किसी ने भी इसे ठुकरा दिया था, वह इतना विनम्र हो कि एक कारण बताए; या हो सकता है कि आप एक सूचना होर्डर भी हों?
mg1075

1
मैं नीच का कारण नहीं जानता, लेकिन मुझे लगता है कि ओपी टीम के साथ अधिक चिंतित है, और यह टीम के लिए कुछ भी करने के लिए प्रकट नहीं होता है, सिवाय इसके कि जमाखोर को हटा दें।
ज़ाचरी येट्स

@ZacharyYates - समझा। मेरी अंतर्निहित धारणा यह है कि मैंने जो कार्रवाई का सुझाव दिया है, वह अंततः स्थिति में शामिल सभी पक्षों की मदद कर सकता है, यहां तक ​​कि सोचा गया कि इसका मतलब होगा कि टीम को छोड़ने वाला होर्डर।
mg1075
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.