खराब संचार कौशल वाले डेवलपर को कैसे प्रबंधित करें


52

मैं एक एप्लिकेशन पर डेवलपर्स की एक छोटी टीम का प्रबंधन करता हूं जो कि एक बड़े फर्म के भीतर, इसके जीवनचक्र के मध्य बिंदु में है। दुर्भाग्य से इसका मतलब यह है कि आमतौर पर "अन्य तकनीकी कार्यों" के लिए प्रोग्रामिंग कार्यों का 30/70 विभाजन होता है। इस कार्य में शामिल हैं:

  • विभिन्न कार्यों पर DBA / Unix / Network / Loadbalancer टीमों के साथ काम करना
  • विभिन्न क्षेत्रों में हार्डवेयर या बुनियादी ढांचे के लिए आदेश देना और प्रबंधित करना
  • चल रहे परीक्षण जो अभी तक सीआई में माइग्रेट नहीं हुए हैं
  • विश्लेषण
  • समर्थन / जांच

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

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

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

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

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


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

12
उन्होंने खराब संचार कौशल कैसे दिखाया है? अपने सांचे में नहीं ढलने से?
जेम्स

5
@ EvanPlaice फिर, "व्यक्तिगत समस्या" हमले के साथ क्या है? मैंने सवाल में कहा है "यह कहना उचित है कि डेवलपर्स सभी कोडिंग करना पसंद करेंगे"। शायद यह वाक्य पर्याप्त स्पष्ट नहीं था और संदेह का परिचय दिया, तो मुझे स्पष्ट करें - मैंने व्यक्तिगत रूप से देवताओं से बात की है, और उन्होंने मुझे बताया है कि वे अन्य कार्यों की तुलना में प्रोग्रामिंग कार्यों पर काम करने का आनंद लेते हैं। अगर ऐसा नहीं होता, तो मुझे ईमानदारी से यह सवाल पूछने की जरूरत नहीं होती।
djcredo

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

6
क्यों "खुद के लिए एक जगह बना रहा है" एक बुरी बात है? क्या आप सबसे अच्छा न्यूरोसर्जन चाहते हैं जो आप अपने मस्तिष्क के ट्यूमर को बाहर निकालने के लिए प्राप्त कर सकते हैं और सबसे अच्छा कार्डियोलॉजिस्ट आपको अपने बढ़े हुए महाधमनी को ठीक करने के लिए मिल सकता है, या क्या आप एक ही आदमी चाहते हैं जो दोनों क्षेत्रों में ठीक है लेकिन दोनों चीजों के लिए उत्कृष्ट नहीं है। आप?
गॉर्डन

जवाबों:


77

ऐसा लगता है कि आप अच्छी तरह से गोल व्यक्तियों पर बहुत अधिक प्रयास कर रहे हैं और एक अच्छी तरह से गोल टीम होने पर पर्याप्त प्रयास नहीं कर रहे हैं ।

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

आपने कहा:

... यह मेरे सिद्धांतों के खिलाफ जाता है, और इस विचार को बढ़ावा देता है कि आप उन कार्यों को बुरा नहीं मान सकते जो आप पसंद नहीं करते हैं।

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

एक प्रबंधक के रूप में, यह सुनिश्चित करना आपका काम नहीं है कि हर कोई "अच्छी तरह से गोल" हो। यह सुनिश्चित करना आपका काम है कि एस *** हो जाता है। और आप ऐसा नहीं कर रहे हैं। वास्तव में, आप ऐसे निर्णय ले रहे हैं जो चीजों को करने से रोक रहे हैं

आपको जो भी समस्या है, आपको उस पर काबू पाने की आवश्यकता है - आप अपनी टीम को कम उत्पादक बना रहे हैं।


22
इसलिए यदि लोन रेंजर प्रोग्रामर बस से टकरा जाए तो आप बेहतर तरीके से यह सुनिश्चित कर सकते हैं कि उसके संचार कौशल काफी अच्छे थे कि वह क्या कर रहा है और वह अपने प्रोजेक्ट में कहां है।
प्रोग्रामर

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

