कब ऑटोमेट न करें: कुछ भी बनाने से पहले मैं जो निर्णय-नियम इस्तेमाल करता हूं

मैंने अब तक जितने ऑटोमेशन चला रहा हूं, उससे ज़्यादा डिलीट कर चुका हूं। खराब होने की वजह से नहीं, बल्कि इसलिए क्योंकि वे बिल्कुल सही काम कर रहे थे और चीज़ों को बदतर बना रहे थे।

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

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

वे मामले जिन्होंने मुझे यह नियम सिखाया

मैंने चार ऐसे ऑटोमेशन बनाए जिन्हें बाद में डिलीट कर दिया। चारों काम कर रहे थे। यहां बताता हूं वे क्या करते थे और क्यों गए।

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

बदला गया: थ्री-टैग एनोटेशन सिस्टम से। मैनुअल। ऑटोमेट नहीं किया जा सकता।

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

बदला गया: किसी चीज़ से नहीं। कुछ फॉलो-अप हाथ से ही लिखने पड़ते हैं।

ब्रीफिंग डाइजेस्ट। पिछले हफ्ते के मेरे नोट्स में महत्वपूर्ण के रूप में टैग की गई हर चीज़ का एक दैनिक डाइजेस्ट। समस्या: दैनिक डाइजेस्ट की आदत ने मुझे इस बारे में कम चयनात्मक बना दिया कि मैं क्या महत्वपूर्ण के रूप में टैग करता हूं। जब कोई सिस्टम सब कुछ इकट्ठा कर लेगा, तो आप कैप्चर करने से पहले यह तय करने का अनुशासन खो देते हैं कि क्या मायने रखता है। डाइजेस्ट ढेर होता गया। संपूर्णता ने चयनात्मकता की जगह ले ली, जबकि चयनात्मकता ही असल मुद्दा थी।

बदला गया: हफ्ते के कच्चे नोट्स की साप्ताहिक पंद्रह मिनट की मैनुअल समीक्षा से। मैं वे तीन चीज़ें चुनता हूं जिन्होंने वाकई कुछ आगे बढ़ाया। यह बंदिश ही असल भार उठाती है।

कॉन्फिडेंस स्कोर। मॉडल से कहा कि वह अपने ही रिसर्च आउटपुट को 1–10 के कॉन्फिडेंस स्केल पर रेट करे। समस्या: संख्याएं गढ़ी हुई थीं। मॉडल ने पैटर्न-मैच किया कि कॉन्फिडेंस स्कोर कैसा दिखता है और प्रशंसनीय संख्याएं बना दीं। मैंने उन पर भरोसा कर लिया। मैंने निर्णय की नकल को ऑटोमेट कर लिया था और उसे निर्णय ही समझ बैठा।

बदला गया: मेरे अपने अनिश्चितता-चिह्नीकरण से। जब मुझे यकीन नहीं होता कि कुछ सही है, तो उससे पहले मैं “CHECK:” लिखता हूं। जब मुझे यकीन होता है, तो मैं दावा लिख देता हूं। यह सिस्टम द्विआधारी और ईमानदार है। इसकी कोई लागत नहीं है।

चारों को इसलिए डिलीट नहीं किया गया कि वे टूट गए थे, बल्कि इसलिए क्योंकि वे उन जगहों पर दक्षता के लिए ऑप्टिमाइज़ कर रहे थे जहां दक्षता सीमित करने वाला कारक थी ही नहीं।

निर्णय-नियम

कोई भी ऑटोमेशन बनाने से पहले मैं एक सवाल चलाता हूं:

इस काम में बाधा समय की है या निर्णय-क्षमता की?

अगर जवाब समय है, तो ऑटोमेशन पर विचार करना उचित है।

अगर जवाब निर्णय-क्षमता है, तो ऑटोमेशन से बचना उचित है, या कम से कम, निर्णय-क्षमता वाला कदम ही वह इकलौती चीज़ होनी चाहिए जिसे ऑटोमेशन न छुए।

इससे तीन उप-जांच निकलती हैं:

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

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

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

यह नियम क्या करने की इजाज़त देता है

स्पष्ट कर दूं: मैं बहुत कुछ ऑटोमेट करता हूं। यह नियम ऐसा संशयवादी नहीं बनाता जो सब कुछ हाथ से करे। यह इस बारे में स्पष्टता देता है कि ऑटोमेशन कहां जाए।

मैं फॉर्मेटिंग और संरचना ऑटोमेट करता हूं। मैं उस सामग्री का संपीड़न ऑटोमेट करता हूं जिसे मैं पहले ही क्यूरेट और एनोटेट कर चुका हूं। मैं रिट्रीवल ऑटोमेट करता हूं: ऐसे सिस्टम बनाना जो मांग पर पिछली सोच सामने लाएं। मैं शेड्यूलिंग और रूटिंग ऑटोमेट करता हूं: किसी भी वर्कफ़्लो की वह प्रशासनिक परत जो पूरी तरह से चीज़ों को एक जगह से दूसरी जगह ले जाने के बारे में है।

मैं किसी भी विषय पर अपनी पहली स्थापना (articulation) ऑटोमेट नहीं करता। मैं रिश्ते-प्रबंधन ऑटोमेट नहीं करता। मैं वह कदम ऑटोमेट नहीं करता जिसमें मुझे तय करना होता है कि क्या मायने रखता है। और मैं ऐसी कोई भी चीज़ ऑटोमेट नहीं करता जिसकी विफलता का तरीका आत्मविश्वास-भरी ग़लती है, क्योंकि वह विफलता तब तक अदृश्य रहती है जब तक वह नहीं रहती।

सवाल कभी यह नहीं होता कि “क्या इसे ऑटोमेट किया जा सकता है?” सवाल यह होता है कि “अगर यह एक प्रशंसनीय गलत जवाब देता है तो असली कीमत क्या है, और किसे पता चलता है?”

जो दस्तावेज़ मैं रखता हूं

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

ऑटोमेट न करने का फैसला उतना ही सोच-समझकर लिया जाना चाहिए जितना ऑटोमेट करने का। इसे जानबूझकर लें, इसे दर्ज करें, और यह एक चूकी हुई संभावना बनना बंद कर देता है। यह नीति बन जाता है।

वह दस्तावेज़, टूल डिसीज़न मैट्रिक्स और डिसीज़न लॉग फॉर्मेट जो मैं इस्तेमाल करता हूं, एक टेम्पलेट के रूप में उपलब्ध है। फॉर्म में तर्क वही है जो मैंने यहां बताया; टेम्पलेट इसे बार-बार इस्तेमाल करने लायक बनाता है।

→ Tool Decision Framework: $39। संरचित निर्णय मैट्रिक्स + निर्णय-लॉग फॉर्मेट। Obsidian या Notion में डाल दें। (पहले न्यूज़लेटर लिस्ट को भेजा जा रहा है; नीचे साइन अप करें।)

चार ऑटोमेशन डिलीट किए गए। हर एक ने वह सिखाया जो “पहले बनाओ” वाला समुदाय खुलकर नहीं कहता: सवाल यह नहीं है कि क्या आप इसे ऑटोमेट कर सकते हैं। सवाल यह है कि दो महीने बाद, क्या आप खुश होंगे कि आपने किया।

Systems में आगे → मैं AI आउटपुट को ईमानदार कैसे रखता हूं: वे जांच जो मैं किसी क्लाइंट के पास कुछ भी जाने से पहले चलाता हूं।