क्या स्क्रैम वातावरण में वेग की एक बड़ी वृद्धि यथार्थवादी है?


89

मेरा प्रबंधक हाल ही में उत्पादकता के लक्ष्य और माप के रूप में वेग का उपयोग करने पर जोर दे रहा है। वर्तमान में हम 50 कहानी बिंदुओं के औसत वेग पर काम कर रहे हैं। मेरा प्रबंधक चाहता है कि हम इसे 40% से बढ़ाकर 70 कहानी अंक (टीम के सदस्यों में कोई वृद्धि नहीं) के साथ करें। यदि हम इस वृद्धि को प्राप्त नहीं करते हैं तो वह हमें यह समझाते हुए पूर्ण विराम देना चाहते हैं।

टीम के प्रदर्शन को वेग से मापने और लक्ष्य के रूप में उपयोग करने का पूरा विचार मुझे गलत लगता है, लेकिन मुझे यह समझाने में मुश्किल हो रही है कि क्यों। कोई मदद? उत्पादकता को मापने और प्रोत्साहित करने का यह सही तरीका क्यों नहीं है?


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

25
ऐसा लगता है कि यह एक अयोग्य अनुरोध है, कि मैं चाहूंगा कि आप उससे पूछें कि वह ऐसा क्यों सोचता है - यदि आप पहले से ही 100% दे रहे हैं, तो क्या वह आपसे 140% देने की उम्मीद करता है? क्या होगा यदि आप सिर्फ 40% लंबे स्प्रिंट बनाते हैं?
जोनाथन रिच

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

45
उसे वेतन में 40% वृद्धि के लिए कहें यदि आप उन लक्ष्यों को प्राप्त करते हैं, तो अपने अनुमानों को बढ़ाएं ताकि आपको 40% की वृद्धि प्राप्त हो।
मट्टनज

18
क्या ऐसा नहीं है कि मैराथन धावक को अचानक 2h के बजाय 1h25m में मैराथन दौड़ने के लिए कहें?
स्क्रूज 1

जवाबों:


158

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

यह देखते हुए कि ऐसा है, यह स्पष्ट होना चाहिए कि लक्ष्य के रूप में वेग का उपयोग करना गलत क्यों है, यह सिर्फ फुलाए गए अनुमानों को प्रोत्साहित करता है।

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

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


28
मैं दृढ़ता से मानता हूं कि कोई "त्वरित और गंदा" नहीं है। "गंदा" हमेशा मुझे धीमा कर देता है - यहां तक ​​कि अल्पावधि में भी।
Doc Brown

1
@Paul - मुझे लगा कि यह अच्छा है। लेकिन इसमें सलाह ज्यादातर केवल प्रबंधकों द्वारा दी जा सकती है, और जो लोग इससे लाभान्वित हो सकते हैं वे शायद इसे नहीं पढ़ेंगे। न ही इसे पढ़ने से व्यवहार में बदलाव आएगा।
psr

2
और यदि आप सहमत हैं और वास्तव में वेग में 40% की वृद्धि करते हैं, तो यह दूसरों की तरह दिखेगा कि आप और आपकी टीम आपके सर्वोत्तम काम नहीं कर रही थी। इसे संभालने का पेशेवर तरीका एक सीधा जवाब है: "नहीं, नहीं कर सकते।" इसके बारे में एक और पुस्तक संदर्भ: रॉबर्ट सी। मार्टिन द्वारा "द क्लीन कोडर"।
पाब्लोसैरिवा


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

53

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

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

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


7
+1: यह प्रबंधक का वर्णन करने का एक अच्छा तरीका है। आप कृत्रिम रूप से वेग को धक्का नहीं दे सकते हैं, लेकिन आप प्रत्येक स्प्रिंट के बाद वापस देख सकते हैं और सीख सकते हैं कि अगले स्प्रिंट के लिए आप अधिक कुशल क्या कर सकते हैं।
केविन

3
ऑड्स यह है कि प्रबंधक के ओवरहेड (मजबूर मीटिंग, फॉर्म भरने आदि) को हटाने से आपको शायद 5-10% आसानी से मिल जाएगा। लेकिन उसे कैसे मनाऊं?
एवीडी

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

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

