अस्पष्ट गुणवत्ता लक्ष्य को देखी जा सकने वाली प्रतिक्रिया और मापन नियम वाले परिदृश्य में बदलें। “पोर्टल तेज होना चाहिए” डिजाइन चुनने या यह तय करने के लिए पर्याप्त नहीं कि रिलीज़ आवश्यकता पूरी करती है।
उत्तेजना का स्रोत, उत्तेजना, प्रभावित सिस्टम, संचालन की परिस्थितियाँ, अपेक्षित प्रतिक्रिया और उसका माप पहचानें। ये हिस्से धारणाएँ स्पष्ट करते हैं ताकि अलग-अलग टीमें एक ही दावे को जाँच सकें।
उदाहरण के रिटर्न पोर्टल के व्यावसायिक स्वामी से यह परिदृश्य तय करें:
ये संख्याएँ उदाहरण के लक्ष्य हैं, उद्योग की डिफ़ॉल्ट सीमाएँ नहीं। विफलताएँ अलग रिपोर्ट करें ताकि जल्दी अस्वीकृति से विलंब का परिणाम अच्छा न दिखे। प्राप्ति की पुष्टि गोदाम में काम पूरा होने से भी अलग है; उसके लिए अलग व्यावसायिक समय मानदंड चाहिए।
डिजाइन अनुरोध को स्थायी रूप से स्वीकार करके गोदाम का काम असिंक्रोनस कर सकता है। यथार्थ नेटवर्क परिस्थितियों सहित उसी मार्ग का परीक्षण करें। अनुपलब्ध निर्भरता और रिकवरी के अलग परिदृश्य लिखें; स्वस्थ सिस्टम का लोड टेस्ट इनमें से किसी को साबित नहीं करता।
औसत विलंब धीमा अनुभव पाने वाले उपयोगकर्ताओं को छिपा देता है। अपरिभाषित डेटा परिणाम दोहराना कठिन बनाता है। “हमेशा उपलब्ध” न विफलता की सीमा देता है न मापन अवधि। मजबूत उत्तर बताता है कि क्या, कहाँ से, किन परिस्थितियों में मापा जाता है और लक्ष्य पर्याप्त होने पर कौन सहमत है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें