🧖 🧖 💯 बैकलॉग स्कोरिंग और प्राथमिकता तकनीक 🚶🏿 👑 💆🏼

खैर, आपकी अलगाव की योजनाएँ कैसी हैं? सर्दी की चीजें हटा दी गईं? क्या आपने प्रतिष्ठित फिल्में देखी हैं? क्या आपने धूल भरी किताबें पढ़ी हैं? और, हमेशा की तरह, उपयोगिताओं के लिए समय नहीं है। चलो, बहाना मत बनाओ - उन लोगों के लिए जो हमारे YouTube चैनल से वीडियो देखने के लिए एक घंटे नहीं बना सकते हैं , हमने एक पाचन लेख बनाया है। अंतरात्मा की आवाज है, 60 के बजाय सिर्फ 15 मिनट :)

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

परिस्थिति

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

पहला व्यक्तिवाद का एक उचित क्षण है: अक्सर प्राथमिकताएं व्यवसाय के मालिक के भटकने के तरीके को निर्धारित करती हैं। प्रधान को। लेकिन कभी-कभी मालिक दृढ़ता से "मतिभ्रम" कर सकते हैं और फ्रैंक बकवास कर सकते हैं, लेकिन सुनिश्चित करें कि सब कुछ ऐसा है।

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

अच्छी खबर यह है कि इस मामले में मदद करने वाली कुछ तकनीकें हैं:

प्राथमिकताओं पर सहमति - चुनें कि क्या अधिक महत्वपूर्ण है और क्या स्थगित किया जा सकता है;
बैकलॉग प्राथमिकता के लिए मानदंड स्थापित करें (किसी के मतिभ्रम की तुलना में थोड़ा व्यक्तिपरक, अफसोस के बिना ऐसा करना असंभव है)।

कार्य को प्राथमिकता देने के तरीके

बैकलॉग कैसा दिखता है?

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

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

कहानी मानचित्रण

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

चरण 1। हम एक क्रम बनाते हैं कि उपयोगकर्ता आपके उत्पाद का उपयोग कैसे करेंगे और वे क्या कदम उठाएंगे। एक सरल उदाहरण:

चरण 2. हम स्टिकर पर लिखते हैं कि इन प्रक्रियाओं में से प्रत्येक के लिए क्या विवरण उपलब्ध हैं - प्रत्येक चरण के लिए स्टिकर जितना कम लटका हुआ है, उतना कम प्राथमिकता।

परिणाम: कार्यों की पूरी सूची को उपयोगकर्ता के पथ के चरणों में विभाजित किया गया है, साथ ही प्रत्येक सुविधा में प्राथमिकताएं हैं (कम सुविधा शीट में लटकी हुई है, संपूर्ण उपयोगकर्ता पथ के संदर्भ में इसकी प्राथमिकता कम है)।

कहां और कैसे लागू करें

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

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

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

स्टोरी मैपिंग के पेशेवरों

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

विचारों के लिए मूल्य और प्रयास (या लीन प्राथमिकता)

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

चरण 1. पहले आप 2 तराजू लेते हैं:

— , « » . , — . , , , Value. , , .
,

, (estimate), . Story Point- ( ) -.

चरण 2. आप इन दो मापदंडों द्वारा सभी विशेषताओं का मूल्यांकन करते हैं: महत्व और श्रम इनपुट द्वारा। बाहरी प्रणालियाँ (जैसे हैगर या एयरफोकस प्रायोरिटीज़ और रोडमैप ) हैं जो आपको इस तरह के बोर्ड पर किसी तरह से अपनी सुविधाओं को स्वचालित रूप से बिखेरने की अनुमति देती हैं। इस मामले में अक्ष शून्य से नहीं आते हैं - वे आपके द्वारा प्राप्त आंकड़ों के अनुकूल हैं।

पहली बार में क्या सुविधाएँ लेनी हैं? सबसे महत्वपूर्ण और सबसे हल्का, जो कुल्हाड़ियों के सबसे करीब हैं - वे शीर्ष में और महत्व में दोनों पर्याप्त हैं:

यदि पहली जगह में हम सस्ते और अच्छे ले जाते हैं, तो बाद में - महंगा, लेकिन ठंडा:

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

कहां और कैसे आवेदन करें।

