معیار کے مبہم ہدف کو قابلِ مشاہدہ جواب اور پیمائش کے اصول والے scenario میں بدلیں۔ “پورٹل تیز ہونا چاہیے” ڈیزائن منتخب کرنے یا یہ طے کرنے کے لیے کافی نہیں کہ ریلیز ضرورت پوری کرتی ہے۔
محرک کا ماخذ، محرک، متاثرہ سسٹم، عملی حالات، متوقع جواب اور جواب کی پیمائش پہچانیں۔ یہ حصے مفروضوں کو واضح کرتے ہیں تاکہ مختلف ٹیمیں ایک ہی دعوے کو جانچ سکیں۔
واپسی کے ایک فرضی پورٹل کے لیے اس کے کاروباری مالک سے اس scenario پر اتفاق کریں:
یہ اعداد مثال کے اہداف ہیں، صنعت کے طے شدہ معیارات نہیں۔ ناکامیاں الگ رپورٹ کریں تاکہ فوری انکار تاخیر کے نتیجے کو اچھا نہ دکھا سکے۔ وصولی کی تصدیق گودام میں کام مکمل ہونے سے بھی مختلف ہے؛ اس کے لیے الگ کاروباری وقت کا معیار چاہیے۔
ڈیزائن درخواست کو پائیدار طور پر قبول کر کے گودام کا کام غیر ہم وقت انداز میں انجام دے سکتا ہے۔ حقیقی نوعیت کے نیٹ ورک حالات سمیت عین اسی راستے کی جانچ کریں۔ کسی انحصار کی عدم دستیابی اور بحالی کے لیے الگ scenarios لکھیں؛ درست چلتے سسٹم کا load test ان میں سے کسی کو ثابت نہیں کرتا۔
اوسط تاخیر سست جواب پانے والے صارفین کو چھپا دیتی ہے۔ غیر متعین dataset نتائج کو دوبارہ حاصل کرنا مشکل بناتا ہے۔ “ہمیشہ دستیاب” ناکامی کی حد یا پیمائش کا دورانیہ نہیں دیتا۔ مضبوط انٹرویو جواب واضح کرتا ہے کہ کیا، کہاں سے، کن حالات میں ناپا جائے گا اور ہدف کے کافی ہونے پر کون اتفاق کرتا ہے۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں