अपने प्रोजेक्ट के लिए सही मेट्रिक चुनना

इस गाइड का मकसद, संगठनों को यह समझने में मदद करना है कि बेहतर दस्तावेज़ों की मदद से किस तरह की समस्याओं को हल किया जा सकता है. साथ ही, दस्तावेज़ प्रोजेक्ट के लिए सही मेट्रिक चुनने का तरीका भी बताया गया है.

मौजूदा चरण:
दस्तावेज़ तैयार करना. टाइमलाइन देखें.

अपनी समस्या बताएं

कोई मेट्रिक चुनने से पहले, पक्का करें कि आपको इस बात की अच्छी समझ है कि आपको किस समस्या को हल करना है. सटीक जानकारी दें.

  • "हमारे ऑनबोर्डिंग दस्तावेज़ के लिए पुल के अनुरोधों को मर्ज करने में बहुत ज़्यादा समय लगता है. योगदान देने वाले हार नहीं मानकर चले जाते हैं."
  • "गड़बड़ी कोड को समझने में मदद के लिए, हमें कई समस्याएं दिखती हैं."
  • "हमारी सीआई/सीडी पाइपलाइन में गड़बड़ी है. गलत जानकारी की वजह से कई टेस्ट फ़ेल हो जाते हैं."
  • "हमारी हर हफ़्ते होने वाली मीटिंग में लोग चिड़चिड़े दिखते हैं."

परिकल्पना बनाना

वजह और असर का पता लगाएं. आपने जो समस्या बताई है उसकी वजह क्या हो सकती है? ध्यान रखें कि समस्याओं की एक से ज़्यादा या ओवरलैप होने की वजहें हो सकती हैं.

  • "ऑनबोर्डिंग दस्तावेज़ के लिए पुल अनुरोधों को मर्ज करने में काफ़ी समय लगता है, क्योंकि हमारे पास स्टाइल के बारे में साफ़ तौर पर दिशा-निर्देश नहीं हैं. समीक्षक या तो पीआर की समीक्षा करना बंद कर देते हैं, क्योंकि उन्हें यह नहीं पता होता कि क्या करना है या वे योगदान देने वालों से लगातार फ़ॉर्मैटिंग के बारे में बात करते रहते हैं."
  • "दस्तावेज़ में गड़बड़ी के कोड के बारे में जानकारी नहीं होने की वजह से, उपयोगकर्ताओं को समस्याएं खोलनी होंगी."
  • "हमारे सीआई/सीडी टेस्ट फ़ेल हो जाते हैं, क्योंकि हम प्लान की सीमाओं में चलते हैं और सेवा देने वाली कंपनी से टाइम आउट हो जाता है."
  • "हर हफ़्ते होने वाली हमारी मीटिंग में लोग नाराज़ होते हैं, क्योंकि उनके टाइम ज़ोन में सुबह 5:30 बजे मीटिंग होती हैं."

कोई समाधान सुझाएं

क्या यह कोई ऐसी समस्या है जिसे नए या बेहतर दस्तावेज़ की मदद से ठीक किया जा सकता है?

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

सटीक जानकारी पाएं

क्या आप इस सवाल का आकलन कर सकते हैं?

  • "'पीआरएस को मर्ज करने में बहुत ज़्यादा समय लगता है' का क्या मतलब है? दो महीने? दो हफ़्ते? योगदान देने वाले, अपना काम सबमिट करने से पहले कितने समय तक समीक्षा के लिए इंतज़ार करेंगे?"
  • "गड़बड़ी-कोड से जुड़ी कितनी समस्याएं 'बहुत ज़्यादा समस्याएं' हैं?"
  • "हम्म ... 'बहुत चिड़चिड़ाहट' कितना चिड़चिड़ा है?"

मापे जाने की क्षमता की जांच करें

सबमिट की गई मेट्रिक की जांच करने का तरीका क्या है? क्या इसे आसानी से और सटीक तरीके से मापा जा सकता है? क्या मेज़रमेंट इस बात पर निर्भर करता है कि मेज़रमेंट कौन कर रहा है?

  • "हम आसानी से यह मेज़र कर सकते हैं कि पुल का अनुरोध कितने समय से और समीक्षा का अनुरोध कितने समय से किया गया है. हम असल में यह नहीं माप सकते कि योगदान देने वाला कब हार मान लेता है."
  • "हम यह गिन सकते हैं कि 'गड़बड़ी का कोड' वाली कितनी समस्याओं को टैग किया गया है या गड़बड़ी के कोड के टेक्स्ट में, समस्याओं को खोजा जा सकता है."
  • "हम वाकई लोगों की चिड़चिड़ापन, समझदारी या सटीक तरीके से माप नहीं सकते."

सेकंडरी मेट्रिक जोड़ना

क्या कोई ऐसी मेट्रिक हैं जिनसे आपको यह समझने में मदद मिलेगी कि आपके दस्तावेज़ से आपकी समस्या हल हो रही है या नहीं? क्या आपकी टारगेट मेट्रिक हर मामले में एक जैसी है?

  • "लंबे समय तक चलने वाले PR की समीक्षा में ज़्यादा समय लगता है. अलग-अलग साइज़ के PRs के लिए अलग-अलग थ्रेशोल्ड होना चाहिए. हम छोटे, मध्यम, बड़े, और बड़े PR के मर्ज होने में लगने वाले समय का आकलन करना चाहते हैं."
  • "हम यह जांच कर सकते हैं कि हमारे गड़बड़ी कोड दस्तावेज़ को कितनी बार विज़िट किया गया और यह देखा जा सकता है कि क्या वह संख्या कम समस्याओं के साथ मेल खाती है."

कोई समयावधि चुनें

  • "हमें लगता है कि छोटे से मध्यम आकार के पीआर को मर्ज करने के लिए दो हफ़्ते का समय सही होता है; और सभी पीआर को एक महीने में मर्ज कर दिया जाना चाहिए. इसलिए हम हर दो हफ़्ते में इसका आकलन करेंगे."
  • "गड़बड़ी कोड से जुड़ी समस्याओं की संख्या को हर दिन अपडेट करना सही नहीं है. इसकी वजह यह है कि आम तौर पर, किसी समस्या को बंद करने में एक हफ़्ते का समय लगता है. हम हर हफ़्ते इसका आकलन करेंगे."

लक्ष्य सेट करें

प्रोजेक्ट सफल होने की जानकारी देने के लिए, आपको अपनी चुनी गई मेट्रिक में कितना बदलाव देखने की ज़रूरत होगी? आपने जिन मेट्रिक को चुना है उनके लिए आंकड़ों वाले लक्ष्य तय करें.

  • "अगर हमने एक महीने से भी कम समय में, हर नए पीआर को बंद करने का अपना लक्ष्य पूरा कर लिया, तो यह हमारी सफलता होगी. अगर बड़े PRs को बंद करने के हमारे औसत समय में दो हफ़्ते की कमी आती है, तो यह एक बड़ी सफलता होगी."
  • "आम तौर पर, हमें गड़बड़ी से जुड़ी कोई नई समस्या नहीं दिखती. हालांकि, अगर हमें गड़बड़ियों से जुड़ी समस्याओं में 50% की गिरावट आती है, तो हम अपने प्रोजेक्ट को सफल मानेंगे."