इस गाइड का मकसद, संगठनों को यह समझने में मदद करना है कि बेहतर दस्तावेज़ों की मदद से किस तरह की समस्याएं हल हो सकती हैं. साथ ही, दस्तावेज़ प्रोजेक्ट के लिए सही मेट्रिक चुनने का तरीका भी बताया गया है.
मौजूदा चरण:
नतीजे का एलान
टाइमलाइन किया गया.
अपनी समस्या बताएं
मेट्रिक चुनने से पहले, पक्का करें कि आपको जिस समस्या को हल करना है उसके बारे में अच्छी तरह से समझ लें. ज़्यादा से ज़्यादा सटीक जानकारी दें.
- “हमारे ऑनबोर्डिंग दस्तावेज़ के लिए पुल के अनुरोधों को मर्ज करने में बहुत ज़्यादा समय लगता है. योगदान देने वाले हार मानकर चले जाते हैं.”
- “गड़बड़ी कोड को समझने के लिए, हमें कई समस्याओं के खुले होने की जानकारी मिली है.”
- “हमारी सीआई/सीडी पाइपलाइन में गड़बड़ी है. कई टेस्ट ऐसे हो जाते हैं जिनके बारे में हमें ठीक से पता नहीं है.”
- “हमारी हर हफ़्ते होने वाली मीटिंग में लोग चिड़चिड़े नज़र आते हैं.”
एक परिकल्पना बनाना
वजह और असर देखें. आपने जो समस्या बताई है उसकी वजह क्या है? ध्यान रखें कि समस्याओं के कई या एक जैसे कारण हो सकते हैं.
- “ ऑनबोर्डिंग दस्तावेज़ के लिए पुल के अनुरोधों को मर्ज करने में बहुत ज़्यादा समय लगता है, क्योंकि हमारे पास स्टाइल के बारे में साफ़ तौर पर दिशा-निर्देश नहीं हैं. समीक्षा करने वाले लोग या तो पीआर की समीक्षा करना बंद कर देते हैं, क्योंकि उन्हें पता नहीं होता कि क्या करना है या वे फ़ॉर्मैट के बारे में योगदान देने वालों से बार-बार संपर्क करते रहते हैं.”
- “उपयोगकर्ताओं को समस्याओं का सामना करना पड़ सकता है, क्योंकि उन्हें दस्तावेज़ में गड़बड़ी के कोड के बारे में जानकारी नहीं मिलती.”
- “हमारे सीआई/सीडी टेस्ट फ़ेल हो जाते हैं, क्योंकि हमारे पास प्लान की सीमाएं होती हैं और सेवा देने वाली कंपनी से टाइम आउट होने की वजह से ऐसा होता है.”
- “हमारी हर हफ़्ते होने वाली मीटिंग में लोग बहुत गुस्सा आते हैं, क्योंकि मीटिंग उनके टाइम ज़ोन में सुबह 5:30 बजे की होती हैं.”
कोई समाधान सुझाएं
क्या यह समस्या, नए या बेहतर दस्तावेज़ों की मदद से हल हो सकती है?
- “अगर हमारे पास कोई स्टाइल गाइड होती, तो कमिटर अपने पीआर सबमिट करने से पहले उसे देख सकते थे. इससे समीक्षकों को पता चल जाएगा कि क्या जांचना है. समीक्षकों और योगदान देने वालों को फ़ॉर्मैटिंग, टोन, और स्टाइल के बारे में बहस नहीं करनी पड़ेगी.”
- “अगर हमारे पास गड़बड़ी कोड से जुड़ा दस्तावेज़ होता, तो लोग समस्याओं को खोलने के बजाय, अपने जवाब वहीं ढूंढते हैं."
- “ऐसा लगता है कि बेहतर दस्तावेज़ से हमारी सीआई/सीडी की समस्या हल नहीं हो सकती.”
- “हम हर मीटिंग की शुरुआत नॉक-नॉक चुटकुले से कर सकते हैं! सुनिए-सुनिए चुटकुलों का संग्रह बनाने से हमें अपनी मीटिंग की शुरुआत करने में मदद मिलेगी.”
सटीक जानकारी पाएं
क्या तुम सवाल हल कर सकते हो?
- “‘पीआरएस को मर्ज करने में बहुत ज़्यादा समय लगता है’ का क्या मतलब है? दो महीने? दो हफ़्ते? जवाब देने से पहले, योगदान देने वाले लोग समीक्षा के लिए कितना इंतज़ार करेंगे?”
- “गड़बड़ी-कोड से जुड़ी कितनी समस्याएं 'बहुत ज़्यादा समस्याएं' हैं?”
- “हम्म ... कितना चिड़चिड़ा हुआ है’?”
मापे जाने की क्षमता की जांच करें
अपने प्रस्तावित मेट्रिक की जांच कैसे की जा सकती है? क्या इसे आसानी से और सटीक तरीके से मापा जा सकता है? क्या मेज़रमेंट इस बात पर निर्भर करता है कि मेज़रमेंट कर रहा है?
- “हम आसानी से यह माप सकते हैं कि पुल का अनुरोध कितने समय से किया गया है और समीक्षा का अनुरोध कितने समय से किया गया है. हम असल में इसका आकलन नहीं कर सकते कि योगदान देने वाला कब हार मान लेता है.”
- “हम गिन सकते हैं कि कितनी समस्याओं को ‘गड़बड़ी का कोड’ के तौर पर टैग किया गया है या गड़बड़ी कोड के टेक्स्ट के लिए समस्याओं में खोज की गई है.”
- “हम लोगों की चिड़चिड़ापन को चतुराई से या सटीक तरीके से नहीं माप सकते.”
दूसरी मेट्रिक जोड़ना
क्या कोई ऐसी मेट्रिक हैं जिनसे आपको यह समझने में मदद मिलेगी कि आपके दस्तावेज़ से आपकी समस्या हल हो रही है या नहीं? क्या आपकी टारगेट मेट्रिक हर मामले में एक जैसी है?
- “लंबे समय तक चलने वाली पीआर को समीक्षा करने में ज़्यादा समय लगता है; अलग-अलग तरह की पीआरओ के लिए हमारे पास अलग-अलग थ्रेशोल्ड होने चाहिए. हम छोटे, मध्यम, बड़े, और बड़े पीआर के लिए मर्ज होने में लगने वाले समय का आकलन करना चाहते हैं.”
- “हम यह जांच कर सकते हैं कि हमारे गड़बड़ी कोड दस्तावेज़ को कितनी बार विज़िट किया गया और यह देखा जा सकता है कि क्या उस संख्या का संबंध कम समस्याओं के साथ है.”
कोई समयावधि चुनें
- “हमें लगता है कि छोटे से मध्यम स्तर की इकाइयों को मर्ज करने के लिए दो हफ़्ते का समय सही होता है; और सभी पीआरओ को एक महीने में मर्ज कर दिया जाना चाहिए. इसलिए हम हर दो हफ़्ते में एक बार जांच करेंगे.”
- “गड़बड़ी कोड से जुड़ी समस्याओं की संख्या को हर दिन अपडेट करने का कोई फ़ायदा नहीं है. इसकी वजह यह है कि आम तौर पर किसी समस्या को ठीक करने में एक हफ़्ते का समय लगता है. हम इसे हर हफ़्ते मेज़र करेंगे.”
लक्ष्य सेट करें
आपको अपनी चुनी गई मेट्रिक में कितना बदलाव देखना चाहिए, ताकि यह साबित किया जा सके कि आपका प्रोजेक्ट सफल था? अपनी चुनी गई मेट्रिक के लिए आंकड़ों वाले लक्ष्य तय करें.
- "अगर हम एक महीने से भी कम समय में हर नए पीआर को बंद करने के अपने लक्ष्य को पूरा कर लेते हैं, तो यह एक सफलता होगी. अगर बड़े पीआरएस को बंद करने में हमारे औसत समय में दो हफ़्ते की कमी आती है, तो यह एक बड़ी सफलता होगी."
- “आम तौर पर, हमें गड़बड़ी से जुड़ी कोई नई समस्या नहीं दिखेगी. हालांकि, अगर हमें गड़बड़ी से जुड़ी समस्याओं के हल में 50% की गिरावट आती है, तो हम अपने प्रोजेक्ट को सफल मानेंगे.”
इससे जुड़ी जानकारी
- रिपोर्ट से जुड़े कामों में मदद पाने के लिए, संगठन के एडमिन के लिए गाइड पढ़ें.