feature-prioritisation

# machine-translated to hi from skills/feature-prioritisation/SKILL.md — review: pending. Native fixes welcome via PR.name: feature-prioritisationdescription: "फ़ीचर और बैकलॉग आइटम को रैंक करने के लिए प्राथमिकता ढाँचे (RICE, MoSCoW, Kano, ICE, Opportunity Scoring) लागू करें। जब कोई फ़ीचर को प्राथमिकता देने, बैकलॉग रैंक करने, आगे क्या बनाना है यह तय करने या प्रतिस्पर्धी विचारों के बीच समझौतों का मूल्यांकन करने को कहे, तब इसका उपयोग करें। ढाँचा-विशिष्ट तालिकाओं, अनुशंसित निर्माण क्रम, हटाए गए आइटम और की गई धारणाओं के साथ एक स्कोर की गई, रैंक की गई फ़ीचर सूची तैयार करता है।"

फ़ीचर प्राथमिकता स्किल

किसी भी बैकलॉग पर सही प्राथमिकता ढाँचा लागू करें और तर्क के साथ एक स्पष्ट, तर्कसंगत रैंकिंग तैयार करें — सिर्फ़ क्रमबद्ध सूची नहीं।

आवश्यक इनपुट

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

• प्राथमिकता देने योग्य फ़ीचर या पहलों की सूची
• जिसके सापेक्ष प्राथमिकता दी जा रही है वह लक्ष्य या मेट्रिक (OKR, लॉन्च, स्प्रिंट)
• पसंदीदा ढाँचा (या नीचे के संदर्भ के आधार पर सिफ़ारिश करें)
• टीम डेटा: पहुँच अनुमान, प्रयास अनुमान, वेलोसिटी (RICE के लिए)

ढाँचा चयन गाइड

उपयोगकर्ता से पूछें कि वे कौन सा ढाँचा पसंद करते हैं, या संदर्भ के आधार पर सिफ़ारिश करें:

---

RICE स्कोरिंग

सूत्र: (Reach × Impact × Confidence) ÷ Effort

आउटपुट तालिका:

---

MoSCoW विधि

हर फ़ीचर को इस रूप में वर्गीकृत करें:

• Must Have — लॉन्च/स्प्रिंट के लिए अनिवार्य; इसके बिना प्रोडक्ट विफल
• Should Have — महत्वपूर्ण पर गंभीर नहीं; जुगाड़ मौजूद हैं
• Could Have — हो तो अच्छा; सिर्फ़ समय मिले तो शामिल करें
• Won't Have (इस बार) — अभी स्पष्ट रूप से दायरे से बाहर; बाद में फिर देख सकते हैं

हमेशा पूछें: "किसके लिए must have?" — वर्गीकरण से पहले दायरा (लॉन्च, स्प्रिंट, तिमाही) तय करें।

---

ICE स्कोरिंग (स्टार्टअप/तेज़ मोड)

सूत्र: Impact + Confidence + Ease (हर एक 1–10)

त्वरित, व्यक्तिपरक — डेटा आने से पहले शुरुआती निर्णयों के लिए अच्छा।

---

Kano मॉडल

फ़ीचर को इनमें वर्गीकृत करें:

• Basic (Must-be): अपेक्षित; अनुपस्थिति असंतोष पैदा करती है
• Performance: जितना ज़्यादा उतनी बेहतर संतुष्टि; रैखिक संबंध
• Excitement (Delighters): अप्रत्याशित; प्रसन्नता पैदा करता है; अनुपस्थिति तटस्थ
• Indifferent: उपयोगकर्ताओं को किसी भी तरह परवाह नहीं
• Reverse: कुछ उपयोगकर्ता चाहते हैं, कुछ नहीं

निर्माण की सिफ़ारिश: पहले सभी Basic फ़ीचर → मुख्य उपयोग-मामलों के लिए Performance फ़ीचर → प्रति रिलीज़ 1–2 Excitement फ़ीचर।

---

प्रोग्रामेटिक हेल्पर

यह स्किल एक stdlib-only Python स्क्रिप्ट के साथ आती है जो गणित-आधारित ढाँचों (RICE, ICE) की रैंकिंग निकालती है ताकि फ़ीचर स्कोरिंग सत्रों के बीच सुसंगत रहे।

# RICE from JSON
python3 scripts/feature_prioritisation.py initiatives.json --framework rice

# RICE from CSV
python3 scripts/feature_prioritisation.py initiatives.csv --framework rice --format csv

# ICE from JSON
python3 scripts/feature_prioritisation.py features.json --framework ice

# Pipe into it
printf '%s\n' '[{"name":"API refactor","impact":8,"confidence":80,"ease":5}]' \
  | python3 scripts/feature_prioritisation.py --framework ice -

आगे के टूलिंग के लिए मशीन-पठनीय आउटपुट हेतु --json उपयोग करें।

---

आउटपुट फ़ॉर्मैट

फ़ीचर प्राथमिकता — [प्रोडक्ट/टीम] — [तारीख़]

उपयोग किया गया ढाँचा: [RICE / MoSCoW / ICE / Kano / कस्टम] दायरा: [स्प्रिंट / तिमाही / रिलीज़] जिस लक्ष्य के सापेक्ष प्राथमिकता दी गई: [मेट्रिक या उद्देश्य]

[चुने गए ढाँचे की स्कोर तालिका]

अनुशंसित निर्माण क्रम:

1. [फ़ीचर] — [1-पंक्ति का तर्क]
2. [फ़ीचर] — [1-पंक्ति का तर्क]
3. ...

स्पष्ट रूप से हटाए गए:

• [फ़ीचर] — कारण: [संक्षिप्त]

की गई धारणाएँ:

• [स्कोरिंग में प्रयुक्त कोई भी अनुमान या निर्णय]

---

दिशानिर्देश

• प्राथमिकता को हमेशा किसी विशिष्ट लक्ष्य या मेट्रिक से जोड़ें — शून्य में कभी प्राथमिकता न दें
• जब दो फ़ीचर के स्कोर मिलते-जुलते हों पर जोखिम प्रोफ़ाइल बहुत अलग हों, तो चिह्नित करें
• अगर हितधारक राजनीति प्राथमिकता को प्रभावित कर रही है, तो इसे स्पष्ट रूप से नाम दें और ढाँचे के स्कोर को अंतिम निर्णय से अलग रखने का सुझाव दें
• कम से कम हर 2 सप्ताह में प्राथमिकताओं पर फिर से विचार की सिफ़ारिश करें
• बिना तर्क के एक-कॉलम वाली रैंक सूची कभी न दें — शीर्ष 3 और निचले 3 निर्णय समझाएँ

गहरी सामग्री

यह स्किल सहायक फ़ाइलों के साथ आती है — उपलब्ध हों तो उनका उपयोग करें:

• references/framework-selection.md — प्राथमिकता ढाँचा चुनना (RICE को डिफ़ॉल्ट मानने के बजाय)। आउटपुट बनाते समय इसे लागू करें; इसमें वह कैलिब्रेशन और निर्णय-विवेक है जिसे ऊपर का संक्षिप्त तरीका संकुचित कर देता है।
• templates/prioritisation-session.md — डिलिवरेबल का भरने योग्य संस्करण, गुणवत्ता-जाँच इनलाइन सहित। जब उपयोगकर्ता दस्तावेज़ खुद बनाना चाहे, उसे जनरेट करवाने के बजाय, तब यह पेश करें।

स्कोरिंग रूब्रिक (0–40)

इस स्किल का कोई भी आउटपुट सौंपने से पहले स्कोर करें; 32+ शिप-गुणवत्ता है।

गुणवत्ता जाँच

• हर आइटम एक ही लक्ष्य या मेट्रिक के सापेक्ष स्कोर किया गया है (प्रति आइटम अलग लक्ष्य नहीं)
• हटाए गए आइटम कारणों के साथ स्पष्ट रूप से सूचीबद्ध हैं (रैंक सूची से सिर्फ़ अनुपस्थित नहीं)
• स्कोरिंग में प्रयुक्त धारणाएँ दस्तावेज़ित हैं
• हितधारक राजनीति या व्यक्तिगत पसंद ढाँचे के स्कोर से अलग हैं
• प्राथमिकता किसी विशिष्ट दायरे (स्प्रिंट / तिमाही / लॉन्च) से जुड़ी है

एंटी-पैटर्न

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

उदाहरण ट्रिगर वाक्य

• "फ़ीचर को प्राथमिकता दो।"
• "बैकलॉग रैंक करो।"
• "तय करो कि आगे क्या बनाना है।"
• "प्रतिस्पर्धी विचारों के बीच समझौतों का मूल्यांकन करो।"

इस स्किल को अपने ब्राउज़र में चलाएँ: https://mohitagw15856.github.io/pm-claude-skills/skill/feature-prioritisation.html