काम में रुकावट की लागत (2023)

• काम के दौरान बाधाएँ (Interruptions) productivity पर बुरा असर डालती हैं—यह आम धारणा है, लेकिन मशहूर 23 मिनट 15 सेकंड recovery time वाले आँकड़े का आधार अस्पष्ट है
• व्यापक रूप से उद्धृत किए जाने वाले पेपर में वास्तव में 23 मिनट 15 सेकंड का उल्लेख नहीं है
• कई ब्लॉग पोस्ट और लेख इस आँकड़े का हवाला देते हैं, लेकिन उनमें से अधिकांश ने पेपर को गलत उद्धृत किया है या Gloria Mark के इंटरव्यू को आधार बनाया है
• विशिष्ट research papers में इसके बजाय यह नतीजा मिलता है कि रुकावट आने पर मूल काम में लगने वाला समय थोड़ा कम हो जाता है, लेकिन stress बढ़ जाता है
• औपचारिक और स्पष्ट स्रोत की कमी है, और फिलहाल व्यक्तिगत इंटरव्यू उद्धरण ही मुख्य स्रोत हैं

---

रुकावटों का productivity पर प्रभाव

• यह बात काफ़ी फैली हुई है कि काम के दौरान बाधा या context switching होने पर वापस लौटने में 23 मिनट 15 सेकंड लगते हैं
• लेकिन यह जिज्ञासा हुई कि यह समय आखिर आया कहाँ से, और इस दावे के लिए वास्तव में भरोसेमंद मूल पेपर की पुष्टि करने की कोशिश की गई
• कई बार search करने और papers देखने के बावजूद, उद्धृत संख्या 23 या 23 मिनट 15 सेकंड का उल्लेख मूल पेपर में नहीं मिला

संबंधित papers की समीक्षा

• ब्लॉग पोस्टों में अक्सर जिस पेपर का ज़िक्र होता है, वह है The Cost of Interrupted Work: More Speed and Stress
• इस पेपर में दिखाया गया है कि रुकावट होने पर काम पर खर्च किया गया समय उल्टा कम हो जाता है, जबकि महसूस किया गया stress बढ़ जाता है
• पेपर में बाधा खत्म होने के बाद मूल काम पर लौटने में लगने वाले समय का कोई ठोस आँकड़ा या विवरण नहीं है, और 23 संख्या भी मुख्य पाठ में नहीं है
• अन्य papers, references और संबंधित research में भी यह आँकड़ा स्पष्ट रूप से दर्ज नहीं है

ब्लॉग और मीडिया उद्धरणों का विश्लेषण

• कुल 23 ब्लॉग पोस्ट और 5 papers की अतिरिक्त समीक्षा की गई
  • 9 पोस्टों ने पेपर को गलत उद्धृत किया, जिनमें से 1 में ऐसा उद्धरण भी शामिल था जो वास्तव में मौजूद ही नहीं है
  • केवल 2 पोस्टों ने उस पेपर के वास्तविक निष्कर्षों को सही तरह से उद्धृत किया
  • 9 पोस्टें Gloria Mark के 3 इंटरव्यू का सीधे या परोक्ष रूप से हवाला देती हैं
  • 2 पोस्टें Wall Street Journal में Gloria Mark के सीधे उद्धरण को फिर से उद्धृत करती हैं
• अंततः, 23 मिनट 15 सेकंड वाला आँकड़ा Gloria Mark द्वारा कई इंटरव्यू में बताया गया एक अनुभवजन्य आँकड़ा निकलता है
• लेकिन यह आँकड़ा पहली बार किस औपचारिक पेपर या research में आया, यह स्पष्ट रूप से सत्यापित नहीं हो सका

निष्कर्ष और संदर्भ

• “रुकावट के बाद 23 मिनट 15 सेकंड लगते हैं” वाला आँकड़ा अभी तक सिर्फ इंटरव्यू स्रोतों पर आधारित दिखता है, इसका कोई औपचारिक रूप से प्रकाशित पेपर-आधारित प्रमाण नहीं है
• Gloria Mark के विभिन्न papers की सूची की अतिरिक्त समीक्षा में भी यह आँकड़ा नहीं मिला
• अगर किसी को वह आधिकारिक paper या research पता हो जिसमें यह आँकड़ा आता है, तो जानकारी आमंत्रित है

अन्य जानकारी

• संबंधित विषय पर Reddit चर्चा पोस्ट का पता साझा किया गया है
• पोस्ट में उल्लेखित सभी ब्लॉग पोस्टों और papers के reference graph और links की सूची दी गई है

[GN⁺]

Hacker News राय

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

  • मेरे लिए pair programming रुकावटों के असर को कम करने का बहुत प्रभावी तरीका रहा है। एक startup में हम हर दिन पूरा दिन pair programming करते थे, और रुकने के बाद फिर से शुरू करना लगभग कभी समस्या नहीं बनता था। इसे समझाना मुश्किल है, अनुभव करना पड़ता है।
  • बिल्कुल सहमत। ऐसे दिनों में मैं उल्टा डेस्क से उठकर जंगल में टहलने चला जाता था या घर के काम कर लेता था, और उससे फिर से फोकस लौट आता था। जिन दिनों काम के लिए दिमाग सही न हो, उन दिनों सचमुच आराम चुन लेना आखिरकार अगले दिन की धमाकेदार productivity में बदल जाता है। सबके लिए win-win है।
  • मेरे लिए रुकावट की "प्रकृति" ज़्यादा महत्वपूर्ण है। ऐसे आसान सवाल जिनका जवाब याद से तुरंत दिया जा सके, उनका खर्च ज़्यादा नहीं होता। लेकिन जब कुछ गहराई से सोचना पड़े या code/documentation देखना पड़े, तब उसका असर बहुत बड़ा लगता है। email या Teams notification भी flow तोड़ सकती है। असली समस्या यह नहीं कि कोई आकर बीच में रोक रहा है, बल्कि यह है कि रुकावट किस विषय पर है। हाँ, coding के दौरान बाधा आए तो bug पैदा होने का जोखिम हमेशा बढ़ जाता है।
  • मेरे लिए फर्क इस बात से पड़ता है कि मैंने काम पहले से plan किया था या नहीं। अगर मुझे 10–11 बजे के बीच पहले से पता है कि किस चीज़ पर ध्यान देना है, तो वापस काम पकड़ना आसान होता है। लेकिन अगर बिना योजना के बस शुरू किया हो, तो बाहरी रुकावट न भी हो तब भी आसानी से भटक जाता हूँ।
  • यह लगभग सीधे अनुपात में है कि पिछली रात कितनी अच्छी नींद ली थी, और उल्टे अनुपात में कि पिछले हफ्ते कितनी coffee पी थी।

• science news reporting में यह समस्या बहुत आम है। लेख अक्सर research paper की बात को अलग ढंग से, या कभी-कभी पूरी तरह उल्टा, पेश कर देते हैं। कई बार लेख के भीतर cited paper को ढूँढना भी संभव नहीं होता। कभी-कभी गलती authors की भी होती है, लेकिन ज़्यादातर science journalists ही बात को गलत समझकर या विकृत रूप में लिखते हैं। मेरा बुनियादी नियम है कि paper का abstract, methods, और graphs/data कम से कम 5 मिनट खुद देखकर निकलो। इससे pop-science लेखों की तुलना में कहीं ज़्यादा सही समझ मिलती है, और धीरे-धीरे इसकी आदत भी हो जाती है। मैं भी जब TDD बहुत सख्ती से करता हूँ, तो रुकावट के बाद जल्दी recover कर लेता हूँ, लेकिन design पर सोचना या जटिल algorithm analysis जैसे काम, जो ज़्यादातर दिमाग के भीतर ही चलते हैं, उनमें वापसी में बहुत समय लगता है। मुझे लगता है कि इस नुकसान को वास्तव में मापा जा सकता है, और इस पर experiment भी किया जा सकता है।

  • जिन माहौल में रुकावटें सामान्य हों, वहाँ मैं काम करने का तरीका ही बदल देता हूँ। ऊपर से लगता है कि time loss कम है, लेकिन असल में मैं बस रुकावटों को ध्यान में रखकर काम कर रहा होता हूँ। असर कम नहीं हुआ, बस काम कुल मिलाकर बिखर गया है।
  • कभी-कभी लगता है कि LLM (large language model) की बकवास का एक हिस्सा शायद इसलिए होता है कि वह ऐसी science reporting को गलती से high-quality training data समझ लेता है।
  • इसमें विस्तार से बताया गया है कि कैसे ऐसी छोटी-छोटी गलतियाँ जमा होकर भरोसा गिराती हैं और बड़ी समस्याओं में बदल जाती हैं। उदाहरण के लिए, "scientists ने कहा" जैसी reporting में अक्सर journalist की गलती का बोझ consumer पर आ जाता है, scientist पर नहीं। "hotdog ज़्यादा खाने से cancer" जैसे दावे भी research context और numbers हटाकर सनसनीखेज तरीके से पेश किए जाते हैं। नतीजा यह होता है कि असली research और news narrative के बीच की खाई से आम लोग भरोसा खो देते हैं। ऊपर से citation count वैज्ञानिकों की प्रतिष्ठा तय करता है, इसलिए media attention पाने का प्रोत्साहन बनता है, और यह भी विकृति को बढ़ाता है। साधारण papers पर किसी की नज़र नहीं जाती, इसलिए MIT graduate student का paper ज़्यादा cite हो जाता है। ऐसी systemic समस्याएँ मिलकर समय के साथ और बड़ी होती जाती हैं। सब कुछ सरल बनाकर समझाना सुविधाजनक हो सकता है, लेकिन वास्तविकता में दुनिया लगातार अधिक जटिल होती जा रही है। papers मूलतः peers के बीच संचार का माध्यम हैं; जब आम जनता से संवाद करना हो, तो अलग तरह के professional communicators की ज़रूरत होती है। और "अगर आप इसे सरलता से नहीं समझा सकते, तो आप इसे समझते नहीं" जैसी पंक्ति भी काफ़ी हास्यास्पद है। कुछ जटिल अवधारणाएँ मूलतः सरल नहीं बनाई जा सकतीं।

