5 टूल्स वाली टीम में निर्णय कैसे ट्रैक करें
टूल्स में बिखरे निर्णय कैसे ट्रैक करें – Slack, Notion, Linear और PR रिव्यू में – और क्यों निर्णय लॉग काम नहीं आते।
By Chris Calo · 2026-03-13
"क्या हमने यह पहले ही तय नहीं किया था?"
कॉल पर पाँच लोग। कोई जवाब नहीं देता। कोई अनम्यूट करके कहता है कि उसे लगता है यह किसी Slack थ्रेड में आया था – शायद तीन हफ्ते पहले, संभवतः #engineering में, लेकिन #backend भी हो सकता है। हमारी डिज़ाइनर को Notion के एक कमेंट की अधूरी याद है। हमारे एक इंजीनियर ने Linear में स्क्रॉल करना शुरू कर दिया है – उस इश्यू पर कोई कमेंट ढूँढ रहे हैं जो शायद बंद हो चुका है। या आर्काइव हो गया। या किसी दूसरे प्रोजेक्ट में चला गया।
जिस निर्णय की बात है: हम आगे कौन सा API वर्ज़निंग स्कीम इस्तेमाल करेंगे। कोई कंपनी-दाँव पर लगाने वाला फैसला नहीं। कोई आर्किटेक्चरल खाई नहीं। बस एक सीधा सवाल – टूल्स में निर्णय कैसे ट्रैक करें – या अधिक सटीक रूप से, एक ऐसा निर्णय कैसे खोजें जो निश्चित रूप से, साबित तरीके से, पहले ही लिया जा चुका था, और जो अब पाँच ऐसे टूल्स के बीच की खाई में गायब हो गया था जो आपस में बात नहीं करते।
आइए अपराध स्थल की पुनर्रचना करते हैं।
एक खोए हुए निर्णय की फोरेंसिक टाइमलाइन
यह असल में क्या हुआ था, बाद में जोड़कर समझा (क्योंकि मैंने अंततः सब ढूँढ ही लिया – इसमें करीब एक घंटा लगा, जो एक बुधवार दोपहर का उत्पादक उपयोग लगा)।
दिन 1, सुबह 10:14 – हमारे एक इंजीनियर ने #engineering में "API वर्ज़निंग ऑप्शन्स" शीर्षक का Notion डॉक शेयर किया। तीन विकल्प, हर एक के फायदे-नुकसान। साफ फॉर्मेटिंग। अच्छी सोच। ऐसा डॉक्युमेंट जिसे देखकर लगता है कि टीम सब सँभाल लेगी।
दिन 1, सुबह 10:22 – शेयर किए गए लिंक के नीचे Slack थ्रेड में चर्चा शुरू हुई। पहले बीस मिनट में छह जवाब। बैकवर्ड कम्पेटिबिलिटी, क्लाइंट SDK के असर, और हेडर-बेस्ड वर्ज़निंग की डीबगिंग तकलीफ पर असली, उपयोगी बातचीत। और चौथे जवाब के आसपास दोपहर के खाने की जगह पर एक छोटी सी भटकान भी – जो, सच में, वर्ज़निंग बहस से ज्यादा जल्दी सहमति पर पहुँची।
दिन 1, सुबह 11:47 – हमारी डिज़ाइनर, जो अब तक देख रही थीं, ने एक लाइन लिखी: "पाथ वर्ज़निंग API एक्सप्लोरर को पठनीय रखती है, बस /v2/ कर लेते हैं।" दो थम्ब्स-अप रिएक्शन। कोई असहमति नहीं। निर्णय हो गया।
दिन 1, दोपहर 2:30 – एक टीममेट ने API रिफैक्टर इश्यू पर Linear कमेंट में नतीजा सारांशित किया। अच्छी सूझ। पर ढूँढना नामुमकिन – जैसा बाद में पता चला, क्योंकि बंद इश्यू पर Linear कमेंट व्यावहारिक रूप से अदृश्य हो जाते हैं।
दिन 8 – /v2/ लागू करने वाला PR मर्ज हुआ। PR डिस्क्रिप्शन में Linear इश्यू का नंबर था, लेकिन वर्ज़निंग निर्णय के बारे में या उस Slack थ्रेड के बारे में कुछ नहीं जहाँ यह असल में तय हुआ था। बिल्कुल सामान्य। PR डिस्क्रिप्शन में कोई नहीं लिखता "वैसे, इस निर्णय की पूरी वंशावली यहाँ है", क्योंकि कोई पागल नहीं है।
दिन 43 – कोई नया व्यक्ति एक संबंधित टिकट उठाता है और पूछता है: "हम पाथ वर्ज़निंग कर रहे हैं या हेडर वर्ज़निंग?" Notion डॉक? नतीजे से कभी अपडेट नहीं हुआ। Slack थ्रेड? छह हफ्तों के मैसेज के नीचे दबा। Linear कमेंट? बंद इश्यू पर जिसे कोई खोजने के बारे में सोचता भी नहीं। PR? उसे ढूँढने के लिए पहले पता होना चाहिए कि वह है।
और इस तरह पाँच लोग कॉल पर बैठे एक-दूसरे को देखते हुए वह निर्णय फिर से निकाल रहे हैं जो छह हफ्ते पहले ही हो चुका था। प्रगति।
title: "एक निर्णय, छह हफ्ते, पाँच टूल" दिन 1, 10:14|ok|Notion doc "API Versioning Options" #engineering में शेयर; तीन विकल्प सूचीबद्ध दिन 1, 10:22|ok|Slack चर्चा शुरू; बैकवर्ड कम्पेटिबिलिटी और SDK पर उत्पादक बहस दिन 1, 11:47|ok|निर्णय लिया: पाथ वर्ज़निंग, /v2/ दिन 1, 14:30|amber|नतीजा Linear कमेंट में सारांशित; बंद इश्यू = खराब खोज योग्यता दिन 8|amber|PR /v2/ मर्ज हुआ; विवरण इश्यू का संदर्भ देता है, निर्णय का नहीं दिन 43|missed|नया डेवलपर पूछता है: "पाथ या हेडर?" – जवाब मौजूद है; कोई नहीं ढूँढ पाता
जहाँ निर्णय मरने जाते हैं
बात यह है कि इनमें से कोई भी टूल विफल नहीं हुआ। Slack ने वही किया जो Slack करता है। Notion ने डॉक्युमेंट बखूबी रखा। Linear ने इश्यू ट्रैक किया। GitHub ने कोड मर्ज किया। हर टूल ने अलगाव में परफेक्ट काम किया – जो तारीफ जैसा लगता है जब तक यह एहसास न हो कि यही असल में डायग्नोसिस है।
| कहाँ हुआ | बाद में क्यों नहीं मिलता | |---|---| | Slack थ्रेड | छह हफ्ते पहले किसी ने जो शब्द इस्तेमाल किए, वे याद रखने होंगे। शुभकामनाएँ। | | Linear कमेंट | बंद इश्यू पर कमेंट समुद्र तल पर उकेरे हों तो भी उतने ही मिलेंगे | | Notion डॉक | डॉक है, पर नतीजे से किसी ने अपडेट नहीं किया – क्योंकि इंसान हैं | | GitHub PR | मर्ज के बाद बातचीत धुंधली पड़ जाती है – कौन सा PR खोदना है यह पहले पता हो | | मीटिंग (मौखिक) | पूरी तरह गायब, जब तक किसी ने नोट्स लिए हों और कहीं ढूँढने लायक रखे हों | | ईमेल थ्रेड | ठीक-ठाक सर्च, पर सिर्फ तभी जब आप सही चेन पर थे |
छह टूल। छह सर्च इंजन। शून्य साझा स्मृति।
हर टूल ने अलगाव में परफेक्ट काम किया – जो तारीफ जैसा लगता है जब तक यह एहसास न हो कि यही असल में डायग्नोसिस है। attribution: Chris Calo
निर्णय लॉग: एक सुंदर लाश
अगर आप सिर भी हिलाते रहे, तो शायद आपके मन में भी वह इच्छा आई होगी। जिसमें लगता है: "ठीक है, मैं एक निर्णय लॉग बनाऊँगा।" बड़े अक्षरों में। एक खूबसूरत Notion डेटाबेस जिसमें तारीख, निर्णय, संदर्भ, हितधारक और स्टेटस के कॉलम हों। आप टीम चैनल में घोषणा करते हैं। खुद तीन एंट्री मेहनत से भरते हैं – और यह वाकई अच्छा लगता है।
मैं तीन कंपनियों में यही चीज़ बना चुका हूँ (और हाँ, मुझे पता है कि एक ही विफल प्रयोग को दोहराकर अलग नतीजे की उम्मीद रखने का एक क्लिनिकल नाम है)। हर बार मुझे पूरा यकीन था कि यह चलेगा। "इस बार हम अनुशासित रहेंगे!" नहीं रहे। आप भी नहीं रहेंगे। यह मैं क्रूरता से नहीं कह रहा – बल्कि इसलिए कह रहा हूँ क्योंकि विफलता का तरीका डिज़ाइन में ही बुना हुआ है।
यह होता है क्या। पहला हफ्ता: शानदार। दूसरा हफ्ता: काफी हद तक भरा। तीसरा हफ्ता: कोई एक Slack DM में जल्दी से कोई निर्णय ले लेता है – लॉग को पता भी नहीं चलता। चौथा हफ्ता: एक PR रिव्यू कमेंट में दबी एक अंतर्निहित आर्किटेक्चरल डिसीज़न के साथ मर्ज हो जाता है – किसी को ट्रांसक्राइब करने की नहीं सूझती। पाँचवाँ हफ्ता: कोई छुट्टी पर है, बाकी टीम दोपहर के खाने पर कुछ तय कर लेती है (खाने का भटकाव फिर आ जाता है), और लॉग चुप हो जाता है।
छठे हफ्ते तक आपका निर्णय लॉग एक स्मारक बन चुका होता है। अच्छे इरादों को समर्पित एक सुरुचिपूर्ण स्मृति-चिह्न, आपके Notion साइडबार में बैठा, अनछुआ, डिजिटल धूल जमा करता हुआ। मेरे पास तीन हैं। वे सुंदर हैं। वे पूरी तरह बेकार भी हैं।
निर्णय लॉग इसलिए विफल नहीं होते क्योंकि टीमें अनुशासनहीन हैं, बल्कि इसलिए क्योंकि वे लोगों से माँगते हैं कि किसी पल को अहम पहचानें जब वह हो रहा हो, रुकें, डॉक्युमेंटेशन टूल पर कॉन्टेक्स्ट स्विचिंग करें, और इतनी जानकारी के साथ लिखें कि छह हफ्ते बाद काम आए। असली काम में व्यस्त लोगों से यह माँगना बेतुका है।
टूल्स में निर्णय ट्रैक करने का असली तरीका
मैन्युअल लॉग मानव स्वभाव के कारण विफल होते हैं। टूल-दर-टूल सर्च बिखराव के कारण विफल होती है। जो असल में काम करता है वह यह है कि आपके सभी टूल्स की पूरी सतह पर नज़र रखे और बिना किसी को रोके बिंदु जोड़े।
व्यवहार में, इसके चार हिस्से हैं:
स्वचालित इनजेस्शन। आपके टूल्स से हर सिग्नल – Slack मैसेज, Linear कमेंट, PR रिव्यू, Notion अपडेट, मीटिंग ट्रांसक्रिप्ट – बिना किसी की उँगली हिलाए कैप्चर हो जाता है। आप काम करते रहते हैं। सिस्टम देखता रहता है। किसी को सोच के बीच में रुककर स्प्रेडशीट खोलकर यह दर्ज नहीं करना पड़ता कि अभी क्या हुआ (जो, जैसा हमने स्थापित किया है, वैसे भी कोई नहीं करता)।
वर्गीकरण। हर मैसेज निर्णय नहीं होता। ज्यादातर स्टेटस अपडेट, सवाल या शोर होते हैं। सिस्टम को "पाथ या हेडर वर्ज़निंग करें?" (सवाल), "बस /v2/ कर लेते हैं" (निर्णय), और "/v2/ एंडपॉइंट डिप्लॉय हो गया" (स्टेटस अपडेट) में फर्क करना होगा। यहाँ एक LLM क्लासिफायर अपनी जगह बनाता है – हालाँकि वह अचूक नहीं है। एक बार हुआ था कि "हाँ, यही कर लेते हैं" को बार-बार बड़ा निर्णय मान लिया गया जबकि कोई बस कॉफी लाने के लिए राज़ी हुआ था। पता चला कि कॉन्फिडेंस स्कोर सही करने के लिए टेम्पोरल संदर्भ और सेंडर-रोल वेटिंग चाहिए।
लिंकिंग। यही वह हिस्सा है जो "बेहतर सर्च" को असली निर्णय ट्रैकिंग से अलग करता है। जब Slack थ्रेड का निर्णय किसी Linear इश्यू से जुड़ा हो जिसने GitHub PR बनाया – ये कनेक्शन सिस्टम द्वारा रेफरेंस (इश्यू IDs, PR नंबर, थ्रेड URLs, समय की निकटता) ट्रेस करने से होने चाहिए, किसी के हाथ से बनाने से नहीं। Notion डॉक, Slack थ्रेड, Linear कमेंट और PR सब अपने आप एक-दूसरे को पॉइंट करें – क्योंकि ऐसा ही हुआ था।
रिट्रीवल। जब आप "API वर्ज़निंग निर्णय" खोजते हैं, तो पूरी चेन मिलती है – सिर्फ वह टूल नहीं जो आपने पहले खोजा। Notion डॉक विकल्पों के साथ, Slack थ्रेड जहाँ फैसला हुआ, Linear कमेंट जिसने सारांश दिया, और PR जिसने लागू किया। सब जुड़े हुए। किसी ने एक भी लॉग एंट्री भरे बिना।
दो चीज़ें जो आप अभी आज़मा सकते हैं (सच में, बिना किसी शर्त के):
#decisions चैनल। Slack में एक बनाएँ और टीम से कहें कि जब भी कहीं कुछ तय हो, वहाँ एक लाइन डाल दें। यह मैन्युअल है और एक महीने में बिखर जाएगा (मैंने इस पर अपनी साख स्थापित कर ली है), पर एक अधूरा, बिखरता लॉग भी बिखरी संवाद व्यवस्था के पैटर्न को दर्दनाक रूप से उजागर करता है।
- PR डिस्क्रिप्शन की आदत। जब कोई ऐसा PR खोलें जो किसी निर्णय को लागू करता हो, तो डिस्क्रिप्शन में एक लाइन जोड़ें: "निर्णय: [क्या तय हुआ] – देखें [थ्रेड/डॉक का लिंक]।" दस सेकंड लगते हैं, कोड रिव्यू के बाद भी रहता है, और भविष्य में आपको कुछ खोजने लायक देता है। Slack DM या दोपहर के खाने पर हुए निर्णय नहीं पकड़ेगा, लेकिन जो पकड़ेगा वे सबसे अहम हैं – जो कोडबेस बदलते हैं।
कनेक्टेड निर्णय ट्रैकिंग से असल में क्या बदलता है
पुरातत्व एक क्वेरी बन जाती है। शुरुआत में वह वर्ज़निंग खोज? क्रॉस-टूल इंडेक्सिंग से यह पाँच सेकंड की सर्च बन जाती है जो चेन का हर आर्टिफैक्ट लिंक के साथ लौटाती है। जिससे मेरा एक शर्मनाक बुधवार दोपहर बच जाता। This is what visibility across your engineering tools actually means in practice. It’s closely related to a semantic approach to finding past Slack decisions and a connected view of tasks that span three or more tools – all three problems stem from the same fragmented-tools root cause.
ऑनबोर्डिंग संदर्भ जो पुराना नहीं पड़ता। नए टीम मेंबर्स को चीज़ें जैसी हैं वैसी क्यों हैं – उसकी जुड़ी हुई चेन मिलती है – न कि तीन महीने पहले अपडेट हुए किसी विकी पेज जिसके बारे में सब जानते हैं कि गलत है लेकिन कोई ठीक करने की जहमत नहीं उठाता। (आपके पास ऐसा एक है। सबके पास है।)
वही बहस कम दोहराई जाती है। यह मुझे हैरान करने वाला था। एक बार निर्णय ढूँढने लायक हो जाएँ, "क्या हमने यह पहले ही तय नहीं किया था?" का जवाब सेकंडों में मिल जाता है – दस मिनट की उस ग्रुप हेलुसिनेशन में नहीं बदलता जहाँ सबको याद है कि चर्चा हुई थी पर कोई तय नहीं कर पाता कि नतीजा क्या था।
पैटर्न जो पहले दिखते नहीं थे। जब निर्णय समग्र रूप से दिखने लगते हैं, तो समझ आता है कि किन विषयों पर सबसे लंबी बहस होती है और कहाँ निर्णय अटकते हैं। ऑपरेशनल अंतर्दृष्टि जो कोई एक टूल नहीं दे सकता, क्योंकि किसी एक टूल के पास पूरी तस्वीर नहीं होती।
Sugarbug इसे कैसे सुलझाता है
वह वर्ज़निंग खोज ही वह आखिरी बूँद थी जिसने मुझे Sugarbug बनाना शुरू करने पर मजबूर किया (ठीक है, वह और तीन मरे हुए निर्णय लॉग जो मेरे ज़मीर पर बोझ बने थे)। यह वही सिस्टम है जो मैंने ऊपर बताया – API के ज़रिए आपके मौजूदा टूल्स से जुड़ता है, हर सिग्नल को एक नॉलेज ग्राफ़ में डालता है, अपने आप वर्गीकृत और लिंक करता है। ग्राफ खुद बनता जाता है जब आपकी टीम काम करती है। कोई कुछ डॉक्युमेंट नहीं करता, क्योंकि कैप्चर काम का एक साइड इफेक्ट है।
हम अभी भी शुरुआती दौर में हैं (प्रोडक्शन में, लॉन्च से पहले), और कुछ कठिन समस्याएँ अभी हल नहीं हुई हैं – वे निर्णय जो मीटिंग में मौखिक रूप से होते हैं जहाँ किसी ने नोट्स नहीं लिए, या "हाँ, यही कर लेते हैं" और एक असली प्रतिबद्धता में फर्क करना (कॉफी वाले किस्से ने हमें कॉन्फिडेंस थ्रेशोल्ड के बारे में बहुत कुछ सिखाया)। पर पुराने निर्णय खोजने में जो समय लगता था वह "नियमित रूप से निराशाजनक" से "कभी-कभी हल्का" तक आ गया है – जो एक उचित दिशा लगती है।
सिग्नल इंटेलिजेंस अपने इनबॉक्स में पाएं।
अक्सर पूछे जाने वाले सवाल
Slack थ्रेड में हफ्तों पहले लिया गया निर्णय कैसे खोजें?
बिना क्रॉस-टूल इंडेक्स के, आप वही करते हैं जो मैंने किया – स्क्रॉल करते हैं, अलग-अलग कीवर्ड आज़माते हैं, उम्मीद करते हैं कि बातचीत कब हुई यह याद आ जाए। Sugarbug, Slack मैसेज को आपके अन्य स्रोतों के साथ एक नॉलेज ग्राफ़ में डालता है ताकि आप कॉन्सेप्ट से खोज सकें, सटीक कीवर्ड से नहीं। यह जादू नहीं है – बातचीत का टेक्स्ट में होना ज़रूरी है – पर यह पुरातात्विक खुदाई से बेहतर है।
क्या Sugarbug टूल्स में निर्णयों को अपने आप ट्रैक करता है?
हाँ। आपके कनेक्टेड टूल्स से हर सिग्नल वर्गीकृत होता है – निर्णय, स्टेटस अपडेट, सवाल, ब्लॉकर – और संबंधित लोगों व टास्क से जुड़ता है। जब किसी Slack थ्रेड में निर्णय आता है जो किसी Linear इश्यू से जुड़ा हो, तो ग्राफ उन्हें बिना किसी के लिंक पेस्ट किए या लॉग अपडेट किए जोड़ देता है।
निर्णय लॉग और नॉलेज ग्राफ़ में क्या अंतर है?
निर्णय लॉग के लिए किसी को लिखना पड़ता है – क्या तय हुआ, कब और किसने। नॉलेज ग्राफ़ वे कनेक्शन अपने आप बनाता है उन सिग्नल से जो आपके टूल पहले से देते हैं – Slack थ्रेड, Linear इश्यू, उसे लागू करने वाला PR। एक के लिए अनुशासन चाहिए (जिसमें हम, जैसा मैंने खूब साबित किया है, बहुत कमज़ोर हैं); दूसरे के लिए एक सिस्टम।
निर्णय लॉग हमेशा विफल क्यों होते हैं?
क्योंकि बोझ बिल्कुल गलत वक्त पर पड़ता है। निर्णय होते समय उसे अहम पहचानना, रुकना, दूसरे टूल पर जाना, इतने संदर्भ के साथ लिखना कि हफ्तों बाद काम आए, और फिर बिना धागा खोए काम पर वापस आना। हर टीम जिसे मैंने यह आज़माते देखा, छह हफ्तों में छोड़ देती है – आलस्य से नहीं, बल्कि इसलिए कि यह प्रक्रिया लोगों के असली काम करने के तरीके के खिलाफ है।
क्या छोटी टीमें भी इससे फायदा उठा सकती हैं, या यह सिर्फ बड़े संगठनों के लिए है?
मेरे अनुभव में छोटी टीमें ज्यादा परेशान होती हैं। डॉक्युमेंटेशन बनाए रखने वाला कोई समर्पित PM नहीं होता, और "संस्थागत स्मृति" एक-दो ऐसे लोग होते हैं जिनकी याददाश्त अच्छी है। पाँच लोगों का स्टार्टअप जो Slack, GitHub और Notion में हर हफ्ते दर्जनों माइक्रो-निर्णय लेता है, उसे वही बिखराव की समस्या है जो पचास लोगों के संगठन को – बस कुछ खो जाने पर लागत झेलने वाले कम लोग हैं।
---
अगर आप कभी ऐसे कॉल पर बैठे हैं जहाँ पाँच लोग हफ्तों पहले तय हो चुके निर्णय को फिर से बनाने की कोशिश कर रहे हों – यही वह समस्या है जिसे दूर करने के लिए हमने Sugarbug बनाया है। प्रतीक्षा सूची में शामिल हों.