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