टीम के भीतर कम/उच्च कलाकारों को कैसे खोजें

हम 3 लोगों की टीम हैं। हम स्क्रम पद्धतियों का अनुकूलन कर रहे हैं।

सबकुछ कन्नबान (ट्रेलो) पर आधारित है जहां हम दैनिक, रेट्रोस्पेक्टिव्स और स्प्रिंट प्लानिंग (काम के घंटों से अनुमानित कार्यों का अनुमान लगाते हैं)।

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

1
जोड़ा संपादित
विचारों: 5
3 की इस टीम में आपकी भूमिका क्या है?
जोड़ा लेखक Lexible, स्रोत

7 उत्तर

उत्साह और खुले दिल के साथ इस जवाब को पढ़ें :)

मैं सवाल का जवाब दूंगा "कैसे सुनिश्चित करें कि डेवलपर्स धीमे डेवलपर्स को आवाज दें- या। आम तौर पर किसी भी मुद्दे- "धीमे डेवलपर्स का पता लगाने के तरीके" के बजाय "मुझे लगता है कि यह अंतर्निहित मुद्दा नहीं है।

संक्षेप में इसे पूरा करने का तरीका यह है:

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

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

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

I suggest you to have a look at one of my favourite books that expands a lot about working on safe environments and how to increase productivity: Creativity Inc.

6
जोड़ा

मैं धीमे व्यक्ति के बारे में अन्य उत्तरों के साथ यहां सहमत हूं। लेकिन अन्य व्यक्ति व्यक्ति तेजी से क्यों है?

मेरे पास एक बार मेरी स्क्रम टीम पर कोई था जो किसी और की तुलना में बहुत तेज़ था:

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

हाँ, वे एक भयानक टीम खिलाड़ी थे। हमें अंत में एहसास हुआ कि हम नहीं चाहते थे कि वे किस तरह की गति की पेशकश करें।

4
जोड़ा

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

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

दूसरा, परियोजना के अंत में एकमात्र गति जो वास्तव में मायने रखती है वह आपकी टीम की वेग है । आपका "धीमी डेवलपर" टीम की सहायता के लिए दृश्यों के पीछे काम कर रहा है और @OneDay के रूप में जब आपका "तेज़ डेवलपर" बताता है कि एक सिलो और होर्डिंग ज्ञान में बैठे हो सकते हैं। वे यूनिट परीक्षण छोड़ सकते हैं जो आपके "धीमे डेवलपर" ईमानदारी से कर रहे हैं।

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

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

एक स्क्रम टीम के सदस्य व्यक्तिगत प्रदर्शन के बारे में चिंता नहीं करते हैं, यह प्रबंधक का काम है और इसे 1: 1s में संभाला जाना चाहिए। एक स्क्रम मास्टर ऐसे कार्यों को देखता है जो जोखिम में हैं और टीम से पूछें कि उन्हें वापस पकड़ने के लिए क्या किया जा सकता है।

2
जोड़ा

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

यह भी दिलचस्प है कि ओपी केवल प्रदर्शन चरम सीमाओं को इंगित करता है: उच्च, निम्न।

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

मुझे लगता है कि आपकी टीम को रेटिंग करते समय तीन पहलुओं को समझने की आवश्यकता है: 1) उपयोग करने के मानदंड; 2) प्रदर्शन वितरण; और 3) विभिन्न शक्तियों और कमजोरियों की गतिशीलता, जो संचयी रूप से, एक उच्च प्रदर्शन टीम बनाते हैं।

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

2: What does the distribution of performance really look like on any team in any domain? Is it normally distributed? Skewed? Most current thinking is that performance is severely positively skewed, where most of your team are mediocre and very few are hyper performers. So perhaps in reality, assuming your criteria are sound, you are really only identifying the hyper performer who might simply stand out.

3) If you only look at your team in a single dimension, you could easily lose sight of other strengths that exist with an individual who may appear mediocre against your criteria, but whose value contributes to the overall team's performance. A slow performer--looking only at speed as a criterion--may offer a high degree of precision in his/her work that could be exploited from a teaming perspective to enable quality in the team's process. So grooming that type of person in that particular team role will enhance the overall team's performance, which is far more important than the individual's performance itself. And remember the concept of The Apollo Effect.

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