1
आप उल्लेख करते हैं कि "5-10% एक शुरुआत है" के वेग में वृद्धि लेकिन यह प्रबंधक की गलतफहमी को साझा करने के लिए लगता है कि "बढ़ते वेग" का मतलब है कि मैंने उल्लिखित किया है।
रिकार्डो ग्लैडवेल

26

टी एल; डॉ

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

जब वेलोसिटी को मैनेजमेंट टारगेट के साथ भ्रमित किया जाता है

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

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

अपने राजनीतिक विकल्पों का मूल्यांकन करें

हमारे पास 50 कहानी बिंदुओं का औसत वेग है ... मुझे इसे 40% बढ़ाकर 70 कहानी अंक करने के लिए कहा गया है (टीम के सदस्यों में कोई वृद्धि नहीं)।

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

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

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

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

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

यदि अन्य सभी विफल हो जाते हैं, तो अपने रिज्यूमे को ब्रश करके, और प्रोजेक्ट के अंत होने तक अपने पेशेवर को सर्वश्रेष्ठ करने के लिए एक मृत्यु मार्च की तैयारी करें। 68% आईटी प्रोजेक्ट फेल ; जब तक प्रबंधन लक्ष्य ठोस रूप से संगठनात्मक क्षमता में नहीं आते हैं, तब तक शायद आप उनमें से एक होंगे।


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

1
@kriss गुणवत्ता, वास्तव में, त्रिकोण का हिस्सा हो सकती है। इसे कभी-कभी "स्कोप" का हिस्सा माना जाता है या कुछ त्रिकोणों में यह एक वास्तविक वर्टिस है जो यह संकेत देता है कि यह एक प्राथमिक बाधा है। देखें नीला त्रिकोण एक ठोस उदाहरण के रूप में PMBOK स्टार के भीतर, या परियोजना बाधा मॉडल का विकास इस मुद्दे पर कुछ जानकारी के लिए। कृपया इसे अधिक के लिए PMSE पर लाएं ।
कोडनेम

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

प्रश्न यहाँ पोस्ट किया गया। pmackexchange.com/questions/11489/…
क्राइस

21

मुझे यह समझ में नहीं आ रहा है कि आपके प्रबंधक की Scrum टीम में क्या भूमिका है? क्या वह कोच है? क्या वह उत्पाद स्वामी है?

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

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

एक बुनियादी नियम यह है कि उत्पाद स्वामी लक्ष्य निर्धारित करता है जबकि टीम यह निर्धारित करती है कि एक पुनरावृत्ति में क्या किया जा सकता है। ऐसा न करने से शास्त्रीय और प्रसिद्ध लोहे का चक्र होता है: संसाधन, वेग, सुविधाएँ। दो चुनें! आप उनमें से तीन को एक साथ नहीं चुन सकते हैं (और याद रखें: गुणवत्ता एक समायोजन चर नहीं है, कम गुणवत्ता के माध्यम से कोनों को काटने की कोशिश करना चीजों को और भी बदतर बना देगा)।

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

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

क्या आपके पास स्क्रम की बुनियादी समझ के साथ कुछ स्क्रम मास्टर या आसपास के कुछ अन्य लोग नहीं हैं जो उसे समझा सकते हैं?


15

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

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

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

हालांकि, अगर ग्राहक को वादा किया गया था, और किसी ने भी अब तक बात नहीं की है, तो यह एक कठिन लड़ाई होगी। यह दुर्भाग्य से एक असामान्य स्थिति नहीं है।


1
"ईमानदार और वफादार अनुमान" समस्या हो सकती है।
जेएफओ

@JeffO - हो सकता है, इसीलिए मैंने अनुमानों को सही ठहराने के लिए केस बनाने की सिफारिश की .. जब वे ऐसा करने की कोशिश करते हैं कि उन्हें या तो एहसास होगा कि उन्होंने अपने अनुमानों को बढ़ाया है या वे वास्तव में क्षमता नहीं रखते हैं
hanzolo

9

ऐसा लगता है कि आप दो मुद्दों का सामना करते हैं।

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

