कार्यस्थल की समस्याओं में मदद कैसे मांगें: स्पष्ट रूप से समझाएं और संभावित समाधान प्रस्तुत करें
मदद के लिए अनुरोध की शुरुआत यह समझाकर करें कि आप क्या पूरा करने का प्रयास कर रहे हैं, काम कहाँ अटका है और आप दूसरे व्यक्ति से किस हिस्से में मदद चाहते हैं। संभावित समाधान प्रस्तुत करने का अर्थ है अपनी वर्तमान सोच और उसकी अनिश्चितताओं को सामने रखना। इसका मतलब यह नहीं है कि मदद मांगने की अनुमति मिलने से पहले आपको समस्या खुद हल करनी ही होगी। एक्सेस न होना, जानकारी की कमी और अपरिचित काम—ये सभी मदद मांगने के वैध कारण हैं।\n\nएक उपयोगी अनुरोध सामने वाले व्यक्ति को उत्तर देने, मना करने या आपको सही व्यक्ति के पास भेजने में सक्षम बनाता है। इसके लिए अपने प्रयासों का लंबा बचाव करने या चुपके से पूरा काम किसी और पर डालने की आवश्यकता नहीं होनी चाहिए। सबसे पहले यह पहचानें कि आपको जानकारी, निर्णय, अनुमति या संयुक्त जांच की आवश्यकता है। यह अंतर यह तय करने में मदद करता है कि किससे संपर्क किया जाए।
तय करें कि किस तरह की मदद से काम आगे बढ़ेगा
मान लीजिए कि आप किसी कार्यक्रम की उपस्थिति सूची (अटेंडेंस लिस्ट) तैयार कर रहे हैं और प्राप्त हुई दो फाइलों में अलग-अलग योग (टोटल) हैं। डेटा के मालिक से यह पूछना कि कौन सी सूची वर्तमान है, जानकारी का अनुरोध करना है। किसी सहकर्मी से इस अंतर की जांच करने को कहना संयुक्त समीक्षा का अनुरोध है। किसी प्रबंधक से यह पूछना कि क्या घोषणा में देरी की जाए, एक निर्णय की मांग करता है। मूल रिकॉर्ड तक पहुंच (एक्सेस) का अनुरोध ऐसे व्यक्ति से किया जाना चाहिए जिसके पास इसे स्वीकृत करने का अधिकार हो।
ये सभी अलग-अलग अनुरोध हैं। इन सभी को उस व्यक्ति के पास न भेजें जिससे संपर्क करना सबसे आसान हो। मौजूदा दस्तावेज़ों, कार्य के मालिक (टास्क ओनर) या अपनी टीम के निर्धारित प्रश्न चैनल की जांच करें। यदि आप ओनर को नहीं जानते हैं, तो मार्गदर्शन मांगें: “मुझे आधिकारिक उपस्थिति सूची की पुष्टि करनी है। इसे बनाए रखने की जिम्मेदारी किस पद की है?” जिस व्यक्ति के पास रिकॉर्ड नहीं है, उसे अनुमान लगाने पर मजबूर न करें।
लक्ष्य और वर्तमान स्थिति के बीच के अंतर का वर्णन करें
एक स्पष्ट शुरुआत इस तरह हो सकती है: “मैं आज दोपहर के कार्यक्रम की घोषणा तैयार कर रहा हूँ, लेकिन दोनों उपस्थिति फाइलों में अलग-अलग योग हैं, इसलिए मैं अभी प्राप्तकर्ताओं की पुष्टि नहीं कर सकता।” बताएं कि विसंगति कहाँ दिख रही है और आपके पास क्या साक्ष्य हैं। यदि कारण अज्ञात है, तो वैसा ही कहें। “शायद कोई अपडेट करना भूल गया” एक परिकल्पना है, कोई सत्यापित आरोप नहीं।
GitLab की सहायता मार्गदर्शिका समस्या के संक्षिप्त सारांश, प्रासंगिक लिंक, विशिष्ट व्यवहार और एक स्पष्ट अनुरोध की सिफारिश करती है। यह स्पष्ट रूप से यह भी कहती है कि इसकी तैयारी संबंधी दिशानिर्देश किसी को मदद मांगने से रोकने नहीं चाहिए। इस व्यावहारिक अंतर को अपनाएं, बिना यह माने कि हर कार्यालयी कार्य के लिए तकनीकी सहायता वर्कफ़्लो की आवश्यकता होती है।
प्रयासों और परिणामों की रिपोर्ट दें, न कि अपनी मेहनत की डायरी
“मैंने कई बार कोशिश की है” से यह पता नहीं चलता कि आगे क्या जांचना बाकी है। “दोनों फाइलों पर आज की तारीख है; मैंने बदलाव के नोट्स देखे लेकिन मुझे कोई स्वीकृत करने वाला ओनर नहीं मिला” मदद करने वाले को शुरुआत के लिए एक बिंदु देता है। सुबह के दौरान आपके द्वारा उठाए गए हर कदम के बजाय, इस विसंगति से संबंधित कार्रवाइयों और परिणामों को शामिल करें।
यदि आप अगले दो संभावित कदमों की पहचान कर सकते हैं, तो उनकी शर्तें बताएं। आप सूची के ओनर से वर्तमान संस्करण की पुष्टि करने के लिए कह सकते हैं, या पुष्टि आने तक घोषणा को रोकने का प्रस्ताव रख सकते हैं। पहले विकल्प के लिए ओनर को खोजना आवश्यक है; दूसरे के लिए शेड्यूल से जुड़े निर्णय की आवश्यकता हो सकती है। यदि आपके पास कोई व्यावहारिक विकल्प नहीं है, तो पहली जांच की पहचान करने में मदद मांगें। तैयार दिखने के लिए मनगढ़ंत विकल्प प्रस्तुत करना अनुरोध को कम उपयोगी बना देता है।
अनुरोध का दायरा और समय सीमा तय करें
उदाहरण के लिए: “क्या आप मुझे यह पुष्टि करने में मदद कर सकते हैं कि हमें किस सूची का उपयोग करना चाहिए? इसकी जांच करने और घोषणा भेजने की जिम्मेदारी मेरी ही रहेगी। भेजने का समय बदलेगा या नहीं, यह जानने के लिए हमें दो बजे तक निर्णय की आवश्यकता है। यदि यह आपकी भूमिका से बाहर है, तो कृपया मुझे उपयुक्त संपर्क व्यक्ति बताएं।” प्राप्तकर्ता देख सकता है कि केवल एक सीमित योगदान का अनुरोध किया गया है।
केवल “क्या आप उपलब्ध हैं?” लिखकर प्रतीक्षा करने, या बिना किसी स्पष्टीकरण के कई फाइलें भेजने से बचें। GitLab की संचार पुस्तिका लिखित दृष्टिकोण में विषय और संदर्भ को शामिल करने की सलाह देती है। यदि आपको लाइव बातचीत की आवश्यकता है, तो बताएं कि क्यों और आप किन बातों पर चर्चा करना चाहते हैं। आपके द्वारा प्रस्तावित समय सीमा (डेडलाइन) स्वतः ही ऐसी प्रतिबद्धता नहीं बन जाती जिसे सामने वाले व्यक्ति ने स्वीकार कर लिया हो।
उचित पहुंच सीमा (एक्सेस बाउंड्री) के भीतर पर्याप्त साक्ष्य साझा करें
प्रासंगिक रिकॉर्ड का लिंक दें और उस हिस्से को इंगित करें जिसकी प्राप्तकर्ता को जांच करनी चाहिए। स्वीकृत आंतरिक चैनलों का उपयोग करें और पुष्टि करें कि एक्सेस उपयुक्त है। सुविधा के लिए उपस्थिति के विवरण, ग्राहक की जानकारी या आंतरिक दस्तावेज़ों को किसी सार्वजनिक प्लेटफ़ॉर्म पर न ले जाएं। स्क्रीनशॉट किसी दृश्य समस्या को स्पष्ट कर सकते हैं; कॉपी किए जा सकने वाले एरर या अंतर अक्सर खोजने योग्य टेक्स्ट के रूप में अधिक स्पष्ट होते हैं।
Stack Overflow का मार्गदर्शन प्रोग्रामिंग से जुड़े सवालों पर लागू होता है और यह समस्या का परिचय देने, प्रासंगिक शोध दिखाने और पूरा प्रोजेक्ट पोस्ट किए बिना पर्याप्त सामग्री प्रदान करने की सलाह देता है। इस सामग्री-चयन सिद्धांत को किसी कार्यालयी अनुरोध पर लागू करना एक संपादकीय अनुकूलन है, इस बात का प्रमाण नहीं कि हर अनुरोध का उत्तर मिलेगा ही।
उत्तर प्राप्त करने के बाद सहयोग को पूरा करें
अपने अगले कदम को फिर से स्पष्ट करें। सलाह, स्वीकृति और उत्तरदायित्व लेने के बीच अंतर करें: काम में देरी करने का सुझाव आवश्यक रूप से प्राधिकार (ऑथराइजेशन) नहीं है, और एक कॉलम की जांच करने का मतलब पूरा काम स्वीकार करना नहीं है। आवश्यकता पड़ने पर उचित स्वीकृति प्राप्त करें।
कार्रवाई करने के बाद, वास्तविक परिणाम के साथ मूल बातचीत पर वापस आएं। बताएं कि किस बात की पुष्टि हुई, क्या बदला और क्या अनसुलझा रह गया। यदि आगे और मदद की आवश्यकता है, तो नए अंतर (गैप) की पहचान करें। मौजूदा कार्य रिकॉर्ड में पुनः उपयोग करने योग्य उत्तर जोड़ें ताकि अगला व्यक्ति इसे ढूंढ सके, समाधान को किसी निजी बातचीत तक सीमित न रहने दें।