Decision Log: निर्णयों को कैसे रिकॉर्ड करें ताकि उनके कारण सुरक्षित रहें

यदि आप किसी टीम से पूछें कि कोई पॉलिसी क्यों मौजूद है, तो अक्सर आपको एक चुप्पी सुनाई देगी। किसी को कोई मीटिंग याद आती है। किसी और को लगता है कि यह सप्लायर की समस्या थी। जिस व्यक्ति को पता था, वह पिछले साल ही चला गया। निर्णय तो जीवित रहा, लेकिन उसके कारण नहीं रहे।

यह एक सामान्य बात है, और यह महंगी भी पड़ती है। कारणों के बिना, एक टीम के पास दो खराब विकल्प होते हैं: या तो उस निर्णय को बनाए रखें जिसे वे अब नहीं समझते, या उसे उलट दें और उस समस्या को वापस लाने का जोखिम उठाएं जिसे उसने हल किया था। एक decision log तीसरा विकल्प देता है। रिकॉर्ड पढ़ें, जांचें कि क्या स्थितियां अभी भी वैसी ही हैं, और फिर से सोच-समझकर निर्णय लें।

संस्थाएं क्यों भूल जाती हैं कि उन्होंने निर्णय क्यों लिया था

तीन ताकतें एक संस्था की अपने निर्णयों की याददाश्त के खिलाफ काम करती हैं।

• कारण बातचीत में जीवित रहते हैं। निर्णय मीटिंग्स, कॉल्स और मैसेज थ्रेड्स में लिए जाते हैं। परिणाम एक पॉलिसी या प्लान तक पहुँचता है, लेकिन संदर्भ (context) शायद ही कभी पहुँच पाता है।
• लोग बदलते रहते हैं। वे लोग जिन्होंने विकल्पों का मूल्यांकन किया था, वे अपनी भूमिकाएं बदल लेते हैं या चले जाते हैं। उनकी समझ भी उनके साथ चली जाती है।
• स्मृति खुद को फिर से लिखती है। 1975 के एक अध्ययन में, मनोवैज्ञानिक Baruch Fischhoff ने पाया कि एक बार जब लोग परिणाम जान लेते हैं, तो वे उसे पहले की तुलना में अधिक अनुमानित (predictable) मानते हैं। उन्होंने इसे "creeping determinism" कहा। घटना के बाद, एक सही निर्णय जो खराब साबित हुआ, वह लापरवाह लगता है, और एक भाग्यशाली निर्णय बुद्धिमान लगता है।

अंतिम बिंदु सबसे महत्वपूर्ण है। भले ही वही लोग बने रहें, उनके निर्णय लेने के कारण की स्मृति इस बात से प्रभावित होती है कि उसके बाद क्या हुआ। केवल उसी समय लिखा गया रिकॉर्ड ही उस जानकारी को सुरक्षित रख पाता है जो तब ज्ञात थी, जो अपेक्षित थी और जो अनिश्चित थी।

Microsoft का आर्किटेक्चर गाइडेंस इस लागत को स्पष्ट रूप से बताता है। एक निर्णय जिसे कभी रिकॉर्ड नहीं किया जाता, "उसे संभवतः भुला दिया जाएगा, जिससे बार-बार बहस होगी।"

सॉफ्टवेयर टीमों ने क्या सीखा: आर्किटेक्चर डिसीजन रिकॉर्ड (ADR)

सॉफ्टवेयर इंजीनियरिंग के पास एक अच्छी तरह से परखा हुआ उत्तर है। नवंबर 2011 में, Michael Nygard ने आर्किटेक्चर डिसीजन रिकॉर्ड, या ADR का प्रस्ताव रखा: प्रत्येक महत्वपूर्ण निर्णय के लिए एक छोटा दस्तावेज़, जो क्रमवार नंबर वाला हो और प्रोजेक्ट के साथ रखा जाए। उनके फॉर्मेट के पांच भाग हैं।

• Title. एक नंबर के साथ एक छोटा संज्ञा वाक्यांश, जैसे "ADR 9: Multitenant Integration के लिए LDAP।"
• Context. काम में लगी ताकतें: तकनीकी, राजनीतिक, सामाजिक और स्थानीय। Nygard ने कहा कि यह सेक्शन निष्पक्ष होना चाहिए, केवल तथ्यों का विवरण।
• Decision. उन ताकतों के प्रति प्रतिक्रिया, एक्टिव वॉइस में पूर्ण वाक्यों में: "हम करेंगे..."
• Status. Proposed, accepted, deprecated या superseded, किसी भी प्रतिस्थापन (replacement) के संदर्भ के साथ।
• Consequences. परिणामी संदर्भ। Nygard के शब्दों में, "सभी परिणामों को यहाँ सूचीबद्ध किया जाना चाहिए, न कि केवल 'सकारात्मक' परिणामों को।"

