मंगलवार की सुबह, आपके प्रोडक्ट मैनेजर ने आपको मैसेज किया कि रिलीज़ की तारीख खतरे में है। लंच तक, इंटीग्रेशन लीड ने बताया कि वेंडर ने अपना API बदल दिया है और टीम को दोबारा काम करना होगा। दिन खत्म होने तक, QA पूछ रहा था कि कौन से टेस्ट छोड़ दिए जाएं क्योंकि शेड्यूल छोटा हो गया है। सिक्योरिटी एनालिस्ट ने कहा कि टेस्टिंग का समय कम होने का मतलब है कि नतीजे शायद कोड फ्रीज़ के बाद आएंगे। आप प्रोजेक्ट मैनेजर हैं, और फैसला यह करना है कि स्कोप वही रखें, तारीख आगे बढ़ाएं, या क्वालिटी से समझौता करें। आपके इंतज़ार करने के हर घंटे के साथ, आखिरी फैसले की लागत बढ़ती जाती है क्योंकि टीमें अलग-अलग धारणाओं के आधार पर काम करती रहती हैं।
स्टेटस स्लाइड बनाने से पहले, आपको एक साफ अंतर समझने की ज़रूरत है। रिस्क (जोखिम) भविष्य की एक अनिश्चित घटना है जो लक्ष्यों पर असर डाल सकती है। इश्यू (समस्या) एक मौजूदा दिक्कत है जो पहले से ही हो रही है। वेंडर का API बदलना खुद एक इश्यू है, जब यह हो जाता है। इसके होने की संभावना पहले एक रिस्क थी। यह कोर्स उस अंतर को साफ और उपयोगी बनाए रखने के लिए ज़रूरी समझ और टूल्स तैयार करता है। इसमें एक काम करने वाला रिस्क रजिस्टर, लक्ष्यों और रिस्क लेने की क्षमता का एक पेज का ब्यौरा, ट्रिगर्स के साथ साफ रिस्क स्टेटमेंट, और हल्की-फुल्की मॉनिटरिंग का इस्तेमाल किया जाता है ताकि अनिश्चितता का पता समय रहते चल जाए और उस पर कार्रवाई की जा सके।
शुरुआत करने के लिए, घटनाओं के क्रम को देखें और पहचानें कि प्रोजेक्ट कब अनिश्चितता से असलियत में बदला।
जब टीमें इस बात पर बहस करती हैं कि क्या किसी चीज़ का रिस्क ट्रैक करने लायक है, तो वे अक्सर किसी और चीज़ पर बहस कर रही होती हैं। वे इस बात पर बहस कर रही होती हैं कि प्रोजेक्ट किस चीज़ को बेहतर बनाने (ऑप्टिमाइज़) के लिए है, किन मान्यताओं (अज़म्पशन्स) को माना जा सकता है, और किन सीमाओं (कन्स्ट्रेंट्स) को बदला नहीं जा सकता। अगर ये बातें साफ़ नहीं हैं, तो रिस्क के बारे में हर बातचीत ‘इस पर नज़र रखें’ जैसी अस्पष्ट सलाह पर खत्म होती है।
एक प्रैक्टिकल फ़्रेमवर्क एक पेज में आ जाता है और लक्ष्यों (ऑब्जेक्टिव्स) से शुरू होता है। शेड्यूल का लक्ष्य तिमाही के अंत तक डिलीवरी हो सकता है। लागत का लक्ष्य तय वेंडर बजट के अंदर रहना हो सकता है। क्वालिटी का लक्ष्य लॉन्च के समय ज़ीरो क्रिटिकल सिक्योरिटी कमियां होना हो सकता है। इसके बाद आप उन मान्यताओं की लिस्ट बनाते हैं जिन्हें आप प्लानिंग के लिए सही मान रहे हैं, जैसे कि वेंडर API बैकवर्ड कम्पैटिबल रहे, और उन सीमाओं की जो बदली नहीं जा सकतीं, जैसे कि रेगुलेटरी डेडलाइन। फिर आप रिस्क एपेटाइट (रिस्क लेने की क्षमता) जोड़ते हैं, यानी स्पॉन्सर कितना बदलाव बर्दाश्त करेगा, इससे पहले कि वे मामले को ऊपर ले जाने (एस्केलेशन) और फ़ैसले की उम्मीद करें। एपेटाइट का मतलब उम्मीद या आशावाद नहीं है। यह कार्रवाई के लिए एक सीमा है।
आम गलती। गलत सोच यह है कि एक ही तरह का एपेटाइट तय कर दिया जाए, जैसे कि ‘हम कम रिस्क वाले हैं’। यह फ़ैसला लेने जैसा लगता है। इसका नतीजा छिपे हुए ट्रेड-ऑफ़ होते हैं, जहाँ टीम स्पॉन्सर की मंज़ूरी के बिना टेस्ट कम करके शेड्यूल बचाती है, या सेल्स को बताए बिना तारीख आगे बढ़ाकर क्वालिटी बचाती है।
ऐसे एपेटाइट चुनें जो प्रोजेक्ट के संदर्भ से मेल खाते हों, न कि आपकी निजी पसंद से।