कस्टम विकास के साथ, इस तरह की चीज ग्राहक के साथ क्या करना है, अगर यह समझ में आता है:

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

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

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

मास्को

कई समूहों में सुविधाओं को वर्गीकृत करने का एक और तरीका MoSCoW विधि है। अंदर बहुत सरल पैरामीटर हैं:

एम - होना चाहिए : कार्यक्षमता जो आप बिल्कुल भी नहीं कर सकते। इसके बिना, आप रिलीज़ नहीं कर पाएंगे, आपका उत्पाद काम नहीं करेगा और इसकी बिल्कुल ज़रूरत नहीं होगी।

एस - होना चाहिए : कार्यक्षमता जो परियोजना में होनी चाहिए, लेकिन अन्य चीजें समान होने के नाते, आप किसी तरह इसके बिना कर सकते हैं।

सी - हो सकता है : कार्यक्षमता जारी करने के लिए वांछित।

डब्ल्यू - होगा : कम से कम व्यावहारिक कार्यक्षमता - तो कहने के लिए, "सब कुछ"।

, . Must Have , , , . Should Have — , , . Could Have — . , Must Have MVP.

अक्सर ऐसा होता है कि प्राथमिकताएं व्यवसाय से ऊपर से कम होती हैं, और वे कुछ "विशलिस्ट" पर केंद्रित होनी चाहिए, से हो सकती हैं, हो सकती हैं, होती हैं, प्रमुख चीजों (स्कोर) पर स्कोरिंग होती हैं। आमतौर पर हम इसका अवलोकन करते हैं, उदाहरण के लिए, ऑनलाइन स्टोर के डिज़ाइन या किसी प्रोजेक्ट के डिज़ाइन के विकास में, जहाँ दांव अंतिम होता है, लेकिन कम से कम वितरण भुगतान प्रणाली या कुछ और जो वास्तव में व्यवसाय के लिए लाभ उत्पन्न करता है। क्यों? क्योंकि मस्ट हैव के साथ काम करना दर्दनाक और डरावना है: आपको यह सोचने की ज़रूरत है कि यह कैसे मुद्रीकृत होगा, और कोई भी इसमें प्रवेश करना पसंद नहीं करता है, हालांकि यह गलत है।

कानो

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

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

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

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

एयरोफ्लोट में सवार बच्चों के लिए उपहार स्रोत हैं।

एक बार इस तरह के एक समारोह में भी औसत दर्जे का कार्यान्वयन होता है, संतुष्टि बढ़ती है। और स्टिपर कार्यान्वयन, उच्च संतुष्टि अनुसूची।

एक अन्य समूह महत्वहीन कार्य है। आप उन्हें कर सकते हैं, आप उन्हें नहीं कर सकते - हर कोई उदासीन होगा।

अंतिम समूह अवांछनीय विशेषताएं हैं। जब वे चले जाते हैं - सब कुछ ठीक होता है, जैसे ही वे दिखाई देते हैं - सब कुछ खराब हो जाता है। ऐसी एंटीफिची :)

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

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

उदाहरण

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

इसलिए, कानो पद्धति विपणन से बिल्कुल बाहर है, लेकिन दीर्घकालिक रणनीति के रूप में एक जगह है।

बग सूचियों को प्राथमिकता देने का क्लासिक तरीका

इसके दिल में 0 से 8:

0 की प्राथमिकताओं की एक सूची है - महत्वपूर्ण बग
जब परीक्षक पॉप अप हो जाता है और अब यह नहीं जांच सकता है कि सिस्टम क्रैश या कुछ टूटता है - सामान्य रूप से, जब यह आगे असंभव है।

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

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

3 - अनावश्यक प्रयोज्य

4 - पाठ

8 -विशलिस्ट / हम प्रबंधक के विवेक पर / नहीं करेंगे

हाँ, 4 और 8 के बीच के अंतराल को जानबूझकर बनाया गया था - प्रबंधक, यदि आवश्यक हो, तो वहां कुछ अन्य कार्यों को साबित कर सकता है।

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

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

यह विधि बैकलॉग को प्राथमिकता देने के लिए उपयुक्त नहीं है - उन्हें पूरी तरह से अलग मानदंडों की आवश्यकता है।