दूसरा मुद्दा यह है कि आपके खाते के आधार पर, आपके प्रबंधक ने उत्पादकता में 40% वृद्धि की उम्मीद की थी। यह आपके प्रश्न में इस अनुरोध के संदर्भ में नहीं कहा गया था। यदि आपकी टीम में सुधार की इच्छा हो तो यह एक अच्छा स्वभाव हो सकता है। या यह इतना सूक्ष्म संकेत नहीं हो सकता है कि आपके प्रबंधक का मानना ​​है कि आपकी टीम अंडर-परफॉर्म कर रही है।

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


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

4
+1 के लिए "डॉज से बाहर निकलें"। कभी-कभी यह एकमात्र तरीका है (हालांकि कम अक्सर बेहतर होता है)।
माइकल

9

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

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

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

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


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

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

@ नथानायफील्ड विशिष्ट? मुझे लगता है कि टीम व्यक्तिगत और लोगों की श्रेणी से बनी होगी। आलसी लोगों को व्यक्तिगत रूप से संबोधित किया जाना चाहिए न कि टीम को एक कंबल अनुरोध।
जेम्स खुरै

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

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

6

मेरा अनुभव यह है कि किसी टीम के वास्तविक वेग को बढ़ाने के लिए यह बहुत कठिन रहा है , यह देखते हुए कि न तो टीम, समस्या डोमेन या स्टैक परिवर्तन।

जहाँ मैं वृद्धि हासिल करने में सक्षम रहा हूँ, यह निम्न की बात है:

  • तकनीकी ऋण की सफाई; यह सुनिश्चित करना कि सब कुछ सही चल रहा है (जरूरी नहीं कि नवीनतम हो!) संस्करण, कि कोड अच्छी तरह से सच है, और यह कि सिस्टम में कोई अतिरेक नहीं है (डुप्लिकेट कोड, अप्रयुक्त कोड, आदि)

  • प्रथाओं में सुधार; जहाँ संभव हो बाँधना (हाँ, मैंने पाया है कि वेग बढ़ता है), रिफ्लेक्टर को आक्रामक रूप से समय ले रहा है (डिट्टो!), और गुंजाइश और फ़ोकस के बारे में निर्दयी होना

  • नौकरी के लिए सबसे अच्छा उपकरण ढूंढना और / या खरीदना (जैसे .NET के लिए ReSharper सोना, Airbrake और रूबी विकास के लिए स्पंक, आदि) में इसके वजन के लायक है

मैं यहां उन अन्य लोगों से सहमत हूं जो कहते हैं कि आपके प्रबंधक ने वेग में एक मनमानी वृद्धि के लिए कहा है। मैं एक उच्च प्राथमिकता के रूप में एक और नौकरी की तलाश करूंगा।


3

आपका प्रबंधक अतिरिक्त घंटे काम करने के लिए आपकी टीम से पूछ रहा है (या बता रहा है)। बाधाओं को दूर करते हुए और दक्षता हासिल करने से आपके वेग में कुछ हद तक सुधार हो सकता है, उस वृद्धि (40%) को प्राप्त करने का एकमात्र तरीका लंबे समय तक काम करना है, क्योंकि उस समय की अवधि में आपको अधिक इकाइयों में काम करने की आवश्यकता होती है।

चलो एक परिदृश्य लेते हैं।

दो सप्ताह के अंतराल में 10 दिनों के लिए कहने की अनुमति देता है। यूटोपिया एक दिन में 8 घंटे का होगा, जिसमें एक कहानी बिंदु को एक कार्य दिवस में सार किया जाएगा। तो, ऊपर से, आपका वेग 8 होगा। लेकिन, मज़बूती से लोगों को ईमेल, मीटिंग्स, बाथरूम ब्रेक आदि के साथ दिन में 6 अच्छे घंटे मिल रहे हैं, इसलिए अब आपका 6 प्रति डेवलपर है। इसलिए आपकी आधार रेखा ६ है। मान लीजिए कि आप चाहते हैं कि लोग ओवरटाइम काम करें, अब दिन में १० घंटे हैं। तो, प्रति डेवलपर 10 वेग बिंदु होंगे।

आपके वेग में हमेशा उतार-चढ़ाव होगा, शायद यह कम था क्योंकि आपको उस पुनरावृत्ति के दौरान बहुत सारे कीड़े से निपटना पड़ा था, शायद आवश्यकताएं गायब थीं, शायद कोई व्यक्ति कुछ दिनों के लिए बीमार हो गया था। शायद यह अधिक था क्योंकि काम को कम कर दिया गया था या आपकी टीम को अतिरिक्त घंटों में डाल दिया गया था।