14
@ जैसनहॉलैंड, ऑप ने यह भी कहा, "अगर मैं उसे अधिक प्रोग्रामिंग काम देना जारी रखता हूं, तो मुझे पता है कि यह तेजी से किया जाएगा ..." यह बताता है कि उस व्यक्ति को प्रोग्रामिंग करने की आवश्यकता है। सेशन में उसके कंधे पर एक चिप होती है, और यही असली समस्या है।
रिवल

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

10
@ Stargazer712, "ऑप के पास अपने कंधे पर एक चिप है, और यही यहां वास्तविक समस्या है।" यह सच हो सकता है, लेकिन इसे "औसत" प्रोग्रामर के दृष्टिकोण से देखें, जो गैर-प्रोग्रामिंग कार्यों में रेलरोड किए जा रहे हैं, क्योंकि एक आदमी के पास "उपरोक्त-औसत" प्रोग्रामिंग कौशल है। मैं तर्क दूंगा कि यह प्रबंधक दूसरों के लिए व्यावसायिक विकास का अपना काम नहीं कर रहा है। शायद "ऊपर-औसत" अधिक कुशल है क्योंकि वह अधिक प्रोग्रामिंग करता है? हो सकता है कि अन्य "औसत" प्रोग्रामर "ऊपर-औसत" हो जाएं यदि अधिक प्रोग्रामिंग काम दिया जाए, तो भविष्य की परियोजनाएं और भी तेजी से हो जाएंगी।
प्रोग्रामर

39

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

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

अब आपने कहा कि क्रोधी देव के पास "औसत से ऊपर" कौशल है, लेकिन आपने यह नहीं कहा कि वह सबसे अच्छा था। इसका मतलब यह है कि शायद आपकी टीम के 1 / 3rd, जो अच्छे संचारक देव हैं, जो क्रोधी देव के कौशल स्तर या उससे ऊपर हैं, वे सभी परेशान महसूस कर रहे हैं।

क्या आपके बेस्ट परफ़ॉर्मिंग STAFF से कुछ उत्पादकता खोना उचित है क्योंकि वे क्रोधी-देवता से नाराज़ हैं? आपको तय करना पड़ेगा।

जब तक आप उस आदमी को आग नहीं देना चाहते, मेरा सुझाव है कि आप इनमें से एक तरीका अपनाएँ:

1) उसे एक बेहतर संचारक बनने के लिए प्रेरित करें। केवल यह बता सकता है कि क्या यह संभव है। हो सकता है कि आपको बस उसका हाथ पकड़ना थोड़ा और मददगार हो जाए। कुछ लोग केवल औपचारिक व्यावसायिक बातचीत से घबरा जाते हैं और इसे करने के लिए कहने पर नाराज हो जाते हैं।

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


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

3
@BillK, "हालांकि, टीम के एक सदस्य के पास संभवतः औसत-औसत कोडिंग कौशल है"। उन्होंने कहा कि वह 'सर्वश्रेष्ठ' नहीं थे। मैंने एक छुरा लिया और कहा कि वह अन्य देवों के 2 / 3rds से बेहतर है। देवों के 1 / 3rd को छोड़ देता है जो इस आदमी की तुलना में अच्छा या बेहतर होता है, जिसे अतिरिक्त काम करना पड़ता है जो उतना मजेदार नहीं है जितना उसे हर समय करने के लिए मिलता है ("सभी कोडिंग करना पसंद करते हैं")। यदि आपके किसी सहकर्मी ने कहा कि "मुझे यूनिट टेस्ट चलाना पसंद नहीं है, तो आपको मेरे लिए सभी खदानों को चलाना होगा" आप बहुत जल्दी नाराज हो जाते। इस लड़के का बुरा रवैया उसे एक इनाम (कम गैर-कोडिंग कार्यों) के लिए मिल रहा है।
ग्राहम

