"Hello" मना, "Quick Call" मना, एजेंडा बिना मीटिंग मना

"Hello" के बिना बातचीत शुरू करें

• "Hello" से बातचीत शुरू करना अप्रभावी है
• अगर आप सीधे सवाल लिखें, तो जवाब जल्दी मिल सकता है
• तकनीकी सहायता मांगते समय समस्या को ठोस रूप से समझाना ज़रूरी है
• उदाहरण:
  1. "Hi", "Hello" सबसे खराब तरीका है
  2. "Hi, frobnicate function काम नहीं कर रहा" पर्याप्त नहीं है
  3. "Hi, frobnicate function Error: missing argument 'count' error दे रहा है" बेहतर तरीका है
  4. "Hi, frobnicate function Error: missing argument 'count' error दे रहा है. पूरा stack trace यह है: (...)" एकदम सही सवाल है

"Quick call" मत मांगें

• "Quick call" की मांग अप्रभावी है
• कॉल, chat की तुलना में ज़्यादा बाधा डालती है
• कई बार समस्या message से ही हल हो सकती है
• समस्या समझाते-समझाते आप खुद भी उसका हल निकाल सकते हैं
• कॉल अस्थायी होती है, लेकिन message स्थायी रहता है
• "Quick call?" कहने के बजाय समस्या को ठोस रूप से समझाना बेहतर है

"No agenda" मीटिंग से बचें

• बिना एजेंडा वाली मीटिंग अप्रभावी होती है
• एजेंडा होने पर मीटिंग की तैयारी की जा सकती है
• एजेंडा से मीटिंग का उद्देश्य और checklist दी जा सकती है
• एजेंडा की वजह से सिर्फ वही लोग शामिल होते हैं जिनकी ज़रूरत है
• तकनीकी सवाल पहले से लिखकर भेजना बेहतर है

संदर्भ महत्वपूर्ण है

• remote work में मदद मांगते समय समस्या को ठोस रूप से समझाना चाहिए
• कॉल के बजाय लिखित रूप में समस्या बताना बेहतर है
• मीटिंग प्लान करते समय साफ़ एजेंडा देना चाहिए
• इन तरीकों से online interaction अधिक प्रभावी होता है और समस्याएँ जल्दी सुलझती हैं

---

GN⁺ का सार

• यह remote work में प्रभावी communication के तरीकों को समझाता है
• "Hello" के बिना सीधे सवाल लिखना महत्वपूर्ण है
• "Quick call" के बजाय समस्या को ठोस रूप से समझाना बेहतर है
• बिना एजेंडा वाली मीटिंग से बचना चाहिए और साफ़ एजेंडा देना चाहिए
• इन तरीकों से online interaction अधिक प्रभावी होता है और समस्याएँ जल्दी सुलझती हैं

[savvykang]

Don't worry, I'm not mad at you.

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

[kandk]

मुझे लगा था कि इसमें बहुत ही स्वाभाविक बातें लिखी हैं, लेकिन काफ़ी लोग इससे सहमत नहीं हैं..

चाहे call हो या meeting, उसकी तैयारी आयोजक करे यह स्वाभाविक है, और अगर बात बहुत अस्पष्ट होने की वजह से तैयारी नहीं हो पाई, तो पहले से समझ लेकर ही meeting शुरू करना सही है.

[savvykang]

रिकॉर्ड-आधारित संचार को कुछ हद तक व्यापक रूप से लागू कर पाने वाला क्षेत्र IT इंडस्ट्री ही है, लेकिन संगठनात्मक संस्कृति और जड़ता की वजह से यह अब भी संक्रमणकाल में ही लगता है।

[draupnir]

सहमत हूँ।

[f4strada]

• किसी भी तरह से सहकर्मी का मूड खराब करना सबसे खराब तरीका है
• अगर agenda हो तो meeting की तैयारी की जा सकती है, लेकिन इसका मतलब यह नहीं कि लोग सच में तैयारी करते हैं; ऐसे लोग बहुत कम होते हैं
• वास्तविक कामकाजी माहौल में अक्सर agenda के आधार पर केवल वही लोग चुनना मुश्किल होता है जिन्हें meeting में होना चाहिए
• अगर आपसी भरोसा ही न हो, तो ये सब बेकार है

