निर्णयों को इस तरह से दस्तावेज़ कैसे करें कि वे वास्तव में टिकें (और फिर से बहस न हों)

ग्यारह महीने पहले आपकी टीम ने तीन बैठकों में यह तय करने में समय बिताया कि इंटीग्रेशन को इन-हाउस बनाना है या खरीदना है। लोग तैयार होकर आए थे। किसी ने एक स्प्रेडशीट बनाई। चर्चा वास्तव में अच्छी थी — चिंताएँ उठाई गईं, समझौते किए गए, एक निर्णय लिया गया। फिर सभी अपने काम पर लौट गए।

इस सप्ताह एक नया इंजीनियरिंग लीड शामिल हुआ, उसने एकीकरण को देखा, और एक उचित सवाल पूछा: "हमने इसे खुद क्यों नहीं बनाया?" और कमरे में मौजूद किसी के लिए ईमानदार जवाब था: कोई भी ठीक से याद नहीं करता। तो सवाल फिर से खुला है। तीन बैठकें फिर से होने वाली हैं — पहली बार की तुलना में कम जानकारी के साथ, क्योंकि जिसने स्प्रेडशीट बनाई थी वह मार्च में चला गया।

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

निर्णय रिकॉर्ड क्या है — और यह पोस्ट क्या कवर करती है

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

यह बैठक के मिनट नहीं हैं — बातचीत का कालानुक्रमिक विवरण — और यह एक कार्य नहीं है। ये भिन्नताएँ इतनी महत्वपूर्ण हैं कि प्रत्येक का अपना पोस्ट है: बैठक के मिनट बनाम निर्णय लॉग दस्तावेज़ स्तर को कवर करता है, और कार्य आइटम बनाम निर्णय कार्य स्तर को कवर करता है। यह पोस्ट वह कैसे करें है जिस पर दोनों वापस इशारा करते हैं।

एक स्कोप नोट: महत्वपूर्ण निर्णय। ऑफसाइट कहां आयोजित करना है, इसका कोई रिकॉर्ड रखने की आवश्यकता नहीं है। कुछ भी जिसे आप छह महीने बाद फिर से बहस करना न चाहें — आर्किटेक्चर, विक्रेता, मूल्य निर्धारण, नीति, भर्ती मानदंड — इसका रिकॉर्ड होना चाहिए। एक उपयोगी परीक्षण: यदि भविष्य का सहयोगी यह पूछ सकता है "यह ऐसा क्यों है?", तो निर्णय योग्य है।

अनिर्धारित निर्णयों की वास्तविक लागत क्या होती है

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

एक और तेज धार भी है: जवाबदेही। जब एक निर्णय केवल स्मृति में होता है, तो इसका इतिहास उस व्यक्ति द्वारा फिर से लिखा जाता है जो इसे बताता है - आमतौर पर अपने ही पक्ष में। एक रिकॉर्ड तर्क को जांचने योग्य बनाता है जब यह महत्वपूर्ण होता है, जो एक वास्तविक निर्णय ऑडिट ट्रेल की नींव है। हमने खुद लागत के बारे में एक संक्षिप्त सहायक लेख लिखा: अदस्तावेज निर्णयों की लागत।

जो ढांचे पहले से मौजूद हैं — और जो अंतर वे छोड़ते हैं

आपको इस प्रथा का आविष्कार करने की आवश्यकता नहीं है; कई गंभीर ढांचे इसे छूते हैं। लेकिन यह देखना फायदेमंद है कि प्रत्येक वास्तव में क्या कवर करता है, क्योंकि सबसे लोकप्रिय ढांचे एक अलग समस्या का समाधान करते हैं जो इस पोस्ट के बारे में है।

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

कैसे कैद करें: सात क्षेत्र

यह Argumentree का अपना टेम्पलेट है — न कि कोई बाहरी मानक, बल्कि एक संश्लेषण जिसे हम उपयोग करते हैं और अनुशंसा करते हैं: ADR की रिकॉर्ड अनुशासन, जिसे उन दो चीजों के साथ विस्तारित किया गया है जिनकी सामान्य टीम निर्णयों को आवश्यकता होती है जो आर्किटेक्चर निर्णयों को मुफ्त में मिलती हैं (एक स्पष्ट मालिक, और एक समीक्षा तिथि)। इसे जैसा है वैसा चुरा लें।

एक रिकॉर्ड जिसे आप कॉपी कर सकते हैं

व्यवहार में, सात क्षेत्रों का आकार आधे पृष्ठ पर आता है। एक कार्यित उदाहरण, संकुचित:

यह पूरा कलाकृति है। अगले वर्ष टीम में शामिल होने वाला कोई भी व्यक्ति इसे चालीस सेकंड में पढ़ता है और जानता है कि क्या तय किया गया, क्या इसे हराया, इसकी लागत क्या थी, और यह कब वापस आएगा। इसे तीन बैठकों के मिनटों के साथ तुलना करें।