लेकिन अगर आपके स्थिर ५० पर, वास्तव में stable० पाने के लिए अतिरिक्त घंटों की आवश्यकता होगी।


2

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

यदि आप इसे ठीक से मापते हैं, तो डेवलपर-प्रति घंटे सुविधा-बिंदुओं में अधिक घंटे काम करना वेग नहीं बढ़ाता। यह तभी काम करता है जब आप प्रति दिन अंक मापते हैं और फिर परिभाषित करते हैं कि मध्य-माप में "दिन" क्या है। यह केवल गति का भ्रम प्रदान करता है।

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

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


1

खैर, मैं थोड़ा हैरान हूं कि अन्य जवाब बॉस के अनुरोध को गंभीरता से लेते हैं। उत्पादकता में 40% वृद्धि की मांग करने वाला कोई व्यक्ति सॉफ्टवेयर विकास के बारे में पहली बात नहीं जानता है।

मुझे अभी भी इस विषय पर फिल फैक्टर पढ़ने में मजा आता है :

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

दोनों मार्ग समान रूप से प्रभावी लगते हैं। बाद की नस्ल से निपटना निश्चित रूप से निराशा और अविश्वास के कुछ क्षणों का कारण बन सकता है ... निराशा भी ... और इनमें से कुछ इन कहानियों में प्रलेखित है।

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

अंततः, यदि आप उन्हें प्रशिक्षित नहीं कर सकते, तो उन्हें पदोन्नत करें, या उनसे बचें, हो सकता है कि आप उन्हें कार्यस्थल की समृद्ध कॉमेडी के लिए उनके अनपेक्षित योगदान के लिए बस प्यार करना सीख सकें।

"दुखी और निराश" न बनने की सलाह आपको मिल सकती है। तकनीकी मामलों में तकनीकी रूप से अक्षम बॉस से न लड़ें। वह सिर्फ एक निजी हमले के रूप में देखेंगे।


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

0

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

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


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

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

-1

मेरे अनुभव और सीधे मुद्दे पर जाने के बारे में।

सबसे पहले, आप अनुमान को बढ़ा सकते हैं लेकिन इसका मतलब यह नहीं है कि आप अधिक कर रहे हैं।

दूसरा (आधार: बिना फुलाए, सिर्फ टीम वेग में केंद्रित),

अपनी टीम के अंदर कौशल खोजने की कोशिश करें। क्या वे सबसे अच्छा काम कर रहे हैं? क्या आपको आवेदन और जटिल चीजों के निर्माण के बारे में कठिन निर्णय लेने के लिए एक सिस्टम आर्किटेक्ट की आवश्यकता है? टीम अपने प्रयासों को कैसे खर्च कर रही है? वे अपनी समस्याओं के समाधान के लिए शोध करने, व्यापार करने, निर्णय लेने या क्या करने में समय बिता रहे हैं?

क्या वे सहज, केंद्रित और अनुमानित हैं? उनके लिए आगे क्या हो रहा है?

यह "मैं सीमाओं पर धकेल दिया गया" नहीं हूं ... यह पूरी टीम के लिए एक प्रश्न की तरह है "क्या हम सीमा पर हैं?" और "हम सीमाओं को कैसे धक्का दे सकते हैं?" ...

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

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

बिक्री ...

यदि उन कारणों की व्याख्या करें जो आप वेग नहीं बढ़ा सकते हैं तो कठिन है, ROI का उपयोग करें।

ग्राहक के लिए सबसे महत्वपूर्ण क्या है, इस पर ध्यान केंद्रित करें। सैद्धांतिक रूप से सबसे अधिक लाभदायक कार्य।

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

कार्यों का इतिहास, लाभ राजस्व (यदि उपलब्ध हो), कहानी बिंदु जो आपने उपयोग किया है, और दिखाएं कि उत्पादकता ISN'T टीम प्रभाव एक जटिलता द्वारा मूल्यांकन करने के लिए टीम द्वारा निर्धारित की गई गणना है और शायद कुछ पाने का समय है। किया हुआ

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