क्या सीनियर प्रोग्रामर्स को जूनियर डेवलपर को लेने और मेंटर करने की जरूरत है? [बन्द है]


25

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


12
जनादेश काम नहीं करता; वास्तव में वे अक्सर विपरीत प्रभाव डालते हैं। अल कैपोन सरकारी विधायिका द्वारा बनाया गया था। कुछ पूर्वी जर्मन जिन्हें 4 साल तक रूसी का अध्ययन करना था, ने खुद को उस भाषा में एक वाक्य कहने में सक्षम नहीं होने के लिए प्रेरित किया। एक ही बात हो सकती है यदि आप विकास के शिक्षण को जनादेश देते हैं या वरिष्ठ व्यक्ति कनिष्ठ का उल्लेख करते हैं।
जॉब

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

@ जॉब क्या आपको कभी आश्चर्य होता है कि एक देव अपने पूरे जीवन में एक ही बकवास कर सकता है [हानिरहित अतिशयोक्ति] अगर वह अपने कनिष्ठ को कनिष्ठ नहीं मानता है [सामान्य मतलब है] संकोच उसे भौतिकी में काम नहीं करने देता]?
चानी

जवाबों:


37

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


3
आप इसे कैसे प्रोत्साहित करते हैं? आप यह कैसे सुनिश्चित कर सकते हैं कि वरिष्ठों और जूनियर्स को पता है कि मेंटर / मेंटर होने के लिए काम का समय लेना ठीक है?
रिचार्ड

3
यदि आप एक जोड़ी-प्रोग्रामिंग मॉडल को प्रोत्साहित करते हैं, तो अक्सर इस तरह के संबंध बस बाहर हो जाते हैं यदि आप बस जूनियर्स और सीनियर्स को जोड़ी के लिए प्रोत्साहित करते हैं। इसके अलावा, पूरी टीम के माध्यम से दोस्ती को बढ़ावा; टीम-निर्माण अभ्यास, सैर और अन्य गैर-कार्य सहभागिता।
कीथ्स

यह दोस्ती को बढ़ावा देने के लिए एक अच्छा तरीका है जो स्वाभाविक रूप से सलाह देने के लिए नेतृत्व करना चाहिए।
ऋचा

मैं पूरी तरह से सहमत हूं, अपने सबसे अच्छे रूप में मेंटरशिप मेंटर को उतना ही वापस देता है जितना कि मेंटली को, इतना खुला, "आंख के स्तर" वार्तालाप एक शर्त है
आसफ

21

क्या यह संस्कृति का हिस्सा होना चाहिए कि वरिष्ठ डेवलपर्स को कनिष्ठ डेवलपर्स के साथ संरक्षक के रूप में जोड़ा जाता है?

हाँ।

जैविक और सहज, अर्थात आवश्यकता नहीं है, लेकिन कृत्रिम प्रोत्साहन के बिना विकसित करने की अनुमति दी गई है

यह वास्तव में किसी की मदद करने के लिए अक्सर पर्याप्त नहीं होगा।

संगठनों में मौजूदा संबंधों वाले लोगों को नए लोगों द्वारा प्रतिरूप या अभिजात वर्ग के रूप में माना जाएगा। क्लिक्स सामान्य रूप से टूटेंगे नहीं। हम उन लोगों से चिपके रहते हैं जिन्हें हम जानते हैं - यह मानव स्वभाव का एक अनिवार्य तत्व है।

30 से अधिक वर्षों के लिए एक सलाहकार के रूप में (100 ग्राहक संलग्नक) मैं यह दावा कर सकता हूं कि नए लोग हमेशा बाहरी होते हैं । यह "संस्कृति" या "वायुमंडल" की विशेषता नहीं है। यह एक जरूरी विशेषता है कि लोग कैसे काम करते हैं। सलाहकार अपने स्वयं के प्रतिरूप बनाते हैं क्योंकि स्थापित कर्मचारी उन्हें किसी भी चीज़ में शामिल नहीं करते हैं।

मेंटरिंग स्थापित करने का एकमात्र तरीका नए लोगों को क्लिक्स में सम्मिलित करना है।


@ डेविड थॉर्नले और एस.लॉट: क्या आपने अपने अनुभवों में जो देखा है उसे साझा कर सकते हैं? Annecdotes? मुझे यहाँ वास्तव में मिश्रित उत्तर मिल रहे हैं!
रिचार्ड

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

1
@ रिचर्ड डेलांडे: "मुझे वास्तव में मिश्रित उत्तर मिल रहे हैं"? आपने क्या उम्मीद किया? यह "समाजीकरण" के बारे में एक व्यक्तिपरक प्रश्न है। कोई सही उत्तर नहीं है। अगर वहाँ था, तो हम पहले से ही कर रहे थे।
S.Lott

