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