Scrum और SAFe के संदर्भ में टीम के प्रत्येक सदस्य की व्यक्तिगत रेटिंग का उपयोग करने का अभ्यास

इस लेख में मैं यह बताने की योजना बना रहा हूँ कि अपने अभ्यास में हम फ्रेमवर्क के तहत काम करने की प्रक्रिया में Scrum में टीम के प्रत्येक सदस्य की व्यक्तिगत रेटिंग कैसे लागू करते हैं SAFe

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

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

मीट्रिक का वर्णन करने से पहले, मैं एक बहुत महत्वपूर्ण, मेरे विचार से, विचार का भी उल्लेख करना चाहूँगा। इस समय मैं इसमें पूरी तरह आश्वस्त हूँ।

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

तो, एक विशिष्ट मामले का उदाहरण। बेशक, हम User Stories को DOR (Definition Of Ready) से DOD (Definition Of Done) तक स्थितियों के अनुसार स्थानांतरित करने के लिए बोर्ड का उपयोग करते हैं। यह हमारे लिए वर्चुअल है (यानी इंटरनेट पर लिंक पर स्थित है। हमारी टीम भी वितरित है और स्टैंडअप कॉर्पोरेट स्काइप के माध्यम से बोर्ड के प्रसारण के साथ होते हैं।

टीम के सदस्य के लिए स्वयं को User Story के प्रतिभागियों में रखना सुविधाजनक है, ताकि स्वयं के फ़िल्टर का उपयोग करते समय केवल उन कहानियों को जल्दी से छोड़ा जा सके जिनमें वह इस समय भाग ले रहा है (अक्सर हम इस फ़िल्टर का उपयोग स्टैंडअप में करते हैं)।

यहाँ यह भी स्पष्ट करना चाहूँगा: इसका मतलब यह नहीं है कि यह टीम सदस्य अन्य कहानियों में भाग नहीं ले सकता (यदि, उदाहरण के लिए, स्टैंडअप में टीम के किसी सदस्य ने मदद माँगी, तो वह नई कहानी का प्रतिभागी बन सकता है या इसके विपरीत, यदि उसे लगे कि उसकी भागीदारी की आवश्यकता नहीं है, तो वह किसी कहानी का प्रतिभागी बनना बंद कर सकता है।

इस प्रकार, टीम के प्रत्येक सदस्य की रेटिंग की गणना करने के लिए, हमें यह देखना होगा कि प्रत्येक टीम सदस्य कितने SP को प्रभावित करता है। हमारे मामले में अर्काडी 29 SP को प्रभावित करता है (कहानियाँ 1, 2, 5, 6), तात्याना 33 SP को प्रभावित करती है (सभी कहानियों में भाग लेती है), वासिली 23 SP को (कहानियाँ 1, 3, 5, 6)।

अर्काडी के 29 SP में से 5 बंद (DOD पूर्ण) हैं, तात्याना के 32 SP में से 6, वासिली के 23 में से 5। सॉर्टिंग के साथ मैंने काफी समय संघर्ष किया और दो टीम सदस्यों की तुलना के लिए इस सूत्र पर पहुँचा (team[i] - एक टीम सदस्य और team[j] - दूसरा टीम सदस्य):

इस सॉर्टिंग के अनुसार हमें टीम सदस्यों की वर्तमान रेटिंग निम्नलिखित रूप में प्राप्त होगी।

• 1 स्थान। वासिली (23 में से 5 पूर्ण)
• 2 स्थान। अर्काडी (29 में से 5 पूर्ण)
• 3 स्थान। तात्याना (32 में से 6 पूर्ण)

अब स्प्रिंट के लिए सभी डेटा उत्पन्न करते हैं। मान लें कि स्प्रिंट 5 कार्य दिवसों तक चलता है।

• 1 दिन
  

  

  
  1 स्थान: वासिली (23 में से 0 जला)
  2 स्थान: अर्काडी (29 में से 0 जला)
  3 स्थान: तात्याना (32 में से 0 जला)
  
• 2 दिन
  

  

  
  1 स्थान: वासिली (23 में से 0 जला) गतिशीलता(1->1)
  2 स्थान: अर्काडी (29 में से 0 जला) गतिशीलता(2->2)
  3 स्थान: तात्याना (32 में से 0 जला) गतिशीलता(3->3)
  
• 3 दिन
  

  

  
  1 स्थान: वसीली (23 में से 5 जलाए गए) गतिशीलता(1->1->1)
  2 स्थान: अर्कादी (29 में से 5 जलाए गए) गतिशीलता(2->2->2)
  3 स्थान: तात्याना (32 में से 5 जलाए गए) गतिशीलता(3->3->3)
  
• 4 दिन
  

  

  
  1 स्थान: वसीली (23 में से 8 जलाए गए) गतिशीलता(1->1->1->1)
  2 स्थान: अर्कादी (29 में से 8 जलाए गए) गतिशीलता(2->2->2->2)
  3 स्थान: तात्याना (32 में से 9 जलाए गए) गतिशीलता(3->3->3->3)
  
• 5 दिन
  

  

  
  1 स्थान: वसीली (23 में से 23 जलाए गए) गतिशीलता(1->1->1->1->1)
  2 स्थान: तात्याना (32 में से 24 जलाए गए) गतिशीलता(3->3->3->3->2)
  3 स्थान: अर्कादी (29 में से 21 जलाए गए) गतिशीलता(2->2->2->2->3)
  

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

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

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

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

हम परिणाम के सही पूर्वानुमान पर ध्यान केंद्रित करते हैं, न कि 1 स्थान पाने के लिए ओवरटाइम करने की प्रेरणा पर। अंततः, यह मेट्रिक टीम के प्रत्येक सदस्य की अलग-अलग योजना बनाने की क्षमता में सुधार पर लक्षित है।