9

सबसे पहले, अपनी टीम के सदस्यों पर दोष लगाना ... खराब प्रबंधकीय कौशल को दर्शाता है।

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

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

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

शायद वह सिर्फ अपने डेस्क की स्थिति से नफरत करता है (क्या वह लैवेटर्स का सामना कर रहा है?) और यह उसे एक बुरे मूड में सेट करता है।

सुझाव: जवाब सुनो, जैसे वह एक भावुक इंसान है, मानव संसाधन नहीं।

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


9
-1: वह किसी पर आरोप नहीं लगा रहा है। उन्होंने पहचान लिया कि एक व्यक्ति संवाद करने में गरीब है, और परिणामस्वरूप वह कुछ और उबाऊ कामों को चकमा देने में कामयाब हो गया है जो अन्य को करना है। मुझे यकीन नहीं है कि आप कैसे निष्कर्ष निकालते हैं कि यह खराब प्रबंधन को दर्शाता है, या ओपी संवाद करने के लिए संघर्ष करता है ... यह कहा, मैं पूरी तरह से सहमत हूं कि प्रश्न में आदमी को बोलना किसी भी समाधान का हिस्सा बनना चाहिए।
cjmUK

1
@cjmUK यह उत्तरदाता जो इंगित कर रहा है वह यह है कि सभी सूचनाओं की कमी के कारण दृढ़ संकल्प करना कठिन है। एक उदाहरण के रूप में, मेरी पत्नी किसी ऐसे व्यक्ति के लिए काम करती थी जो सोचता था कि मेरी पत्नी भयानक है, अब मेरी पत्नी लोगों के साथ काम करती है और एक उच्च कलाकार मानी जाती है। तो क्या मेरी पत्नी समस्या है, या सहकर्मी समस्या थी?
पॉल

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

2
+1 "संकेत: उत्तर सुनो, जैसे वह एक भावुक मानव है, मानव संसाधन नहीं है।" अगर केवल और अधिक प्रबंधकों ने इस तरह से सोचा ... आह।
डेमॉन्गोलम

8

लोग अलग हैं। एक प्रबंधक के रूप में, आपको अपनी टीम से सबसे अधिक लाभ उठाने के लिए लोगों से अलग-अलग (लेकिन निष्पक्ष रूप से) व्यवहार करने की आवश्यकता है।

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

लोगों को काम से बाहर निकलने के लिए अक्सर बुरा नहीं होता है; वे इस पर बुरे हैं क्योंकि वे इसका आनंद नहीं लेते हैं या इसके लिए कोई योग्यता नहीं है। आप बाद की मदद नहीं कर सकते, इसलिए पूर्व पर काम करें।


6

30/70 विभाजन हो सकता है जहां आपकी सभी समस्याएं शुरू होती हैं। मैंने कभी भी डेवलपर्स को इस तरह विभाजन से खुश नहीं देखा है।

मैंने देखा है कि डेवलपर्स 10, 15% अन्य काम के साथ सहज हैं (और खुद खुश हैं क्योंकि यह खुराक के सही होने पर मज़ेदार है) लेकिन 30% बहुत अधिक है। मुझे लगता है कि अन्य टीम के सदस्य अपने मन की बात नहीं करना पसंद करते हैं, क्योंकि केवल वही है जो "30% अन्य कार्य" को नापसंद करता है।