• मूल स्रोत 2006 में Gallup की researcher Gloria Mark का interview है, लिंक, जिसमें कहा गया है कि "बाधा आने के बाद फिर से काम पर लौटने में औसतन 23 मिनट 15 सेकंड लगते हैं"। अच्छी बात यह है कि 81.9% लोग उसी दिन फिर अपने मूल काम पर लौटते हैं, और यह समय असामान्य रूप से लंबा नहीं है।

  • मैं इस 23 मिनट का अर्थ यह लेता हूँ कि यह वह समय है जो बाधा के बाद लोग मूल काम पर दोबारा फोकस करने की कोशिश में नहीं, बल्कि बीच में आए दूसरे काम या अचानक निपटाने पड़े नए task में लगाते हैं। यानी यह समय अपने-आप में पूरी तरह बर्बाद नहीं है।
  • दुर्भाग्य से यह interview असली primary source नहीं है। Jaro Fietz (oberien) नाम के एक लेखक ने diagram में इस interview को refer किया था, लेकिन असली research paper अभी तक नहीं मिला। अगर किसी को सही paper पता हो तो बताने का अनुरोध है।
  • लेकिन सोच रहा हूँ कि यहाँ "bad news" आखिर है क्या।

• जब मैं किसी जटिल समस्या को हल करते हुए flow state में होता हूँ और बीच में रुकावट आती है, तो सचमुच शारीरिक दर्द जैसा महसूस होता है। बाहर से सामान्य दिखने की कोशिश करूँ तब भी दिमाग में जुड़ी हुई सारी कड़ियाँ टूट जाती हैं। productivity loss को मैं संख्याओं में नहीं माप सकता, लेकिन समस्या पर निर्भर करते हुए recovery में 20 मिनट से भी ज़्यादा लग जाना बहुत आम है।

  • यह समझाना कि हमारे open source project की issue management को public GitHub से private Jira (2FA required) में ले जाना developer productivity के लिए क्यों बुरा है, senior management को शायद ही कभी समझ आता है। उनके लिए "flow state" या अचानक टूट जाने का दर्द बस कोई काल्पनिक बात है।

• मेरे लिए meetings से होने वाली असली "रुकावट" से भी ज़्यादा समय उस "उम्मीद" में बर्बाद होता है कि रुकावट आने वाली है। इसलिए दोनों तरफ़ 30-30 मिनट उड़ जाते हैं।

  • महामारी से पहले work-from-home/office schedule अनियमित था। कभी-कभी अगर मैं office meeting से पहले जल्दी पहुँच जाता, तो बीच का वह समय लगभग बेकार चला जाता था। गहरे काम की शुरुआत नहीं कर पाता, बस हल्की research जैसी चीज़ें करके समय काटता। open office environment में वैसे भी बहुत रुकावटें होती थीं, इसलिए फोकस करना मुश्किल था। आदर्श तो यही था कि meeting से सिर्फ 5–10 मिनट पहले पहुँचूँ, लेकिन व्यावहारिक रूप से ऐसा करना आसान नहीं था। दूसरी ओर, कभी-कभी flow state में मैं meeting ही miss कर देता था, और तब desktop/phone notifications का कोई फायदा नहीं होता था। सच में miss न करना हो तो alarm लगाना चाहिए, लेकिन अक्सर ऐसा भी नहीं करता।
  • मेरा दिन खराब करने वाली चीज़ यही meetings हैं। सहकर्मियों से आने वाली दूसरी रुकावटें लगभग हमेशा उपयोगी और productive होती हैं।
  • मुझे भी आख़िरी समय में जल्दबाज़ी में reschedule की गई meetings से बहुत नफ़रत है। जब लगता है कि बस 30 मिनट बचे हैं, तो कोई अर्थपूर्ण काम शुरू ही नहीं होता। यह सचमुच समय की बर्बादी है।
  • दिमाग में यह सोच आ जाती है कि "meeting तक 30 मिनट बचे हैं, अब कोई गंभीर काम शुरू मत करो।" कुछ लोग चतुराई दिखाते हुए meetings के बीच 1 घंटे का gap रखते हैं, लेकिन उससे फिर पूरा दिन ही बेकार हो जाता है।
  • मेरे लिए भी एक meeting लगते ही लगता है कि दिन का आधा हिस्सा गया।

