فیصلہ لاگ: فیصلوں کو کیسے ریکارڈ کریں تاکہ ان کی وجوہات محفوظ رہیں

اگر آپ کسی ٹیم سے پوچھیں کہ کوئی پالیسی کیوں موجود ہے، تو اکثر آپ کو خاموشی ملے گی۔ کوئی میٹنگ یاد کرتا ہے۔ کوئی دوسرا سوچتا ہے کہ یہ سپلائر کا مسئلہ تھا۔ جس شخص کو معلوم تھا وہ پچھلے سال چھوڑ گیا۔ فیصلہ تو برقرار رہا، لیکن اس کی وجوہات نہیں۔

یہ ایک عام بات ہے، اور یہ مہنگی پڑتی ہے۔ وجوہات کے بغیر، ایک ٹیم کے پاس دو ناقص آپشنز ہوتے ہیں: یا تو ایسے فیصلے پر عمل جاری رکھیں جسے وہ اب سمجھتی نہیں، یا اسے منسوخ کر دیں اور اس مسئلے کے دوبارہ پیدا ہونے کا خطرہ مول لیں جسے اس نے حل کیا تھا۔ ایک فیصلہ لاگ تیسرا راستہ فراہم کرتا ہے۔ ریکارڈ پڑھیں، چیک کریں کہ کیا حالات اب بھی وہی ہیں، اور پھر مقصد کے ساتھ دوبارہ فیصلہ کریں۔

ادارے کیوں بھول جاتے ہیں کہ انہوں نے فیصلہ کیوں کیا تھا

تین قوتیں کسی ادارے کی اپنے فیصلوں کی یادداشت کے خلاف کام کرتی ہیں۔

• وجوہات گفتگو میں زندہ رہتی ہیں۔ فیصلے میٹنگز، کالز اور میسجز کے ذریعے کیے جاتے ہیں۔ نتیجہ ایک پالیسی یا منصوبے کی شکل اختیار کر لیتا ہے، لیکن سیاق و سباق شاذ و نادر ہی وہاں تک پہنچ پاتا ہے۔
• لوگ تبدیل ہوتے ہیں۔ وہ لوگ جنہوں نے اختیارات کا جائزہ لیا، وہ عہدے بدل لیتے ہیں یا ادارے چھوڑ دیتے ہیں۔ ان کی سمجھ بوجھ بھی ان کے ساتھ چلی جاتی ہے۔
• یادداشت خود کو دوبارہ لکھتی ہے۔ 1975 کے ایک مطالعے میں، ماہر نفسیات Baruch Fischhoff نے پایا کہ ایک بار جب لوگ نتیجہ جان لیتے ہیں، تو وہ اسے اس سے کہیں زیادہ قابلِ پیش گوئی سمجھتے ہیں جتنا وہ حقیقت میں تھا۔ انہوں نے اسے "creeping determinism" کا نام دیا۔ حقیقت سامنے آنے کے بعد، ایک درست فیصلہ جو برا ثابت ہوا، وہ لاپرواہی لگتا ہے، اور ایک خوش قسمتی والا فیصلہ دانشمندانہ لگتا ہے۔

آخری نکتہ سب سے اہم ہے۔ یہاں تک کہ جب وہی لوگ موجود رہیں، تب بھی ان کی یہ یادداشت کہ انہوں نے فیصلہ کیوں کیا تھا، اس بات سے متاثر ہوتی ہے کہ اس کے بعد کیا ہوا۔ صرف وہی ریکارڈ جو اسی وقت لکھا گیا ہو، اس معلومات کو محفوظ رکھتا ہے جو معلوم تھی، جس کی توقع کی گئی تھی اور جو غیر یقینی تھی۔

Microsoft کی آرکیٹیکچر گائیڈنس اس قیمت کو واضح طور پر بیان کرتی ہے۔ ایک فیصلہ جسے کبھی ریکارڈ نہ کیا جائے "ممکنہ طور پر بھول جایا جائے گا، جس سے بار بار بحث و تکرار ہوگی۔"

سافٹ ویئر ٹیموں نے کیا سیکھا: آرکیٹیکچر فیصلہ ریکارڈ (ADR)

سافٹ ویئر انجینئرنگ کے پاس اس کا ایک آزمودہ جواب ہے۔ نومبر 2011 میں، Michael Nygard نے آرکیٹیکچر فیصلہ ریکارڈ، یا ADR تجویز کیا: ہر اہم فیصلے کے لیے ایک مختصر دستاویز، جو ترتیب وار نمبروں کے ساتھ ہو اور پروجیکٹ کے ساتھ ہی رکھی جائے۔ اس کے فارمیٹ کے پانچ حصے ہیں۔

