منگل کی صبح، آپ کا پروڈکٹ مینیجر آپ کو اطلاع دیتا ہے کہ ریلیز کی تاریخ اب خطرے میں ہے۔ دوپہر کے کھانے کے وقت تک، انٹیگریشن لیڈ بتاتا ہے کہ وینڈر نے اپنا API تبدیل کر دیا ہے اور ٹیم کو دوبارہ کام کرنے کی ضرورت ہے۔ دن کے اختتام تک، QA (کوالٹی ایشورنس) پوچھ رہا ہے کہ کون سے ٹیسٹ چھوڑ دیے جائیں کیونکہ شیڈول مختصر ہو گیا ہے۔ سیکیورٹی تجزیہ کار مزید کہتا ہے کہ ٹیسٹنگ کے لیے کم وقت کا مطلب غالباً یہ ہوگا کہ نتائج ‘کوڈ فریز’ (code freeze) کے بعد سامنے آئیں گے۔ آپ پروجیکٹ مینیجر ہیں، اور آپ کو اس مشکل فیصلے کا سامنا ہے کہ آیا پروجیکٹ کے دائرہ کار (scope) کو برقرار رکھا جائے، تاریخ تبدیل کی جائے، یا معیار (quality) پر سمجھوتہ کیا جائے۔ آپ جتنی دیر انتظار کرتے ہیں، حتمی فیصلے کی لاگت اتنی ہی بڑھ جاتی ہے کیونکہ ٹیمیں مختلف مفروضوں کی بنیاد پر کام جاری رکھتی ہیں۔
اسٹیٹس سلائیڈ (status slide) تیار کرنے سے پہلے، آپ کو ایک واضح فرق سمجھنے کی ضرورت ہے۔ رسک (Risk) مستقبل کا ایک غیر یقینی واقعہ ہے جو مقاصد پر اثر انداز ہو سکتا ہے۔ مسئلہ (Issue) ایک موجودہ مشکل ہے جو پہلے ہی پیش آ چکی ہے۔ وینڈر کی جانب سے API میں تبدیلی خود ایک ‘مسئلہ’ ہے جب وہ واقع ہو جائے۔ اس کے ہونے کا امکان پہلے ایک ‘رسک’ تھا۔ یہ کورس اس فرق کو واضح اور مفید رکھنے کے لیے ضروری فہم اور ٹولز (artifacts) فراہم کرتا ہے؛ اس میں ایک فعال رسک رجسٹر، مقاصد اور رسک برداشت کرنے کی صلاحیت (appetite) کا ایک صفحے پر خاکہ، ٹریگرز (triggers) کے ساتھ واضح رسک اسٹیٹمنٹس، اور ہلکی پھلکی نگرانی (lightweight monitoring) کا استعمال شامل ہے تاکہ غیر یقینی صورتحال اتنی جلدی سامنے آ جائے کہ اس پر بروقت عمل کیا جا سکے۔
ابتدا کے طور پر، واقعات کے سلسلے کا جائزہ لیں اور نشاندہی کریں کہ پروجیکٹ کب غیر یقینی صورتحال سے نکل کر حقیقت کا روپ دھار گیا۔
جب ٹیمیں اس بات پر بحث کرتی ہیں کہ آیا کوئی چیز ٹریکنگ کے قابل خطرہ ہے یا نہیں، تو اکثر ان کی بحث کا اصل موضوع کچھ اور ہوتا ہے۔ وہ دراصل اس بات پر بحث کر رہی ہوتی ہیں کہ پروجیکٹ کی ترجیحات کیا ہیں، کن مفروضوں (assumptions) کو برقرار رکھا جائے گا، اور کن رکاوٹوں (constraints) میں تبدیلی ممکن نہیں۔ اگر یہ امور واضح نہ ہوں، تو خطرے سے متعلق ہر بات چیت کا اختتام محض مبہم مشوروں پر ہوتا ہے، جیسے کہ “اس پر نظر رکھیں۔”
ایک عملی فریم ورک (یا خاکہ) ایک صفحے پر سما سکتا ہے اور اس کا آغاز مقاصد سے ہوتا ہے۔ شیڈول کا مقصد سہ ماہی کے اختتام تک ڈیلیوری ہو سکتا ہے۔ لاگت کا مقصد وینڈر کے مقررہ بجٹ کے اندر رہنا ہو سکتا ہے۔ معیار کا مقصد لانچ کے وقت سیکیورٹی سے متعلق کسی بھی سنگین مسئلے (critical finding) کا نہ ہونا ہو سکتا ہے۔ اس کے بعد آپ ان مفروضوں کی فہرست بناتے ہیں جنہیں آپ منصوبہ بندی کے لیے درست مان رہے ہیں (مثلاً وینڈر کی API کا ‘بیک ورڈ کمپیٹیبل’ رہنا)، اور ان رکاوٹوں کا ذکر کرتے ہیں جن میں کوئی لچک نہیں ہے (مثلاً ریگولیٹری ڈیڈ لائن)۔ پھر آپ خطرے کو قبول کرنے کی حد (risk appetite) کا تعین کرتے ہیں؛ یعنی اسپانسر (سرپرست) تبدیلی یا انحراف کی کتنی مقدار برداشت کرے گا اس سے پہلے کہ وہ معاملے کو اعلیٰ سطح پر لے جانے (escalation) اور حتمی فیصلے کا مطالبہ کرے۔ ‘رسک ایپٹائٹ’ (خطرے کو قبول کرنے کی حد) کا مطلب محض خوش فہمی یا امید پرستی نہیں ہے، بلکہ یہ عمل کے لیے ایک حد مقرر کرتی ہے۔
ایک عام غلطی: اکثر غلط رجحان یہ ہوتا ہے کہ ایک ہی عمومی حد مقرر کر دی جائے، جیسے کہ “ہم کم خطرے والے (low risk) زمرے میں ہیں۔” یہ فیصلہ کن تو محسوس ہوتا ہے، لیکن اس کے نتیجے میں پوشیدہ سمجھوتے (trade-offs) جنم لیتے ہیں؛ مثلاً ٹیم اسپانسر کی منظوری کے بغیر ٹیسٹنگ میں کمی کر کے شیڈول کو بچاتی ہے، یا سیلز ٹیم کو بتائے بغیر تاریخ آگے بڑھا کر معیار کو برقرار رکھتی ہے۔
ایسی حدود کا انتخاب کریں جو پروجیکٹ کے سیاق و سباق سے مطابقت رکھتی ہوں، نہ کہ آپ کی ذاتی ترجیح سے۔