मुझे यह भी लगता है कि आपके "उत्पादकता गणित" को अधिक यथार्थवादी आंकड़ों में समायोजित करना महत्वपूर्ण है। "संदर्भ स्विच" में अपरिहार्य नुकसान के कारण यह कभी भी 100% तक नहीं बढ़ेगा।

  • प्रोग्रामिंग और अन्य काम के बीच स्विच करने पर 30 + 70, 100% उत्पादकता तक , वास्तविक जीवन में कभी नहीं होगा; यह लगभग 20 + 50 या 20 + 40 की संभावना है। सॉफ़्टवेयर स्विच सॉफ़्टवेयर डेवलपर्स के लिए विशेष रूप से दर्दनाक हैं - यदि आप रुचि रखते हैं, तो इस लेख की एक अच्छी व्याख्या के लिए जांच करें कि यह क्यों है: क्या उत्तर नहीं है!
    प्रोग्रामर जो अपनी उत्पादकता को महत्व देते हैं वे स्वाभाविक रूप से उस तरह के नुकसान के बारे में नाखुश होंगे।

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

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

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

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


4

मेरे पास इस पर कहने के लिए 2 चीजें हैं

  1. क्या आपने एक कोडर या एक सॉफ्टवेयर डेवलपर की भर्ती की है ?
    जब आप एक सॉफ्टवेयर डेवलपर पर विचार कर रहे हैं तो आपके द्वारा बताई गई सभी चीजें सॉफ्टवेयर डेवलपमेंट का हिस्सा और पार्सल हैं। आप किसी भी तरह से इनको नजरअंदाज नहीं कर सकते जब तक कि आपने सिर्फ एक विशिष्ट कार्य के लिए भर्ती नहीं किया हो। कुल सॉफ्टवेयर विकास का 50% आईएमओ बाकी कोडिंग है जो सभी डिजाइन, विश्लेषण, परीक्षण, प्रलेखन आदि है।

  2. कोई भी सही जन्म नहीं लेता है।
    यह सिर्फ इतना नहीं हो सकता कि आप एक ऐसे व्यक्ति को पा सकें जो हर चीज में अच्छा है। आपको उन्हें संघर्ष करना होगा और उन्हें चीजों को सीखना होगा।

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


+1 - मैं दोनों बिंदुओं से सहमत हूं। एक डेवलपर को उचित रूप से अच्छी तरह गोल होना चाहिए। और उचित समर्थन और प्रोत्साहन के साथ, कोई कारण नहीं हो सकता है कि आदमी अपने खेल को खत्म नहीं कर सकता है।
cjmUK

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

@ ग्राहम जो संभवतः आपको कंपनी की संपत्ति बनाता है
शिरीष

4

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

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

संपादित करें: यदि आपके पास एक छोटी टीम है, तो संभवत: यह समझ में आता है कि सभी सदस्य कई टोपी पहनने में सक्षम हैं। यदि आपके पास एक टीम है जो काफी बड़ी है, तो यह संभवतः उन समूहों के लिए समझ में आता है जो विभिन्न क्षेत्रों में विशेषज्ञ हैं। आपकी पोस्ट से ऐसा लगता है कि आपके पास विशेषज्ञों के समूह के लिए पर्याप्त बड़ी टीम नहीं है।


4

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

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

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

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

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


2

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

क्या आप अपने सर्वश्रेष्ठ डेवलपर को खोने और / या जोखिम को कम करने से डरते नहीं हैं? आपका काम सभी से इस प्रकार के कर्तव्यों को दूर करना और राहत देना है।

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

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

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


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

1
@cjmUK - और किसी ने नहीं कहा कि टीम के अन्य सदस्यों को इससे कोई समस्या थी। देखें संपादित करें 2.
जेएफओ

2
@ जेफ ओ "यह कहना उचित है कि डेवलपर्स सभी कोडिंग करना पसंद करेंगे"। क्षमा करें, लेकिन यदि अन्य देवों को अब प्रश्न में लड़के के साथ कोई समस्या नहीं है, तो वे अंततः करेंगे। djcredo को इस मार्ग पर जाने से पहले इसे नियंत्रण में लाने की कोशिश में सक्रिय किया जा रहा है।
ग्राहम

2

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

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

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

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

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

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

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


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