• عنوان۔ ایک نمبر کے ساتھ مختصر اسم، جیسے "ADR 9: Multitenant Integration کے لیے LDAP"۔
• سیاق و سباق۔ کام میں لگی ہوئی قوتیں: تکنیکی، سیاسی، سماجی اور مقامی۔ Nygard نے کہا کہ یہ حصہ غیر جانبدار ہونا چاہیے، یعنی صرف حقائق کی وضاحت۔
• فیصلہ۔ ان قوتوں کا جواب، جو مکمل جملوں اور ایکٹو وائس میں ہو: "ہم کریں گے..."
• صورتحال۔ مجوزہ (Proposed)، قبول شدہ (Accepted)، متروک (Deprecated) یا متبادل کے ذریعے تبدیل شدہ (Superseded)، کسی بھی متبادل کے حوالے کے ساتھ۔
• نتائج۔ نتیجے کے طور پر پیدا ہونے والا سیاق و سباق۔ Nygard کے الفاظ میں، "تمام نتائج یہاں درج ہونے چاہئیں، نہ کہ صرف 'مثبت' والے"۔

یہ طریقہ کار پھیل گیا۔ Thoughtworks نے اپنے Technology Radar کے Adopt ring میں ہلکے پھلکے ADRs کو رکھا، جو کہ اس کی سفارش کا مضبوط ترین درجہ ہے، اور مشورہ دیا کہ انہیں الگ ویکی کے بجائے سورس کنٹرول میں رکھا جائے۔ Microsoft کا Azure Well-Architected Framework فیصلے کے ریکارڈ کو ایک سالاتی ماہر (solution architect) کے اہم ترین کاموں میں سے ایک قرار دیتا ہے۔ اس کی گائیڈنس میں دو ایسے اصول ہیں جو اپنانے کے قابل ہیں: لاگ کو صرف اضافہ کرنے کے لیے (append-only) استعمال کریں، اور ہر فیصلے کے ساتھ اعتماد کی سطح (confidence level) ریکارڈ کریں۔

یہ سب صرف سافٹ ویئر تک محدود نہیں ہے۔ ہسپتال داخلے کے طریقہ کار بدلتے ہیں۔ اسکول اسیسمنٹ کی پالیسیاں بدلتے ہیں۔ ایجنسیاں سپلائرز بدلتی ہیں۔ ان میں سے ہر فیصلے کا ایک سیاق و سباق، اختیارات اور نتائج ہوتے ہیں، اور ہر فیصلے پر بعد میں اس شخص کی جانب سے سوال اٹھایا جائے گا جو اس وقت وہاں موجود نہیں تھا۔

ایک فیصلہ ریکارڈ میں کیا شامل ہونا چاہیے

فیصلہ لاگ ان ریکارڈز کا مجموعہ ہے، جس میں ایک انڈیکس ہوتا ہے جو ہر ایک کا خلاصہ کرتا ہے۔ Microsoft کی انجینئرنگ پلے بک لاگ کو ایگزیکٹو سمریز کے ایک ٹیبل کے طور پر بیان کرتی ہے، جس میں مکمل ریکارڈز میں موجود فیصلوں کے لیے میٹا ڈیٹا بھی شامل ہوتا ہے۔ نیچے دیا گیا فیصلہ لاگ ٹیمپلیٹ انجینئرنگ سے کہیں آگے تک کام کرتا ہے۔ ہر فیلڈ اپنی اہمیت رکھتی ہے۔

• ID اور عنوان۔ ایک نمبر اور ایک جملہ جو بتائے کہ کیا فیصلہ کیا گیا۔
• تاریخ۔ جب فیصلہ کیا گیا، نہ کہ جب اسے لکھا گیا۔
• ذمہ دار۔ وہ شخص جو فیصلے کا جوابدہ ہے، اور جن سے مشورہ کیا گیا۔
• سیاق و سباق۔ مسئلہ، رکاوٹیں اور آپس میں ٹکراتی ہوئی قوتیں۔
• غور کیے گئے اختیارات۔ ان میں وہ بھی شامل ہیں جنہیں مسترد کر دیا گیا، اور کیوں۔ یہ وہ فیلڈ ہے جو اکثر غائب ہوتی ہے اور جس کی سب سے زیادہ ضرورت ہوتی ہے۔
• فیصلہ۔ ایک واضح جملہ جو "ہم کریں گے..." سے شروع ہو۔
• شواہد۔ ڈیٹا، رپورٹس، آڈٹ یا فیڈ بیک کے لنکس جن پر فیصلہ مبنی تھا۔
• متوقع نتیجہ۔ اگر فیصلہ کامیاب رہا تو کیا حقیقت ہونا چاہیے، اور کب تک۔
• اعتماد۔ زیادہ، درمیانہ یا کم، اس تفصیل کے ساتھ کہ کیا چیز غیر یقینی ہے۔
• ریویو کی تاریخ۔ جب فیصلے کا اس کے متوقع نتیجے کے ساتھ موازنہ کیا جائے گا۔
• اسٹیٹس۔ مجوزہ، قبول شدہ، تبدیل شدہ یا منسوخ، کسی بھی متبادل کے لنک کے ساتھ۔