यह अभ्यास फैल गया। Thoughtworks ने अपने Technology Radar के Adopt रिंग में हल्के ADRs को रखा, जो सिफारिश का सबसे मजबूत स्तर है, और उन्हें अलग विकी के बजाय सोर्स कंट्रोल में रखने की सलाह दी। Microsoft का Azure Well-Architected Framework निर्णय रिकॉर्ड को एक सॉल्यूशन आर्किटेक्ट के सबसे महत्वपूर्ण डिलिवरेबल्स में से एक कहता है। इसका मार्गदर्शन दो ऐसे नियम जोड़ता है जिन्हें अपनाना चाहिए: लॉग को केवल 'append-only' मानें, और प्रत्येक निर्णय के साथ एक कॉन्फिडेंस लेवल रिकॉर्ड करें।

यह सब केवल सॉफ्टवेयर के लिए विशिष्ट नहीं है। अस्पताल प्रवेश प्रक्रियाओं को बदलते हैं। स्कूल मूल्यांकन नीतियों को बदलते हैं। एजेंसियां सप्लायर बदलती हैं। इन सभी निर्णयों का अपना संदर्भ, विकल्प और परिणाम होते हैं, और प्रत्येक पर बाद में उस व्यक्ति द्वारा सवाल उठाया जाएगा जो उस समय वहां मौजूद नहीं था।

एक निर्णय रिकॉर्ड को क्या कैप्चर करना चाहिए

एक decision log इन सभी रिकॉर्ड्स का संग्रह है, जिसमें एक इंडेक्स होता है जो प्रत्येक का सारांश देता है। Microsoft का इंजीनियरिंग प्लेबुक लॉग को मेटाडेटा के साथ एग्जीक्यूटिव सारांशों की एक टेबल के रूप में वर्णित करता है, जो पूर्ण रिकॉर्ड में रखे गए निर्णयों के लिए है। नीचे दिया गया decision log टेम्पलेट इंजीनियरिंग से कहीं आगे भी बहुत अच्छा काम करता है। प्रत्येक फील्ड का अपना महत्व है।

• ID और title. एक नंबर और एक वाक्यांश जो बताता है कि क्या निर्णय लिया गया था।
• Date. निर्णय कब लिया गया था, न कि वह कब लिखा गया था।
• Owner. निर्णय के लिए जिम्मेदार व्यक्ति, और जिनसे परामर्श किया गया था।
• Context. समस्या, बाधाएं और तनावपूर्ण स्थितियां।
• Options considered. अस्वीकार किए गए विकल्पों सहित, और क्यों। यह वह फील्ड है जो अक्सर गायब होती है और जिसकी सबसे अधिक आवश्यकता होती है।
• Decision. एक स्पष्ट वाक्य जो "हम करेंगे..." से शुरू होता है।
• Evidence. उन डेटा, रिपोर्ट, ऑडिट या फीडबैक के लिंक जिन पर निर्णय आधारित था।
• Expected outcome. यदि निर्णय सफल होता है, तो क्या सच होना चाहिए, और कब तक।
• आत्मविश्वास (Confidence)। उच्च, मध्यम या निम्न, साथ ही एक स्पष्ट रेखा कि क्या अनिश्चित बना हुआ है।
• रिव्यू डेट। वह समय जब निर्णय की उसके अपेक्षित परिणाम के साथ जांच की जाएगी।
• स्टेटस। प्रस्तावित (Proposed), स्वीकृत (Accepted), बदला हुआ (Superseded) या रिटायर (Retired), साथ ही किसी भी रिप्लेसमेंट का लिंक।

अपेक्षित परिणाम और कॉन्फिडेंस फ़ील्ड्स एक डिसीजन जर्नल का काम करते हैं। वे उस चीज़ को रिकॉर्ड करते हैं जो आप परिणाम जानने से पहले मानते थे, और यही वह चीज़ है जिसे 'हाइंडसाइट' (hindsight) मिटा देती है।

हम अपने प्रोडक्ट संबंधी निर्णयों में भी इसी नियम का पालन करते हैं। जो देखा गया है उसे निष्कर्षों से अलग लिखा जाता है, और विरोधाभासी विचारों को मिटाया नहीं जाता, बल्कि उन्हें वैसा ही रखा जाता है। एक निर्णय कम से कम इतनी सावधानी का हकदार है।

प्रत्येक निर्णय को उसके साक्ष्य (evidence) और उसके परिणाम से जोड़ें

एक ऐसा रिकॉर्ड जो अकेला खड़ा हो वह कुछ न होने से बेहतर है। लेकिन एक ऐसा रिकॉर्ड जो लिंक किया गया हो, वह कहीं अधिक उपयोगी है।

साक्ष्य (evidence) से वापस लिंक करें। जब कोई निर्णय किसी पेशेंट सर्वे, लागत विश्लेषण या घटना रिपोर्ट का हवाला देता है, तो सीधे स्रोत को लिंक करें। बाद में पढ़ने वाले लोग यह तय कर पाएंगे कि क्या वह साक्ष्य अब भी मान्य है। Microsoft का मार्गदर्शन भी यही कहता है: बिना औचित्य वाला रिकॉर्ड "समय के साथ अपना मूल्य खो देता है।"