2
जोड़ा

परंपरागत रूप से, आपके पास देवलेड होगा, जो कम कलाकारों को ढूंढने के लिए ज़िम्मेदार है, यह देखकर स्वाभाविक रूप से यह कर रहा है कि कार्य कितनी जल्दी बंद हो गया है।

वैसे, कम प्रदर्शन एक समस्या है? यदि व्यक्ति दो बार धीमे काम करता है और दो गुना कम वेतन मिलता है, तो सबकुछ ठीक लगता है, है ना?

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

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

1
जोड़ा

टी एल; डॉ

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

सही चीजों को मापें

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

कुछ अन्य उत्तरों पर कई अन्य उत्तरों छूए हैं, लेकिन मैं यहां कुछ चीजें घर पर हथियार बनाना चाहता हूं।

  1. एक चुस्त परिप्रेक्ष्य से, टीम की प्रभावशीलता टीम पर व्यक्तिगत डेवलपर्स की सापेक्ष गति नहीं है, जो मायने रखती है।
  2. प्राथमिक मीट्रिक के रूप में कोडिंग गति मापना एक स्क्रम कार्यान्वयन गंध होने में 100% उपयोग की कमी के करीब है।
  3. आप जो भुगतान करते हैं वह आपको मिलता है, इसलिए यदि आपके प्रोजेक्ट को प्रभावित करने वाला वास्तव में महत्वपूर्ण कौशल अंतर है, तो आपको या तो अंतर को बंद करने के लिए अधिक प्रशिक्षण के लिए बजट की आवश्यकता है, उच्च प्रदर्शन करने वाले कर्मचारियों के लिए मजदूरी में अधिक बजट, या दोनों।

Agile in general, and Scrum in particular, are about measuring the ability of a team to deliver business value. A cross-functional team will often have people with varying skill sets, and different abilities and levels of expertise. A good agilist measures the effectiveness of the team as a whole in terms of its ability to deliver value, rather than contrasting members of the team against one another.

अपनी धारणाओं की जांच करें

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

  1. क्या हम सामूहिक रूप से समय पर और बजट पर हमारे परियोजना लक्ष्यों को पूरा कर रहे हैं?
  2. क्या टीम टिकाऊ गति से काम कर रही है?
  3. क्या टीम अत्यधिक तकनीकी ऋण के बिना व्यावसायिक मूल्य प्रदान कर रही है?
  4. क्या विकास दल अपने कामकाजी समझौतों और उनके साथी टीम के सदस्यों से संतुष्ट है?
  5. क्या कोई वास्तव में कोई मुद्दा उठा रहा है, या क्या आप बस एक समस्या मान रहे हैं?

If items 1-4 are "yes" and no one else is raising an issue, it seems likely that you're chasing a false economy of some sort. सही चीजों को मापें, ensure you have an effective process, and consistently elicit honest feedback from your team and your stakeholders.

1
जोड़ा

ऐसा लगता है कि आपने पहले ही 'धीमी' डेवलपर की पहचान की है। आपकी टीम के पास वर्जन कंट्रोल सिस्टम होना चाहिए और बैकलॉग सहित काम को ट्रैक करना चाहिए; दैनिक आधार पर तथ्य के बाद या डेटा पर पूर्ण सुविधाओं को देखकर आपकी अधिकांश चिंताएं संबोधित की जा सकती हैं।

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

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

आपको 9 महीनों में सबसे खराब से सर्वश्रेष्ठ पढ़ने और साझा करने से लाभ हो सकता है: माइक्रोसॉफ्ट के आईटी विभाग में ड्रम-बफर-रस्सी समाधान लागू करना अपनी टीम के साथ।

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

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

प्रत्येक स्प्रिंट पर स्वतंत्र रूप से लागू सुविधाओं की संख्या के सरल उपायों, शायद जटिलता के गुणों के साथ (उदाहरण के लिए, कहानी बिंदु), व्यक्ति द्वारा आपको गति दिखा सकती है। यह जानने के लिए संदर्भ लेता है कि समग्र परियोजना योजनाओं के लिए "धीमी" या स्वीकार्य है।

0
जोड़ा