متوقع نتیجہ اور اعتماد کے فیلڈز ایک decision Journal کا کام کرتے ہیں۔ یہ اس بات کو ریکارڈ کرتے ہیں کہ نتیجہ معلوم ہونے سے پہلے آپ کا کیا خیال تھا، جو کہ بالکل وہی چیز ہے جسے hindsight مٹا دیتی ہے۔

ہم اپنے پروڈکٹ کے فیصلوں میں بھی اسی اصول پر عمل کرتے ہیں۔ جو کچھ مشاہدہ کیا گیا اسے اخذ کردہ نتائج سے الگ لکھا جاتا ہے، اور متضاد آراء کو دبانے کے بجائے انہیں برقرار رکھا جاتا ہے۔ ایک فیصلے کے لیے کم از کم اتنی توجہ تو لازمی ہے۔

ہر فیصلے کو اس کے شواہد اور اس کے نتیجے سے جوڑیں۔

ایک ایسا ریکارڈ جو اکیلا کھڑا ہو وہ کچھ نہ ہونے سے بہتر ہے۔ لیکن ایک ایسا ریکارڈ جو لنک شدہ ہو، وہ کہیں زیادہ مفید ہے۔

شواہد سے دوبارہ لنک کریں۔ جب کوئی فیصلہ مریض کے سروے، لاگت کے تجزیے یا کسی واقعے کی رپورٹ کا حوالہ دے، تو خود اس کے ذریعے (source) کو لنک کریں۔ بعد میں پڑھنے والے اس بات کا فیصلہ کر سکیں گے کہ آیا وہ شواہد اب بھی درست ہیں۔ Microsoft کی رہنمائی بھی یہی کہتی ہے: جواز کے بغیر ریکارڈ "وقت کے ساتھ اپنی اہمیت کھو دیتا ہے"۔

نتیجے کے ساتھ آگے لنک کریں۔ ریویو کی تاریخ پر، جو توقع کی گئی تھی اس کے ساتھ یہ بھی لکھیں کہ حقیقت میں کیا ہوا۔ اگر فرق بڑا ہے، تو پوچھیں کہ کیوں؟ کیا شواہد کمزور تھے؟ کیا حالات بدل گئے تھے؟ کیا فیصلہ درست تھا اور نتیجہ محض بدقسمتی تھی؟ اس کا جواب ایک سبق ہے، اور اسے اسی سلسلے کا حصہ ہونا چاہیے۔ سبق آموز تجربات جو اگلے پروجیکٹ کو بدل دیتے ہیں پر ہمارا مضمون بتاتا ہے کہ ایسے اسباق کو کیسے برقرار رکھا جائے۔

متبادل فیصلوں سے لنک کریں۔ جب کسی فیصلے کو واپس لیا جائے، تو پرانے ریکارڈ میں ترمیم نہ کریں۔ اسے 'superseded' کے طور پر نشان زد کریں اور نئے فیصلے کی طرف اشارہ کریں۔ سمت کی تبدیلی کی تاریخ اکثر لاگ میں سب سے قیمتی چیز ہوتی ہے۔

ایک فرضی مثال اس سلسلے کو واضح کرتی ہے۔ ایک کلینک فیصلہ کرتا ہے کہ فالو اپ کالز نرسوں سے ہٹا کر ایک مخصوص کوآرڈینیٹر کو دے دی جائیں۔ ریکارڈ کال مکمل ہونے کے ڈیٹا کا حوالہ دیتا ہے، آپریشنز مینیجر کو ذمہ دار قرار دیتا ہے، تین ماہ کے اندر تکمیل میں اضافے کی توقع کرتا ہے، اور ریویو کی تاریخ مقرر کرتا ہے۔ ریویو کے وقت، تکمیل میں اضافہ تو ہوا ہے، لیکن نرسوں کے کام کا بوجھ توقع کے مطابق کم نہیں ہوا۔ ایک نیا ریکارڈ پہلے والے کو تبدیل (supersede) کرتا ہے، کردار کو ایڈجسٹ کرتا ہے، اور اس سے دوبارہ لنک کرتا ہے۔ دو سال بعد، ایک نیا مینیجر پانچ منٹ میں پوری کہانی پڑھ سکتا ہے۔