मैंने जानी-मानी कंपनियों से लेकर छोटी कंपनियों तक सबमें काम किया है
और मूर्ख लोगों से लेकर जीनियस लोगों तक सबके साथ काम किया है, लेकिन इंसान काम कैसे करते हैं इसमें सब जगह काफी समानता होती है
अगर मैं खुद ठीक से काम करूँ, तो कोई hi कहे या xi कहे, उससे कोई फर्क नहीं पड़ता

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

इसीलिए ऐसे लेख लिखने वालों को ही पहले छाँटना चाहिए।

[GN⁺]

Hacker News राय

• रिमोट काम करने पर फिजिकल ऑफिस में होने वाली आकस्मिक मुलाकातें खत्म हो जाती हैं

  • सोशल कॉल्स को कृत्रिम रूप से शेड्यूल किया जा सकता है, लेकिन वे असली ऑफिस जैसा अनुभव नहीं दे सकतीं
  • अगर आप एक quick call को मना करते हैं, तो आप और अलग-थलग पड़ सकते हैं
  • कॉल बाधा बन सकते हैं, लेकिन ideas पर brainstorming के लिए उपयोगी भी हो सकते हैं

• अगर हर छोटे सवाल को पूरी मीटिंग में बदल दिया जाए, तो संगठन बहुत ज्यादा bureaucratic हो सकता है

  • लोग experts से पूछने के बजाय अंदाज़ा लगाना शुरू कर सकते हैं
  • कंपनी हर व्यक्ति के हिसाब से 100% नहीं ढल सकती

• लेखक की राय से कुल मिलाकर सहमत हैं, लेकिन कुछ points बढ़ा-चढ़ाकर कहे गए हैं, जिससे पूरी दलील कमजोर पड़ती है

  • गलत code को debug करने में समय बर्बाद करना आपकी अपनी गलती भी हो सकती है
  • IT support requests को chat की जगह ticket system से संभालना चाहिए
  • अगर समस्या पहले से पता है, तो लंबी-चौड़ी व्याख्या की ज़रूरत नहीं होती

• productivity को जरूरत से ज्यादा optimize करना, सहकर्मियों तक पहुंच की सुविधा की कीमत पर हो सकता है

• बड़ी कंपनियों में meeting agenda और meeting के बाद notes अहम होते हैं

  • जो लोग मीटिंग के लिए तैयार नहीं होते, वे दूसरों का समय बर्बाद कर सकते हैं
  • मीटिंग में लिए गए फैसलों को दर्ज न करना भी दूसरों का समय बर्बाद करता है

• जो लोग stack trace छोड़ देते हैं, वे समय बर्बाद करा सकते हैं

  • जो लोग उलझे हुए सवाल पूछते हैं, वे खुद भी उलझन में होते हैं
  • स्थिति समझ में आने तक सवाल पूछते रहना महत्वपूर्ण है

• कुछ राय से सहानुभूति है, लेकिन tone असहज है

  • अलग communication styles को 'गलती' कहना आकर्षक नहीं लगता

• इस राय से सहमत नहीं कि कॉल chat message से ज्यादा बाधक होते हैं

  • कॉल की शुरुआत और अंत स्पष्ट होता है
  • asynchronous chat लगातार ध्यान खींचती रहती है

• यह देखकर हैरानी होती है कि कुछ लोगों के पास productivity पर लिखने का समय है

• समझ नहीं आता कि Slack पर सिर्फ "Hello" या "Hi Joe" लिखकर इंतज़ार करने वाले लोग ऐसा क्यों करते हैं

[heycalmdown]

जो व्यक्ति उलझे हुए सवाल पूछता है, वह खुद भी उलझन की स्थिति में होता है
स्थिति को समझने तक सवाल पूछते रहना ज़रूरी है

मुझे यह बात और

कॉल की शुरुआत और अंत स्पष्ट होते हैं
asynchronous chat लगातार ध्यान लगाए रखती है

यह बात काफ़ी relatable लगी। हालांकि मुझे कॉल पसंद नहीं हैं।

[roxie]

मुझे भी ऐसा लग रहा है कि एक तरफ़ मैं इसे मानना नहीं चाहता, लेकिन दूसरी तरफ़ सहमति भी है..