ये केवल सारांश विचार हैं, उम्मीद है कि कोई व्यक्ति इन बिंदुओं को चुराएगा और उन्हें अन्य उत्तरों में से एक में बदल देगा। ;-)


0

प्रदर्शन ही सबकुछ है। उसे प्रोग्रामिंग टास्क दें। बाकी विभाग के साथ इस पर बात करते हैं। वैकल्पिक रूप से कॉम कार्य करने के लिए किसी को लाएं या किसी व्यक्ति को केवल कॉम कार्यों पर कार्य करें। मजेदार होने की प्रोग्रामिंग के बारे में मत सोचो। सब कुछ अपने POV से "मज़ा" है।

यदि आप नहीं करते हैं तो आप एक ऐसी स्थिति बनाएंगे जो प्रबंधन करने में बेहद कठिन हो और इससे कम प्रभावी हो।


0

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

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

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

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

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

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

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

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

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


0

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

देखने के लिए एक और बात: प्रश्न में व्यक्ति को कुछ भी नहीं देने पर प्रोग्रामिंग कार्यों से अलगाव को बढ़ावा मिलेगा। सुनिश्चित करें कि आप उन्हें कुछ अन्य कार्य देते रहें (लेकिन वे जो अच्छा कर सकते हैं, उन्हें नकारात्मक प्रतिक्रिया के लिए सेट न करें)) इसलिए वे दोनों अन्य विभागों / टीमों के साथ दृश्यता रखते हैं और दृश्यता रखते हैं।

अंत में ... टीम के अन्य सदस्यों के साथ जांच करें कि क्या उन्हें समय-समय पर टीम के असाइनमेंट में कोई असमानता दिखाई देती है । यह आपके लिए एक बड़ी चिंता का विषय हो सकता है, लेकिन हर किसी की सूची में # 15।


1
वह दुर्भाग्य से, जाहिरा तौर पर औसत संचार कौशल से कम है।
मैथ्यू एम।

-1

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

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


2
"हालांकि, टीम के एक सदस्य के पास संभवतः औसत-औसत कोडिंग कौशल है"। वह सबसे अच्छा नहीं है। वह औसत से ऊपर है। लगभग 1 / 3rd टीम हो सकती है जो कोडिंग में बेहतर हो।
ग्राहम

-1

उत्तर देने वाले कुछ लोगों की तरह, मैं आपकी स्थिति को समझता हूं, और मेरी भी ऐसी ही महत्वाकांक्षाएं होंगी।

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

यदि इस आदमी को अपनी भूमिका में गैर-कोडिंग तत्वों को करने की आवश्यकता है, लेकिन उसके संचार कौशल वास्तव में जरूरत से ज्यादा गरीब हैं, तो उसे सुधारने की आवश्यकता है। इस धारणा पर कि आपके पास किसी प्रकार की विकास समीक्षा / मूल्यांकन प्रणाली है, यह मुद्दा उठाने का समय है।

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

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

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


-1

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

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


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

-2

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

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

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

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

एक फिल्म है, एडम , जिसमें जीनल प्रोग्रामर को सिर्फ इसलिए निकाल दिया जाता है क्योंकि उसने कुछ ऐसा लिखा है जिसकी उसे उम्मीद नहीं थी। उनका विचार नियोक्ता के लिए बहुत पैसा ला सकता है, लेकिन वह इस अवसर का उपयोग नहीं कर सका क्योंकि वह अपने "सिद्धांतों" पर केंद्रित था।


1
बस स्पष्ट होने के लिए - यहां किसी को भी नहीं हटाया जा रहा है। हम सभी वास्तव में एक साथ मिलकर काम करते हैं, और वह देव टीम का एक अत्यंत मूल्यवान सदस्य है। मैं भविष्य के काम को कैसे सौंपा जाए, और समग्र रूप से टीम के प्रदर्शन और मनोबल को कैसे बेहतर बनाया जाए, इसके बारे में बात कर रहा हूं।
djcredo
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.