اسے اتنا ہلکا رکھیں کہ یہ برقرار رہے

ڈیسن لاگز اسی طرح ناکام ہوتے ہیں جیسے زیادہ تر دستاویزات ہوتی ہیں۔ یہ ایک بوجھ بن جاتے ہیں، اور پھر رک جاتے ہیں۔ پانچ اصول انہیں زندہ رکھتے ہیں۔

• صرف اہم فیصلے ریکارڈ کریں۔ Microsoft کا معیار مفید ہے: وہ فیصلے جو ڈھانچے کو تشکیل دیتے ہیں، اہم خصوصیات پر اثر انداز ہوتے ہیں، یا جنہیں واپس لینا مشکل ہو۔
• ہر ریکارڈ کو مختصر رکھیں۔ ایک صفحہ یا اس سے کم۔ مواد کی کاپی کرنے کے بجائے معاون مواد کا لنک دیں۔
• فیصلہ کرتے وقت ہی لکھ لیں۔ اسی ہفتے لکھا گیا ریکارڈ درست ہوتا ہے۔ مہینوں بعد لکھا گیا ریکارڈ محض ایک دوبارہ بنائی گئی یادداشت ہے۔
• اسے وہیں رکھیں جہاں کام ہو رہا ہو۔ ایک لاگ جو ان منصوبوں اور طریقہ کار کے ساتھ رکھا جائے جن پر اس کا اثر پڑتا ہے، اسے پڑھا جاتا ہے۔ الگ فولڈر میں رکھا گیا لاگ نہیں پڑھا جاتا۔
• ابھی سے شروع کریں، پھر کچھ پرانے شامل کریں۔ نئے فیصلوں سے آغاز کریں۔ پھر ماضی کے چند ایسے فیصلے دوبارہ ترتیب دیں جن کے بارے میں لوگ سب سے زیادہ پوچھتے ہیں، اور انہیں 'reconstructed' کے طور پر نشان زد کریں۔

وجوہات کے بغیر فیصلہ محض ایک ہدایت ہے۔ وجوہات کے ساتھ فیصلہ کیا جا سکتا ہے، اسے برقرار رکھا جا سکتا ہے یا احتیاط سے بدلا جا سکتا ہے۔

Prism کس طرح فیصلوں کے ریکارڈ کو محفوظ رکھتا ہے

Prism کسی ادارے کے فیصلوں اور علم کو ایک بیان کردہ اعتماد کی سطح کے ساتھ آئٹمز کے طور پر محفوظ کرتا ہے: تصدیق شدہ، شواہد کے ساتھ، مشاہدہ شدہ یا اندازہ شدہ۔ ہر فیصلہ اپنے شواہد، اسے نافذ کرنے والے اقدامات، اور اس کے نتیجے اور 'Pause and Learn' کے اسباق سے لنک ہوتا ہے۔ جب کوئی فیصلہ تبدیل (supersede) کیا جاتا ہے، تو پرانا فیصلہ نظر آتا رہتا ہے۔ آپ کی ٹیم جو اسسٹنٹس پہلے سے استعمال کر رہی ہے وہ بھی ریکارڈ پڑھ سکتے ہیں، تاکہ جب کوئی پوچھے تو وجوہات موجود ہوں۔ فیصلے لوگ کرتے ہیں۔ Prism ان کی وجوہات محفوظ رکھتا ہے۔

ذرائع

1. Architecture Decisions کی دستاویز سازی۔ Michael Nygard, Relevance (اب Cognitect) بلاگ، 2011۔
2. Architecture decision record (Azure Well-Architected Framework)۔ Microsoft Learn, 2024۔
3. Decision Log (Code-With Engineering Playbook)۔ Microsoft, 2024۔
4. Lightweight Architecture Decision Records (Technology Radar)۔ Thoughtworks, 2018۔
5. Hindsight ≠ foresight: The effect of outcome knowledge on judgment under uncertainty۔ Journal of Experimental Psychology: Human Perception and Performance 1(3) (B. Fischhoff), 1975۔

تبصرے

آپ کا نامآپ کا تبصرہ

تبصرے ہماری ٹیم کی ریڈنگ کے بعد ظاہر ہوں گے۔ براہ کرم مریضوں یا ساتھیوں کی ذاتی تفصیلات شامل نہ کریں۔

تبصرہ پوسٹ کریں