टीम पर कोड चरवाहा


15

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

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


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

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

7
आराम करें और प्रतीक्षा करें 'तिल' वे बाहर जला।
स्टीवन एवर्स

9
ऐसा लगता है कि आप सोमवार की सुबह में और अधिक समय पर योजना बना सकते हैं।
जेएफओ

3
आपने हमें जो नहीं बताया वह उसके कोड की गुणवत्ता है। क्या वह अन्य लोगों को उसी, अधिक या कम गुणवत्ता के समाधान के साथ पहले से ही देख रहा है?
डेविड थॉर्नले

जवाबों:


17

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

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

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


17

यह मानते हुए कि वह वास्तव में कुशल है, और "सभी ट्रेडों का जैक" ...

उसकी शैली को गले लगाओ। उसे अनचेक करें । और - उसे अलग करो।

इसके अलावा ...

जिम्मेदारियों के साथ आप स्पष्ट रहें।
सुनिश्चित करें कि आपकी टीम उससे सीखती है (जैसे जोड़ी प्रोग्रामिंग उत्कृष्ट काम करती है)।
"ऑल-इन" मत जाओ - उसका परीक्षण करें और यदि चीजें खराब हो जाती हैं तो बैकअप योजना सुनिश्चित करें।

सबसे बुरी बात यह है कि आप उसकी प्रेरणा को खराब कर सकते हैं।


यह मैं अपने अनुभव से कह रहा हूं। मैं उतना कुशल नहीं हो सकता जितना मैं चाहूंगा, लेकिन मैं निश्चित रूप से UI से सभी तरह से दृढ़ता के लिए जा सकता हूं और मैं निश्चित रूप से काउबॉय कोडिंग का अभ्यास कर रहा हूं (जो निश्चित रूप से दोधारी तलवार है)।

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

वास्तव में - यह स्वतंत्रता केवल एक चीज की तरह है कि मैं अभी भी यहीं काम कर रहा हूं।


9

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

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

समाधान (IMHO): उसका सीधा सामना करें। बेशक, उनके द्वारा किए गए योगदान और बलिदान की कूटनीतिक और सराहना हो (80 घंटे एक परे-पागल काम का सप्ताह है, और संभवतः उनके व्यक्तिगत जीवन में एक बहुत अपमानजनक बलिदान के बिना नहीं हो सकता)।

लेकिन यह उसकी ज़िम्मेदारी है कि वह अपने सहकर्मियों - कनिष्ठों, या अन्यथा को अलग न करे। और टीम के सभी लोग यह महसूस करने के हकदार हैं कि वे प्रयास सार्थक हैं - आखिरकार, कोई भी रोज़मर्रा के काम पर क्यों जाना चाहेगा यदि उनकी उपस्थिति अर्थहीन थी?


आप एसओ / एसई पर ओपी के प्रोफाइल को देखने के बाद जानते हैं। मैं सिक्के के दूसरे हिस्से को देखने के लिए तैयार हूं। यदि यह जानबूझकर या अनजाने में ऐसा कर रहा था। यह निश्चित रूप से टिम द्वारा उल्लिखित कारणों के लिए बुरा है। इसके अलावा जूनियर्स को बढ़ने / विकसित न होने देने के मूल बिंदु के कारण। जब जूनियर आपकी जगह लेने के लिए बेहतर बन जाते हैं तो आपकी उपस्थिति के बिना भी शो चल सकता है। तो +1
आदित्य पी

9

उसे और अधिक काम देने पर विचार करें , ताकि उसे आपकी तलाश न करनी पड़े!


6

क्या यह संभव है कि वह "अंदर कूद और खत्म हो रही है" क्योंकि बाकी टीम बहुत धीरे-धीरे आगे बढ़ रही है, या क्योंकि बॉस ने उससे पूछा है?

इसमें से कितना बाईपास होने के साथ झुंझलाहट है, और यह कितना अधिक सरल (जरूरी नहीं कि बेहतर) कोडर द्वारा "दिखाया" जा रहा है?


4

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

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


7
कोई भी जो वरीयता के आधार पर प्रोग्रामिंग में 80 घंटे का सप्ताह काम करता है, सामाजिक कौशल पर थोड़ा कम होने की संभावना है।
डेविड थॉर्नले

4

आप एक टीम के सदस्य के साथ कैसे व्यवहार करते हैं जो आपसे वरिष्ठ है और हमेशा अन्य लोगों की परियोजनाओं पर कूदता है और उन्हें रात या सप्ताहांत में पूरा करता है?

तेजी से काम करें?

वह 80 घंटे के सप्ताह में काम करने लगती है कि क्या कोई आपात स्थिति है या नहीं और यह भविष्यवाणी करना थोड़ा मुश्किल है कि आपकी टूडू सूची के किस हिस्से में वह आगे जा रही है।

परिभाषा के अनुसार, यदि यह आपकी टूडू सूची में है - ऐसा नहीं किया गया है। यदि वह इसे पूरा करती है, तो इसे अपनी टूडू सूची से पार कर लें।

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

जिसे आम तौर पर टीमवर्क कहा जाता है - जब तक कि आपको वह दिशा पसंद नहीं आती, तो क्या समस्या है?

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