परिणाम से आगे लिंक करें। रिव्यू डेट पर, जो अपेक्षित था उसके साथ लिखें कि वास्तव में आगे क्या हुआ। यदि अंतर बड़ा है, तो पूछें कि क्यों। क्या साक्ष्य कमजोर था? क्या स्थितियां बदल गईं? क्या निर्णय सही था और परिणाम बस दुर्भाग्यपूर्ण था? इसका उत्तर एक सबक है, और यह उसी चेन का हिस्सा होना चाहिए। अगले प्रोजेक्ट को बदलने वाले सीखे गए सबक पर हमारा लेख बताता है कि ऐसे सबक कैसे स्थायी बनाए जाएं।

सक्सेसरों (successors) से लिंक करें। जब किसी निर्णय को उलट दिया जाता है, तो पुराने रिकॉर्ड को एडिट न करें। उसे 'superseded' के रूप में मार्क करें और नए की ओर इशारा करें। दिशा में बदलाव का इतिहास अक्सर लॉग में सबसे मूल्यवान चीज़ होता है।

एक काल्पनिक उदाहरण इस चेन को दर्शाता है। एक क्लिनिक फॉलो-अप कॉल को नर्सों से हटाकर एक समर्पित कोआर्डिनेटर को देने का निर्णय लेता है। रिकॉर्ड कॉल-कम्प्लीशन डेटा का हवाला देता है, ऑपरेशंस मैनेजर को ओनर बताता है, तीन महीने के भीतर कम्प्लीशन बढ़ने की उम्मीद करता है, और एक रिव्यू डेट तय करता है। रिव्यू के समय, कम्प्लीशन तो बढ़ गया है, लेकिन नर्सों का वर्कलोड उम्मीद के मुताबिक कम नहीं हुआ है। एक नया रिकॉर्ड पहले वाले को रिप्लेस (supersede) करता है, भूमिका को एडजस्ट करता है, और उससे वापस लिंक करता है। दो साल बाद, एक नया मैनेजर पूरी कहानी पांच मिनट में पढ़ सकता है।

इसे इतना हल्का रखें कि यह लंबे समय तक चले

डिसीजन लॉग्स उसी तरह विफल होते हैं जैसे अधिकांश डॉक्यूमेंटेशन विफल होते हैं। वे एक बोझ बन जाते हैं, और फिर रुक जाते हैं। पाँच नियम उन्हें जीवित रखते हैं।

• केवल महत्वपूर्ण निर्णय रिकॉर्ड करें। Microsoft का टेस्ट उपयोगी है: वे निर्णय जो संरचना को आकार देते हैं, प्रमुख गुणों को प्रभावित करते हैं, या जिन्हें बदलना कठिन होता है।
• प्रत्येक रिकॉर्ड को छोटा रखें। एक पेज या उससे कम। सामग्री को कॉपी करने के बजाय सहायक सामग्री का लिंक दें।
• जब आप निर्णय लें, तभी लिखें। उसी सप्ताह लिखा गया रिकॉर्ड सटीक होता है। महीनों बाद लिखा गया रिकॉर्ड केवल एक पुनर्निर्माण (reconstruction) है।
• इसे वहीं रखें जहाँ काम हो रहा है। एक लॉग जिसे उन योजनाओं और प्रक्रियाओं के पास रखा जाता है जिन्हें वह प्रभावित करता है, उसे पढ़ा जाता है। एक अलग फ़ोल्डर में रखा गया लॉग नहीं पढ़ा जाता।
• अभी शुरू करें, फिर कुछ पुराने जोड़ें। नए निर्णयों के साथ शुरुआत करें। फिर उन कुछ पिछले निर्णयों को फिर से लिखें जिनके बारे में लोग सबसे अधिक पूछते हैं, और उन्हें 'reconstructed' के रूप में मार्क करें।

बिना कारणों के निर्णय केवल एक निर्देश है। कारणों के साथ लिया गया निर्णय सावधानी से परखा, रखा या बदला जा सकता है।

Prism निर्णय रिकॉर्ड को कैसे सुरक्षित रखता है

Prism किसी संस्था के निर्णयों और ज्ञान को एक घोषित ट्रस्ट लेवल के साथ आइटम के रूप में रखता है: ratifed, evidenced, observed या inferred। प्रत्येक निर्णय अपने साक्ष्य (evidence), उसे लागू करने वाले चरणों, और उसके बाद आने वाले परिणामों और 'Pause and Learn' लेसन्स से लिंक होता है। जब कोई निर्णय बदल दिया जाता है (superseded), तो पिछला निर्णय दिखाई देता रहता है। आपकी टीम जो असिस्टेंट पहले से उपयोग करती है, वे भी रिकॉर्ड पढ़ सकते हैं, ताकि जब कोई पूछे तो कारण वहां मौजूद हों। निर्णय लोग लेते हैं। 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.

कमेंट्स

आपका नामआपकी टिप्पणी

हमारी टीम द्वारा पढ़ने के बाद ही कमेंट्स दिखाई देंगे। कृपया मरीजों या सहकर्मियों का व्यक्तिगत विवरण शामिल न करें।

कमेंट पोस्ट करें