कार्यों का आकलन

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

लेकिन गंभीरता से, आमतौर पर तीन विकल्प होते हैं।

- « » , , . , , - -, - -. :)

( ). - , - . , . , , ( - ).
: , , , .

: ( + ( * 3) + ) / 6.

, .

, , . , , , : , — . . — .

, , , . - , , , «» — . — 1 , , .

, « », . , .
Planning Poker

«» , - , , . .

Planning Poker — , . Story Mapping, ( , — ).

Planning Poker
1. , ;
2. , — ( , «»).

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

ICE स्कोरिंग

संक्षिप्त नाम में तीन पैरामीटर हैं:

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

प्रभाव

एक विशेष सुविधा के प्रभाव का मूल्यांकन करने के लिए, यह कई मानदंडों पर विचार करने के लायक है:

यह रूपांतरणों में सुधार करता है,
वह नए उपयोगकर्ताओं को आकर्षित करती है
यह मौजूदा उपयोगकर्ताओं को रखता है
वह उत्पाद में मूल्य जोड़ती है।

यदि फ़ंक्शन उन्हें जवाब देता है, तो उत्पाद पर इसका उच्च प्रभाव पड़ता है। मूल्यांकन के लिए, आप 1 से 10 तक का पैमाना ले सकते हैं, आप 1 से 100 तक ले जा सकते हैं। उत्तरार्द्ध अधिक सुविधाजनक है, क्योंकि टेक-ऑफ रन है।

विश्वास

पर आधारित हो सकता है:

व्यक्तिगत राय, टीम की राय, बाहरी विशेषज्ञों की राय;
यूएक्स अनुसंधान;
चुनाव
साक्षात्कार;
प्रतियोगियों सहित टिप्पणियों;
एमवीपी
ए / बी परीक्षण;
तृतीय-पक्ष अनुसंधान;
एनालिटिक्स;
तकनीकी सहायता के लिए शीर्ष कॉल;
बिक्री प्रबंधकों से शीर्ष अनुरोध;
शीर्ष ग्राहक अनुरोध

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

विश्वास के स्तर को कैसे मापें - स्रोत

ICE प्राप्त करने के लिए, आपको इन तीन मापदंडों को गुणा करना होगा - यह कार्यान्वयन के लिए प्राथमिकता होगी।

पेशेवरों : त्वरित और आसान।

विपक्ष : विधि में एक सीमित पैमाने पर है - आप उच्च प्राथमिकता के बहुत सारे कार्य प्राप्त कर सकते हैं, क्योंकि उन पर बयान स्पष्ट होंगे, कार्य स्वयं सरल होंगे और महत्वपूर्ण प्रतीत होंगे।

RICE स्कोरिंग

4 मापदंडों का उपयोग यहां किया जाता है:

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

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

प्राथमिकता के लिए सॉफ्टवेयर

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

Hygger अंदर से कैसा दिखता है - स्रोत

किसी भी Google डॉक में एक ही काम करना है: बस तीन पैरामीटर जोड़ें, डेटा एकत्र करें - यह गिनती करेगा। ये आपकी प्राथमिकताएँ होंगी। और फिर आप खुद चुनते हैं कि स्प्रिंट में क्या लेना है।

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

जीरा के पास कार्यों को महाकाव्यों, घटकों, रिलीज़ में वर्गीकृत करने के कुछ तरीके हैं, और आप कुछ टैग के साथ कार्यों को चिह्नित कर सकते हैं। स्कोरिंग के लिए कई प्लगइन्स हैं ( जीरा के लिए अंक जारी करें ,)प्राथमिकता स्कोरिंग कैलकुलेटर ), लेकिन वे बहुत कार्यात्मक नहीं हैं।

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

प्राथमिकता के लिए मित्र जीरा और Google डॉक्स कैसे बनाएं प्राथमिकताओं

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

जीरा में, दुर्भाग्य से, "बॉक्स" से यह विकल्प बहुत अच्छी तरह से लागू नहीं हुआ है, इसलिए कई प्लगइन्स भी काम में आ सकते हैं:

नतीजतन

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

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

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

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

हमारे YouTube चैनल पर नए वीडियो में देखें !

बैकलॉग स्कोरिंग और प्राथमिकता तकनीक