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