यही कारण है कि है कि मैं क्या उम्मीद। लेकिन आप और डेविड अन्य जवाबों की तुलना में दूसरी तरफ से इस पर आ रहे हैं, इसलिए मैं चाहता था कि आप जवाबों को संतुलित करने के लिए थोड़ा और रास्ता निकालें। मुझे दोनों ओर से उतनी ही जानकारी चाहिए जितनी मुझे मिल सकती है। धन्यवाद! :-)
रिचार्ड

8

"संरक्षक" का पारंपरिक अर्थ कुछ हद तक असाइनमेंट को परिभाषित करता है। आप के रूप में अच्छी तरह से कोशिश करते हैं और दोस्तों को असाइन कर सकते हैं।

यह ठीक है, मेरे अनुभव में, पहले सप्ताह, महीने, इत्यादि के दौरान प्रश्नों के लिए अपने प्राथमिक संपर्क के रूप में एक स्थापित टीम के सदस्य का उपयोग करने के लिए एक नई टीम के सदस्य को सौंपना है।


1
फिर आप मेंटरिंग को कैसे प्रोत्साहित करेंगे? आप चाहते हैं कि जूनियर मानसिक रूप से असहज महसूस करें, और आप चाहते हैं कि सीनियर्स आरामदायक मेंटरिंग महसूस करें।
रिचार्ड

1
@ रिचर्ड: एक वरिष्ठ डेवलपर के रूप में उल्लेख करना एक प्राथमिक कार्य है। बूढ़े होने और दाढ़ी उगाने से आप वरिष्ठ नहीं बन जाते। यदि आप सलाह नहीं दे सकते, तो इस भूमिका में न आएं। "बस" एक डेवलपर हो।
back2dos

1
@ रीचर्ड आमतौर पर बातचीत कुछ इस तरह होती है: वरिष्ठ डेवलपर: "वे लोग भयानक इंटरफेस लिख रहे हैं! यह मेरे द्वारा पिछले साल तैयार की गई हर चीज को खराब कर रहा है।" Me: "आप जानते हैं, यदि आप चाहते हैं कि नए लोग क्लीनर इंटरफेस लिखना चाहें तो आप उनके साथ बैठकर अपनी सोच को समझा सकते हैं।"
क्रिस्टोफर Bibbs

7

क्या जूनियर डेवलपर्स के लिए वरिष्ठ डेवलपर्स की आवश्यकता होनी चाहिए?

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

या यह कुछ ऐसा होना चाहिए जो अधिक जैविक और सहज हो, अर्थात आवश्यकता न हो, लेकिन कृत्रिम प्रोत्साहन के बिना विकसित होने की अनुमति हो?

नहीं, उस के साथ सहमत नहीं है, या तो। मैंने बहुत सी स्थितियों को देखा है, जहां सलाह दी जाती है कि "जैविक और सहज" होने की उम्मीद है और यह बहुत कम ही होता है। मुझे लगता है कि संगठनों को सलाह देने का अवसर लेने की आवश्यकता है कि वे संक्रामक होने का मौका दें - लेकिन इसे मजबूर नहीं किया जा सकता है। यह कठिन है, लेकिन सार्थक है। मुझे लगता है कि संगठन इस तरह की चीजें कर सकता है:

  • संभावित संरक्षक और संभावित प्रोटेक्ट्स के बीच अनौपचारिक मुलाकात
  • संगठन द्वारा औपचारिक रूप से मान्यता प्राप्त करने के लिए सलाह देने के तरीके और अवसर (उदाहरण के लिए, यदि आप एक ऐसी जगह हैं, जिसमें वस्तुतः सब कुछ के लिए एक चार्ज नंबर है, तो मेंटर शिप मीटिंग के लिए एक चार्ज नंबर बनाएं - यह स्पष्ट करते हुए कि यह काम का एक व्यवहार्य हिस्सा है )
  • प्रशिक्षकों के लिए प्रशिक्षण और समर्थन
  • एक संरक्षक का चयन कैसे करें और क्या उम्मीद करें इसके लिए प्रोटीज का मार्गदर्शन
  • आकाओं को मार्गदर्शन कि क्या उम्मीद करें और क्या पेशकश करें
  • भागीदारी के लिए टेम्पलेट्स के साथ सलाह के लिए सुझाव (या लागू) पैटर्न - उदाहरण के लिए, यह एक शॉट देने के लिए बहुत आसान है अगर आप पहले से जानते हैं कि आपका लक्ष्य साप्ताहिक मीटिंग्स के साथ 3 महीने का अनुभव है और एक नए डेवलपर की मदद करने का लक्ष्य है और कंपनी में जा रहा है। यह कहने के लिए नहीं कि यह अधिक विकसित नहीं होगा ... लेकिन यह लोगों को शुरू करने के लिए एक जगह देता है।

5

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

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

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


4

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

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

मुझे लगता है कि आपको किसी समय मेंटर बनने की इच्छा है और दूसरों की सलाह पर।

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

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

मजबूर करने वाली सलाह शायद एक जाति व्यवस्था बनाएगी जो डेवलपर्स एक दूसरे को नाराज कर सकते हैं। प्रत्येक डेवलपर को समान स्तर पर समान रूप से व्यवहार करना बेहतर है।