• manager के रूप में मुझे ईमानदारी से लगता है कि बार-बार होने वाली बहुत-सी परेशान करने वाली रुकावटें दरअसल "खुद कोशिश न करने वाले रवैये" से आती हैं। मेरी भूमिका सिर्फ strategy और priorities देना नहीं, बल्कि developers के अटकने पर रास्ता साफ़ करना भी है। लेकिन कुछ लोग basic चीज़ें भी खुद ढूँढे बिना सीधे पूछ लेते हैं, जैसे "database account चाहिए तो infra वाले से पूछो" या "यह API किसने लिखी, git में ढूँढो।"

  • senior developer के नज़रिए से भी पूरी सहमति है। बहुत बार लोग ऐसी बातें 15 सेकंड में मुझसे पूछ लेते हैं जिन्हें वे खुद 2–3 मिनट लगाकर जान सकते थे। जब junior कोई गहरा सवाल पूछता है, तो मैं 15–30 मिनट साथ बैठकर सोचता हूँ, लेकिन उससे पहले कई सवाल पूछता हूँ कि उसने खुद क्या search किया, क्या कोशिश की। फिर भी जब वही चीज़ बार-बार पूछी जाती है, तो सचमुच थका देती है। कभी-कभी जवाब सुनकर लगता है कि वह बात तो सामने वाला पहले से जानता भी था; जैसे वह बस चाहता हो कि कोई और उसके लिए काम कर दे। यह बहुत थकाने वाला है।
  • मैं ऐसे मौकों को "मछली पकड़ना सिखाने" वाले समय की तरह देखता हूँ। साथ में यह भी पूछता हूँ कि उसने खुद क्या जाँच-पड़ताल या प्रयास किया। अगर यह बार-बार हो, तो one-on-one में सीधे बात करनी चाहिए। और अगर यह कई लोगों में एक साथ दिखे, तो शायद दिक्कत व्यक्ति से बढ़कर organization या documentation process में हो। जटिल organizations या बड़े teams में ऐसी स्थिति खास तौर पर आम है।
  • अगर अनुरोध मेरी अपनी team के भीतर से आया है, तो फिर वह काम का हिस्सा है, सचमुच की "रुकावट" नहीं। दिशा और प्राथमिकता देना अगर full-time काम नहीं भी है, तब भी यह स्वाभाविक ज़िम्मेदारी है।

• यह विडंबना दिलचस्प है कि बहुत-से लोग सिर्फ headline या article देखकर, या बिना पढ़े ही comment करके, उसी "article के दावे" को real time में साबित कर रहे होते हैं।

  • सचमुच लगता है कि बहुत-से लोग सिर्फ comments पढ़कर भी चर्चा में शामिल हो जाते हैं। मैं भी कभी-कभी article पढ़ने लायक है या नहीं, यह तय करने के लिए पहले comments देख लेता हूँ, लेकिन कम-से-कम top comment तक जाने से पहले मूल लेख ज़रूर पढ़ता हूँ।

• अगर सचमुच "23 मिनट" कोई fixed value होती, तो doctors जैसे कई अहम पेशे असंभव हो जाते। यानी रुकावट के असर को एक ही संख्या में समेटना संभव नहीं होगा।

  • मेरा मानना था कि यह एक average होगा, और वास्तव में कुछ कामों में 5 सेकंड लग सकते हैं, कुछ में 2 घंटे। ऊपर से सटीक quotation भी इतनी निश्चित नहीं है, इसलिए सिर्फ 23 मिनट वाली एकल संख्या पर ज़ोर देना जल्दबाज़ी होगी।
  • या फिर ऐसा भी हो सकता है कि बाधित काम की priority धीरे-धीरे नीचे खिसकती जाए और वह लंबे समय तक पूरा ही न हो पाए।

• Gloria Mark की किताब ‘Multitasking in the Digital Age’ के पेज 44 पर यह बात आती है, लिंक

• स्रोत को इतने ध्यान से ढूँढने और दर्ज करने की कोशिश सचमुच शानदार है। मैं अक्सर छात्रों को डाँटता हूँ जब वे references या मूल स्रोत को ठीक से जाँचे बिना quote कर देते हैं, या किसी गलत व्याख्या को अपनी समझ मान बैठते हैं। सक्रिय पठन एक ऐसी प्रक्रिया है जिसमें पाठक खुद सोच जोड़ता है और अर्थ निकालता है।