"स्वामित्व" और कोड एक साथ नहीं चलते हैं। यदि आपको रखने में परेशानी हो रही है, तो उसे इसे आपको समझाने के लिए कहें। उसे सलाह देने के लिए कहें, क्योंकि ऐसा लगता है कि वह काफी उत्पादक है। रिश्ते का लाभ उठाएं, और एक साथ काम करें।

परीक्षण कवरेज के लिए, यदि यह आपके ओआरजी में एक मानक है - तो इसे अपने लीड / मैनेजर पर लाएं। त्वरित, लेकिन घटिया, काम किसी के लिए कोई फायदा नहीं है। यद्यपि, यदि वह आपसे 10 गुना अधिक उत्पादक है - तो आप उसके बाद सफाई का गंभीर काम कर सकते हैं। अगर ऐसा है, तो उसके साथ रिश्ते में और भी अधिक निवेश करें।


वह आदर्श टीम के सदस्य की तरह लगता है ... वह स्पष्ट कर रही है कि उसने क्या काम किया है / समाप्त हो गया है, वह टीम के हर सदस्य आदि की मदद कर रही है ..
Augury

3
  • उससे सीखें और अपने काम करने की गति को बेहतर बनाने का प्रयास करें।
  • ऐसी संभावना हो सकती है कि आपका काम पिछड़ रहा है।
  • हो सकता है कि सीनियर के आधार पर वह सीन के पीछे या आपके ज्ञान के ऊपर से चल रहा हो, क्योंकि वह सीनियर है।
  • आप सोच सकते हैं कि उसके पास ऐसा करने के लिए बेहतर कोई चीज नहीं हो सकती है, अक्सर यह संभावना नहीं है।
  • आप आपातकाल के बारे में नहीं जानते होंगे।
  • यह प्रबंधन या वरिष्ठ द्वारा आपके प्रदर्शन के लिए संकेत हो सकता है।

किसी भी तरह से इसका सर्वश्रेष्ठ आप पहले खुद का मूल्यांकन करना शुरू करते हैं। उसके साथ "डील" करने के आपके प्रयास प्रबंधन के साथ अच्छा काम नहीं कर सकते हैं।


3

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

प्रमुख चीजें मुझ पर कूदती हैं:

  • वह दूसरों की तुलना में तेजी से काम करने की प्रतिभा रखती है (आपने उसके कोड खराब होने के बारे में कुछ भी नहीं कहा है)

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

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


1
यदि आप DeMarco पुस्तकों को पढ़ते हैं, तो आप देखेंगे कि उस राशि के बीच लगभग 10: 1 का अनुपात है, जो कि अच्छे और इतने अच्छे डेवलपर्स का उत्पादन कर सकते हैं। आखिरी चीज जो आप करना चाहते हैं, वह उस अवगुण को टटोलना है जो दूसरों की तुलना में अधिक हो जाता है, आपको उस ऊर्जा का दोहन करने और इसे निर्देशित करने की आवश्यकता है जहां यह सबसे अच्छा करेगा।
जल्दी_नहीं

2

जोड़ी-प्रोग्रामिंग करने वाली टीम शुरू करें।

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

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

तीसरा, वह वर्तमान में आपकी ओर से किए जा रहे भारी जोखिम को कम कर देगी, ताकि टीम के एक से अधिक सदस्य को पता हो कि वह क्या जानती है।

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

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

छठी, कोड की गुणवत्ता आमतौर पर देव जोड़ी के ऊपर जाती है। एक अच्छा दुष्प्रभाव।


1

क्या वह जानती है कि लोग क्या काम कर रहे हैं और उनकी प्रगति क्या है? क्या प्रबंधन उसे दिशा प्रदान कर सकता है ताकि वह अन्य लोगों से काम की नकल न करे? मुझे सुझाव है कि प्रबंधन में लाने से पहले 1: 1 बातचीत करने के लिए प्रलोभन दिया जाएगा क्योंकि शायद वह सिर्फ एक वर्कहॉलिक है जो यह जानने की दिशा का उपयोग कर सकता है कि क्या चीजें महत्वपूर्ण हो सकती हैं जो अन्य नहीं कर रही हैं जो उसके लिए काफी उपयोगी हो सकती हैं। कर।

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


0

चरवाहा उत्साही लगता है। मैं प्रबंधन से संपर्क करूंगा ताकि वे उसे एक टन का काम दे सकें और आप लोग अपना सामान खुद कर सकें। हालाँकि, हो सकता है कि आप चरवाहे से एक या दो चीजें सीख सकें। मैं यह नहीं कह रहा हूं कि 80 घंटे का कार्य सप्ताह आदर्श होना चाहिए (जाहिर है यह एक अतिशयोक्ति है), लेकिन काम पर अतिरिक्त घंटे लगाना एक बड़े कॉर्पोरेट वातावरण में बहुत सामान्य है।


5
लंबे समय तक प्रोग्रामिंग घंटों में लगाना आमतौर पर लंबे समय में उल्टा होता है।
डेविड थॉर्नले

@ डेविड: अगर आपको हर दूसरे शुक्रवार को छुट्टी नहीं दी जाती है :)
ब्रायन

2
@ 0A0D: यह फ्लेक्सिटाइम है, "काम पर अतिरिक्त घंटे लगाने के लिए नहीं"
Carson63000

3
@OAOD: कोई भी दुकान जिसमें लोग बिना किसी नियमित समयोपरि के काम करते हैं, पसीने की दुकान है।
बिट-ट्विडलर

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