यह उद्योग बहुत अलग है। सेनोरिटी हमेशा बेहतर नहीं होती है।

कभी-कभी वरिष्ठों को जूनियर्स द्वारा सलाह दी जाती है।


यह उत्तर +1 से अधिक योग्य है जो मैं इसे दे सकता हूं।
पीटर टेलर

3

मैं ऐसे वातावरण में रहा हूं जो दोनों तरह से काम करता है।

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

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

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

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

यह सब यह कहने का लंबा तरीका है कि जब तक मैं चाहता हूं कि आपको आकाओं को सौंपने की ज़रूरत नहीं है, यह शायद काम के चारों ओर फैलने का एकमात्र उचित तरीका है। यदि आप नहीं करते हैं, तो आपको उन लोगों को देना चाहिए जो इसे उनके कारण करते हैं। यह आसान काम नहीं है; इसके लिए पारस्परिक कौशल और इंजीनियरिंग कौशल दोनों की आवश्यकता होती है; और यह समय लेने वाली है।


3

वरिष्ठ डेवलपर्स को कोड से बाहर मंथन से परे जाने की उम्मीद की जानी चाहिए। हालांकि, वे जिस दिशा में जाते हैं, वह प्रत्येक वरिष्ठ डेवलपर के लिए समान नहीं होना चाहिए।

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

असल में, एक सीनियर को ऐसा कोई नहीं होना चाहिए जो जूनियर्स की तुलना में कुछ सालों से कोड काट रहा हो। यह ऐसा व्यक्ति होना चाहिए जो अतिरिक्त जिम्मेदारियों को लेने के लिए तैयार और सक्षम हो जो टीम की सफलता में योगदान दे। मंटोरिंग जूनियर्स महत्वपूर्ण है, लेकिन यह एकमात्र महत्वपूर्ण चीज नहीं है, और यह ऐसा कुछ नहीं है जो हर किसी के लिए अच्छी तरह से अनुकूल है।


3

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

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


3

टीम संरचना की अगुवाई करती है, जो कोड समीक्षाओं की ओर अग्रसर होना चाहिए ...

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


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

2

प्रोग्रामिंग की सभी चीजों में यह निर्भर करता है । लेकिन मैं निश्चित रूप से एक वरिष्ठ डेवलपर को काम पर रखने के लिए नए काम का जिक्र करते हुए एक नए डेवलपर की सलाह लेना चाहूंगा, चाहे वे कनिष्ठ हों या न हों।


2

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

कृत्रिम प्रोत्साहन हालांकि यहां बुरा विचार नहीं है। सभी कनिष्ठ और वरिष्ठ डेवलपर्स को बताएं कि वे मानसिक और संरक्षक होने जा रहे हैं, इससे कोई फर्क नहीं पड़ता कि थोड़ा धार्मिक और बहुत जल्दी हो सकता है।


अगर वहाँ एक रूपरेखा है कि कंपनी को पता होना चाहिए कि महान कैसे संभालना है। हालाँकि, अगर वह मौजूद नहीं है, तो चाबी मेंटर और मेंटी के बीच कुछ अलग तरह के पल होते हैं:

  1. वर्तमान स्थिति - अब चीजें कहां हैं? वर्तमान चुनौती क्या है कि संरक्षक हल करने में सहायता प्रदान कर सकता है?
  2. भविष्य की स्थिति - क्या चाहता है: एक संकेत, एक समाधान, पूछने के लिए प्रश्न, किसे पूछना है?
  3. पूर्वव्यापी - परिवर्तन करने में क्या काम किया और क्या नहीं किया?
  4. भविष्य के बदलाव - भविष्य में क्या कोशिश की जाएगी जो पहले की तुलना में बेहतर हो सकती है?

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

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


1
हाँ, मैं देख रहा हूँ। मुझे आश्चर्य है कि आप कैसे सलाह देते हैं और इसे करने के लिए भुगतान किए गए काम के समय को लेने के लिए उन्हें सहज बनाते हैं?
रिछार

2

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

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


2

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

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

इसके लिए कुछ संतुलित प्रबंधन की आवश्यकता होती है। मुझे यकीन नहीं है कि यह आम है।


2

काम करने के लिए किसी भी सलाह के लिए यह आवश्यक है कि प्रबंधन यह स्वीकार करे कि यह महत्वपूर्ण है और इसके लिए समय आवंटित करें, और सक्रिय रूप से इसे प्रोत्साहित करें!

असाइनमेंट के साथ बुक किए गए किसी भी व्यक्ति के लिए शाब्दिक रूप से सलाह देने या प्राप्त करने का कोई समय नहीं है, और ऐसा नहीं होगा।


1

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


0

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

इसने बहुत अच्छा काम किया लेकिन फिर, आपको यह काम करने के लिए अच्छे लोगों की आवश्यकता है।

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