जो प्रथाएँ इसे स्थायी बनाती हैं

टेम्पलेट्स असफल नहीं होते; आदतें असफल होती हैं। चार प्रथाएँ उन टीमों को अलग करती हैं जिनके निर्णय लॉग जीवित रहते हैं और उन टीमों को जिनके लॉग दूसरे सप्ताह के बाद मर जाते हैं:

सामान्य गलतियाँ

चार विफलता मोड अधिकांश छोड़े गए निर्णय लॉग के लिए जिम्मेदार हैं:

हम एगाइल हैं — क्या यह सिर्फ दस्तावेज़ी ओवरहेड नहीं है?

आपत्ति का सबसे मजबूत संस्करण सही तरीके से कहने के लायक है: दस्तावेज़ीकरण की एक वास्तविक लागत होती है, अधिकांश दस्तावेज़ कभी नहीं पढ़े जाते, और एक टीम जो अपने काम के बारे में लिखने में अपनी ऊर्जा खर्च करती है, उसने बिना किसी कारण के खुद को धीमा कर लिया है। एगाइल की अंतर्दृष्टि — व्यापक दस्तावेज़ीकरण के मुकाबले कार्यशील सॉफ़्टवेयर — एक वास्तविक बीमारी का सुधार था।

उत्तर यह है कि आपत्ति गलत वस्तु को लक्षित करती है। नायगार्ड ने एडीआर के लिए एगाइल टीमों के लिए, बिल्कुल इसी तर्क पर लिखा: रिकॉर्ड आधे पृष्ठ का है, एक बार लिखा गया, उस क्षण में जब ज्ञान मुक्त है — और इसका पाठक कोई ऑडिटर नहीं बल्कि भविष्य का आप है, जो ग्यारह महीने बाद एकीकरण को देख रहा है और सोच रहा है क्यों। लागत का असममिति अत्यधिक है: निर्णय के समय पांच मिनट बनाम बाद में तीन बैठकें फिर से विवादित करने की। यह दुर्लभ दस्तावेज़ है जो बची हुई बैठकों में अपने लिए भुगतान करता है।

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

कैसे Argumentree दस्तावेज़ स्वचालित रूप से निर्णय लेते हैं

ऊपर दिया गया सब कुछ एक विकी पृष्ठ के साथ काम करता है। हमने Argumentree इसलिए बनाया क्योंकि मैन्युअल रूप से कैप्चर करने के लिए सबसे कठिन क्षेत्र क्षेत्र 3 है — तर्क — क्योंकि ये लाइव, चर्चा में होते हैं, और बाद में उन्हें लिखना याददाश्त से संक्षेप में बताने का मतलब है। Argumentree में स्वयं विचार-विमर्श संरचित होता है: प्रश्न स्पष्ट होता है, विकल्प और उनके पक्ष/विपक्ष के तर्क एक पेड़ का निर्माण करते हैं, और रेटिंग दिखाती है कि कौन से तर्क वास्तव में निर्णय को प्रभावित करते हैं।

जिसका मतलब है कि निर्णय रिकॉर्ड एक ऐसा दस्तावेज़ नहीं है जिसे कोई बैठक के बाद लिखता है — यह बैठक की अपनी संरचना है, जो संरक्षित है। सभी सात क्षेत्र स्वचालित रूप से निकलते हैं: प्रश्न, विकल्प, तर्क, निर्णय, तर्कसंगतता (जीतने वाले तर्क का मार्ग), मालिक, और एक समीक्षा तिथि। कोई ट्रांसक्रिप्शन चरण नहीं, कोई स्मृति भटकाव नहीं, और पूर्ण तर्क हर भविष्य के पाठक के लिए निरीक्षण योग्य रहता है। इसे बैठक बुद्धिमत्ता में अंत से अंत तक देखें। यदि आप इस सप्ताह एक वास्तविक निर्णय पर प्रारूप का प्रयास करना चाहते हैं, तो आप मुफ्त में शुरू कर सकते हैं और इसे बनाते समय अगले को दस्तावेज़ित कर सकते हैं।

निर्णय एक संपत्ति हैं — यदि आप उन्हें बनाए रखते हैं

एक संगठन जो स्मार्ट बनता है और एक जो व्यस्त रहता है, के बीच का अंतर बुद्धिमत्ता नहीं है — यह स्मृति है। कार्य पूरे होते हैं और गायब हो जाते हैं; निर्णय, उनके तर्क के साथ, संचित होते हैं: मिसालें बनती हैं, पैटर्न उभरते हैं, और समीक्षाएँ प्रक्रिया को सुधारने के लिए सिखाती हैं।

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