go/no-go क्या तय करता है
go/no-go वह पल है जब बिज़नेस कहता है: CRM का यह वर्ज़न इस तारीख़ को प्रोडक्शन में जा सकता है। या वह कहता है: अभी नहीं। यह टेस्ट के अंत की कोई औपचारिकता नहीं है। यही वह वजह है जिसके लिए टेस्ट किया गया।
एक अच्छे go/no-go के तीन हिस्से होते हैं:
- तथ्य। क्या टेस्ट हुआ, क्या पास हुआ, क्या अभी खुला है। टेस्ट के नतीजों से लिए गए, याद से नहीं।
- एक आकलन। प्रक्रियाओं के मालिक बताते हैं कि क्या वे इस वर्ज़न के साथ अपना काम कर सकते हैं, और किन शर्तों पर।
- एक फ़ैसला। स्टीयरिंग कमेटी तथ्यों और आकलनों को गो-लाइव की तारीख़ के सामने तौलती है, और फ़ैसला करती है।
जो go/no-go मीटिंग बिगड़ जाती हैं, उनमें ज़्यादातर पहला हिस्सा नहीं होता। लोग बहस करते हैं कि कोई इश्यू कितना गंभीर है, या कोई प्रक्रिया टेस्ट हुई भी या नहीं, क्योंकि किसी के पास आँकड़े नहीं होते। इस गाइड का बाक़ी हिस्सा इसी बारे में है कि मीटिंग शुरू होने से पहले तथ्य मौजूद हों।
एग्ज़िट क्राइटेरिया: इन्हें पहले टेस्ट डे से पहले तय करें
एग्ज़िट क्राइटेरिया बताते हैं कि टेस्ट कब गो-लाइव के लिए काफ़ी अच्छा है। इन्हें पहले टेस्ट डे से पहले स्टीयरिंग कमेटी के साथ तय करें। अंत में भावनाएँ उफान पर होती हैं और तारीख़ें नज़दीक होती हैं। तब यह तय करने का गलत समय है कि क्या गिना जाएगा।
ज़्यादातर CRM गो-लाइव के लिए काम करने वाले क्राइटेरिया:
- कोई Critical इश्यू खुला नहीं है।
- हर Must टेस्ट केस पास हो चुका है।
- हर खुले High इश्यू के लिए एक वर्कअराउंड या फ़िक्स की एक तारीख़ है, जिसे बिज़नेस स्वीकार करता है।
- स्कोप के हर टेस्ट केस का एक नतीजा है।
- हर प्रक्रिया के मालिक ने साइन ऑफ़ कर दिया है।
शब्दों का मतलब तय करें
क्राइटेरिया तभी काम करते हैं जब सब एक ही पैमाना इस्तेमाल करें। लिखें कि हर गंभीरता का क्या मतलब है, और इसे टेस्टरों और स्टीयरिंग कमेटी, दोनों के साथ साझा करें:
| गंभीरता | इसका मतलब |
|---|---|
| Critical | कोई मुख्य प्रक्रिया काम नहीं करती और उससे बचने का कोई रास्ता नहीं है, या डेटा खो जाता है या गलत होता है। गो-लाइव रोकता है। |
| High | कोई मुख्य प्रक्रिया सिर्फ़ वर्कअराउंड के साथ काम करती है, या कोई ज़रूरी फ़ंक्शन फ़ेल होता है। |
| Medium | कोई फ़ंक्शन वैसे काम नहीं करता जैसे करना चाहिए, लेकिन उससे बचने का एक उचित रास्ता है। |
| Low | कॉस्मेटिक: टेक्स्ट, लेआउट, थोड़ी असुविधा। |
प्राथमिकता के लिए भी यही करें। Must के रूप में चिह्नित टेस्ट केस उसे कवर करता है जिसे पहले दिन से काम करना ज़रूरी है, जैसे कोट बनाना या केस रूट करना। अगर कोई Must टेस्ट केस फ़ेल होता है, तो गो-लाइव ख़तरे में है। प्राथमिकताएँ कैसे तय करें, इसके लिए देखें ऐसे टेस्ट केस लिखना जो बिज़नेस टेस्टर समझें।
लिखें कि क्या टेस्ट नहीं होगा
हर UAT में कुछ छूट जाता है: कोई देश जो बाद में गो-लाइव करता है, कोई रिपोर्ट जो तैयार नहीं है, कोई इंटीग्रेशन जो सिर्फ़ सिस्टम टेस्ट में टेस्ट हुआ। इसे टेस्ट से पहले लिख लें। तब go/no-go पर कोई नहीं कह सकता कि उसने मान लिया था कि यह कवर है।
कौन फ़ैसला करता है
दो तरह के लोग हिस्सा लेते हैं, अलग-अलग भूमिकाओं के साथ।
प्रक्रियाओं के मालिक साइन ऑफ़ करते हैं
टेस्ट की हर प्रक्रिया या ग्रुप के लिए, बिज़नेस का एक व्यक्ति साइन ऑफ़ करता है: lead to cash के लिए सेल्स डायरेक्टर, केस मैनेजमेंट के लिए कस्टमर सर्विस प्रमुख, इनवॉइसिंग के लिए फ़ाइनेंस लीड। वे जानते हैं कि उनकी टीमों को क्या चाहिए, और नतीजे के साथ उन्हें ही जीना है। उनका साइन-ऑफ़ कहता है: मेरे लोग इस वर्ज़न के साथ अपना काम कर सकते हैं।
उन्हें प्रोजेक्ट की शुरुआत में तय करें, आख़िरी हफ़्ते में नहीं। जो प्रक्रिया-मालिक टेस्ट को पहली बार go/no-go मीटिंग में देखता है, वह या तो बिना पढ़े साइन कर देगा, या एक हफ़्ता और माँगेगा।
स्टीयरिंग कमेटी फ़ैसला करती है
स्टीयरिंग कमेटी पूरे गो-लाइव का फ़ैसला लेती है। इसमें आम तौर पर बिज़नेस का स्पॉन्सर, प्रोजेक्ट मैनेजर, IT का एक लीड और, इम्प्लीमेंटेशन पार्टनर होने पर, पार्टनर का कोई व्यक्ति होता है। वह उन बातों को तौलती है जिन्हें अकेला प्रक्रिया-मालिक नहीं देख सकता: पुराने CRM का ख़त्म होने वाला कॉन्ट्रैक्ट, ट्रेनिंग प्लान, माइग्रेशन वीकेंड, उसी तारीख़ पर दूसरे प्रोजेक्ट।
टेस्ट लीड तैयारी करता है, पर फ़ैसला नहीं करता
टेस्ट लीड तथ्य और एक सलाह लाता है। टेस्ट लीड बिज़नेस की ओर से साइन ऑफ़ नहीं करता और फ़ैसला नहीं लेता। इन भूमिकाओं को अलग रखने से ही फ़ैसला तब भी टिका रहता है जब गो-लाइव के बाद कुछ गलत हो जाए।
रिपोर्ट: इसमें क्या होता है
go/no-go रिपोर्ट उन लोगों के लिए है जो टेस्ट में नहीं थे। इसे छोटा रखें: एक पेज, और जो चाहें उनके लिए उसके पीछे विवरण।
- एक सलाह। go, शर्तों के साथ go, या no-go, एक या दो पंक्तियों में कारणों के साथ।
- स्कोप। कौन-सी प्रक्रियाएँ और यूज़र स्टोरी टेस्ट में थीं, और क्या टेस्ट नहीं हुआ।
- क्या टेस्ट हुआ। परिवेश, रिलीज़ और बिल्ड। एक नतीजा सिस्टम के एक वर्ज़न का होता है।
- आँकड़े। पास, फ़ेल, ब्लॉक और अधूरे टेस्ट केस।
- हर ग्रुप या प्रक्रिया के अनुसार। वही आँकड़े, हर ग्रुप के साइन-ऑफ़ के साथ।
- प्राथमिकता के अनुसार। कितने Must, Should और Could टेस्ट केस पास हुए, और कौन-से Must टेस्ट केस पास नहीं हुए।
- गंभीरता के अनुसार इश्यू। कितने खुले हैं, रीटेस्ट के लिए तैयार हैं और बंद हैं, और खुले Critical और High इश्यू नाम सहित।
- साइन-ऑफ़। किसने साइन किया, कब, किस फ़ैसले के साथ और किन शर्तों पर।
- ज्ञात जोखिम। वे वर्कअराउंड जो बिज़नेस पहले हफ़्तों में इस्तेमाल करेगा, और उनमें कौन मदद करता है।
रिपोर्ट मीटिंग से एक दिन पहले भेजें। जो लोग इसे घर पर पढ़ते हैं, वे बेहतर सवाल पूछते हैं।
UAT Studio मेंडैशबोर्ड पर Go/no-go report में संकेत (GO, GO with conditions या NO-GO, कारणों के साथ), आँकड़े, हर दिन की प्रगति, हर ग्रुप, हर epic और हर प्राथमिकता के नतीजे, गंभीरता के अनुसार इश्यू, नाम सहित खुले Critical और High इश्यू, और राउंड का हर साइन-ऑफ़ होता है। संकेत तय नियमों पर चलता है और एक सलाह है: फ़ैसला स्टीयरिंग कमेटी करती है। इसे PDF के रूप में साझा करें या स्टीयरिंग कमेटी की प्रेज़ेंटेशन के लिए स्लाइड के रूप में डाउनलोड करें।
खुले इश्यू का क्या करें
UAT के अंत में हमेशा खुले इश्यू होते हैं। सवाल यह नहीं कि कोई है या नहीं, बल्कि यह कि हर एक पर फ़ैसला हुआ है या नहीं। मीटिंग से पहले, रोज़ाना के ट्राइएज की तरह, बिज़नेस और डेवलपमेंट टीम के साथ उन्हें देख लें।
| गंभीरता | गो-लाइव से पहले बिज़नेस को क्या चाहिए |
|---|---|
| Critical | ठीक किया और रीटेस्ट किया हुआ। अगर समय पर ठीक नहीं हो सकता, तो जवाब no-go है, या वह प्रक्रिया गो-लाइव से बाहर जाती है। |
| High | ठीक किया हुआ, या ऐसा वर्कअराउंड जिसे प्रक्रिया-मालिक स्वीकार करे, फ़िक्स की तारीख़ के साथ। |
| Medium | फ़िक्स की एक तारीख़, या फ़िलहाल इसके साथ चलने का फ़ैसला। |
| Low | बैकलॉग पर। रुकने की वजह नहीं। |
सावधानी से दोबारा वर्गीकृत करें
आख़िरी दिनों में किसी Critical इश्यू को High करने का दबाव होता है। कभी-कभी यह सही होता है: कोई वर्कअराउंड मिल जाता है, या प्रक्रिया दुर्लभ निकलती है। इसे खुलकर करें, ट्राइएज में, प्रक्रिया-मालिक के साथ, और लिखें कि क्यों। आँकड़े बेहतर दिखाने के लिए इसे कभी चुपचाप न करें। ऐसे ही गो-लाइव अपने पहले हफ़्ते में फ़ेल होता है।
इच्छाएँ डिफ़ेक्ट नहीं हैं
टेस्टरों को ऐसी चीज़ें मिलती हैं जिन्हें वे अलग चाहते हैं। अगर सिस्टम डिज़ाइन के अनुसार काम करता है, तो यह एक change request है: यह बैकलॉग पर जाता है, इस रिलीज़ में नहीं, और गो-लाइव के ख़िलाफ़ नहीं गिना जाता।
UAT Studio मेंट्राइएज हर इश्यू को एक गंभीरता, एक प्राथमिकता, एक असाइनी और एक फ़ैसला देता है: Fix, Reject या Change request। AI test design मॉड्यूल के साथ, Issues टैब पर Summarize with AI go/no-go मीटिंग के लिए खुले इश्यू का एक छोटा ओवरव्यू लिखता है: थीम के अनुसार ग्रुप किया हुआ, और क्या गो-लाइव रोकता है। इसके बिना, Summarize with your own AI एक prompt देता है जिसे आप अपनी कंपनी के AI में पेस्ट कर सकते हैं।
शर्तों के साथ go
कई CRM गो-लाइव को शर्तों के साथ go मिलता है। सिस्टम काफ़ी अच्छा है, बशर्ते गो-लाइव से पहले या उसके तुरंत बाद कुछ किया जाए। यह एक उचित फ़ैसला है, जब तक शर्तें असली हों।
एक अच्छी शर्त होती है:
- ठोस। 50,000 से ऊपर के ऑर्डर के लिए डिस्काउंट की मंज़ूरी ठीक की गई और रीटेस्ट हुई, न कि मंज़ूरियाँ काम करती हैं।
- किसी की ज़िम्मेदारी। एक व्यक्ति, नाम से, इसके लिए ज़िम्मेदार है।
- तारीख़ के साथ। गो-लाइव से पहले, या उसके बाद के पहले हफ़्तों की कोई तारीख़।
- जाँचा हुआ। कोई पुष्टि करता है कि यह हो गया, और स्टीयरिंग कमेटी को इसकी ख़बर मिलती है।
शर्तों की संख्या पर नज़र रखें। दो या तीन सामान्य हैं। पंद्रह का मतलब है कि टेस्ट पूरा नहीं हुआ। शर्तों के साथ go, no-go से बचने का तरीका नहीं है।
हिस्सों में गो-लाइव
कभी-कभी एक प्रक्रिया तैयार नहीं होती और बाक़ी तैयार होती हैं। तब आप उस प्रक्रिया के बिना गो-लाइव कर सकते हैं, या किसी एक देश या टीम के साथ बाद में। इसे स्पष्ट रूप से तय करें, जो हिस्सा इंतज़ार करता है उसकी नई तारीख़ लिखें, और उसका अपना UAT राउंड और साइन-ऑफ़ प्लान करें।
हर ग्रुप का साइन-ऑफ़
हर प्रक्रिया या ग्रुप के लिए साइन-ऑफ़ माँगें, सब कुछ के लिए एक हस्ताक्षर नहीं। सेल्स डायरेक्टर केस मैनेजमेंट का आकलन नहीं कर सकता, और उसे करना भी नहीं चाहिए। हर मालिक तीन में से एक जवाब चुनता है:
- Accepted: मेरे लोग इस वर्ज़न के साथ अपना काम कर सकते हैं।
- Accepted with conditions: बशर्ते शर्तें पूरी हों। हर शर्त लिखें, इस बात के साथ कि उसे कौन करेगा और कब तक।
- Rejected: गो-लाइव के लिए काफ़ी अच्छा नहीं। पूछें कि जवाब किस चीज़ से बदलेगा।
मीटिंग से पहले साइन-ऑफ़ इकट्ठा करें, ताकि स्टीयरिंग कमेटी पूरी तस्वीर पर फ़ैसला करे। एक साइन-ऑफ़ एक वर्ज़न का होता है: जब नया बिल्ड या टेस्ट का नया राउंड आता है, तो फिर से साइन ऑफ़ करें।
UAT Studio मेंडैशबोर्ड पर Sign-off कार्ड में पूरे प्रोजेक्ट के लिए एक पंक्ति और हर ग्रुप के लिए एक पंक्ति होती है, Accepted, Accepted with conditions या Rejected के साथ। तारीख़, समय और खुले Critical इश्यू की संख्या दर्ज होती है। डिफ़ॉल्ट रूप से, जब तक कोई Critical इश्यू खुला है, कोई स्वीकार नहीं कर सकता; No sign-off while Must test cases have not passed पर टिक होने पर, स्वीकार करना तब तक भी रुका रहता है जब तक हर Must टेस्ट केस पास न हो जाए। अस्वीकार करना हमेशा संभव है। एक साइन-ऑफ़ मौजूदा राउंड का होता है।
go/no-go मीटिंग चलाना
मीटिंग उसी समय प्लान करें जब आप टेस्ट डे प्लान करते हैं, तारीख़ स्टीयरिंग कमेटी के कैलेंडर में डालकर। एक घंटा रखें। एक आम क्रम:
- टेस्ट लीड रिपोर्ट दिखाता है: स्कोप, आँकड़े, खुले इश्यू, साइन-ऑफ़। दस मिनट, आँकड़े स्क्रीन पर।
- हर प्रक्रिया-मालिक एक-दो वाक्यों में बताता है कि उसने वैसे साइन क्यों किया, और उसकी शर्तें क्या हैं।
- खुले Critical और High इश्यू के बारे में सवाल: क्या कोई फ़िक्स, वर्कअराउंड, तारीख़ है?
- टेस्ट से बाहर के सवाल: ट्रेनिंग, डेटा माइग्रेशन, पहले हफ़्तों में सपोर्ट, रोलबैक का प्लान।
- फ़ैसला: go, शर्तों के साथ go, या no-go। इसे शर्तों, मालिकों और तारीख़ों के साथ ज़ोर से पढ़कर सुनाएँ।
अगर फ़ैसला no-go है, तो एक प्लान के साथ ख़त्म करें: क्या बदलना है, एक नया टेस्ट राउंड, और अगले go/no-go की तारीख़। प्लान के साथ no-go एक सामान्य प्रोजेक्ट फ़ैसला है। प्लान के बिना no-go नाकामी जैसा लगता है।
डिसीज़न लॉग
फ़ैसला उसी दिन लिख लें। महीनों बाद, किसी घटना के बाद या ऑडिट के दौरान, कोई पूछेगा कि उस खुले इश्यू के साथ गो-लाइव करने का फ़ैसला किसने किया। जवाब ढूँढने में एक मिनट लगना चाहिए।
एक डिसीज़न लॉग में, हर go/no-go के लिए, यह होता है:
- तारीख़, और मीटिंग में कौन था।
- फ़ैसला: go, शर्तों के साथ go, या no-go।
- हर शर्त, उसके मालिक, उसकी तारीख़ और, बाद में, वह कब पूरी हुई, इसके साथ।
- वे खुले इश्यू जिन्हें बिज़नेस ने स्वीकार किया, कारण के साथ।
- वह रिपोर्ट जिस पर फ़ैसला आधारित था, जैसी वह उस पल थी।
इसे प्रोजेक्ट दस्तावेज़ों के साथ रखें, और गो-लाइव के बाद के पहले हफ़्तों में शर्तों पर फ़ॉलो-अप करें, जब तक हर एक पूरी न हो जाए।
UAT Studio मेंgo/no-go रिपोर्ट पर Save snapshot रिपोर्ट को वैसा ही रखता है जैसी वह फ़ैसले के समय थी; वह फिर नहीं बदलती, और Show उसे बाद में फिर से खोलता है। हर साइन-ऑफ़ हिस्ट्री में रहता है, वे भी जो बदल दिए गए या वापस लिए गए। ऑडिटर के लिए, एडमिन Evidence pack डाउनलोड करते हैं: रिपोर्ट, टेस्ट केस, नतीजे और इश्यू, हर इश्यू की हिस्ट्री, हर साइन-ऑफ़ और audit log, हर फ़ाइल के checksum के साथ।
इस्तेमाल के लिए मुफ़्त
एग्ज़िट क्राइटेरिया, साइन-ऑफ़ और रिपोर्ट CRM गो-लाइव के लिए UAT चेकलिस्ट में भी हैं, मुफ़्त Excel फ़ाइल के रूप में। पूरे टेस्ट के लिए, Salesforce UAT और Dynamics 365 UAT की गाइड देखें।