3.5 संचार और सहयोग मेट्रिक्स

अवलोकन और प्रेरणा

संचार और सहयोग, SPACE (विषय 3.1) में C, मापता है कि लोगों और टीमों के बीच जानकारी वास्तव में कैसे बहती है: दस्तावेज़ीकरण कितना खोजने योग्य है, ज्ञान एक टीम में कितनी समान रूप से फैलता है, क्रॉस-टीम निर्भरताओं का समन्वय कितनी अच्छी तरह होता है, और नए टीम सदस्य साझा समझ के फ़्लो में कैसे ऑनबोर्ड होते हैं। यह आयाम अक्सर पाँचों में सबसे कम इंस्ट्रूमेंट किया गया है, ठीक इसलिए क्योंकि इसे डिलीवरी डेटा की तुलना में देखना कठिन है और संतुष्टि डेटा की तुलना में कम व्यक्तिगत है, और वह अंतर एक ग़लती है, क्योंकि यहाँ की टूट-फूट अक्सर उन समस्याओं का मूल कारण होती है जो हर दूसरे आयाम में, ग़लत रूप से आरोपित होकर, सामने आती हैं।

एक बढ़ती चेंज फ़ेल्योर रेट (विषय 2.10) जो एक परीक्षण समस्या जैसी दिखती है वह कभी-कभी वास्तव में एक संचार समस्या होती है: एक टीम जिसे एक निर्भरता के परिवर्तन के बारे में तब तक पता नहीं था जब तक यह उत्पादन में टूट नहीं गया। एक गिरती संतुष्टि प्रवृत्ति (विषय 3.2) जो एक कार्यभार समस्या जैसी दिखती है वह कभी-कभी वास्तव में एक अलगाव समस्या होती है: एक इंजीनियर जिसे उन बातचीतों से चुपचाप बाहर रखा गया है जहाँ निर्णय लिए जाते हैं। इस विषय का केंद्रीय तर्क यह है कि संचार और सहयोग ठीक इसलिए प्रत्यक्ष माप के हक़दार हैं क्योंकि उनकी विफलताएँ अन्य समस्याओं के रूप में प्रच्छन्न होती हैं, और ग़लत मूल कारण का पीछा करने वाली एक टीम ग़लत चीज़ को ठीक करने में वास्तविक प्रयास बर्बाद करती है।

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

प्रमुख सिद्धांत

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

सिफ़ारिशें

ज्ञान एकाग्रता को सीधे मापें

ट्रैक करें कि कितने लोग हर महत्वपूर्ण प्रणाली घटक की सक्षमता से समीक्षा, संशोधन, या संचालन कर सकते हैं: केवल एक योग्य व्यक्ति वाला एक घटक एक की बस फ़ैक्टर है, एक गंभीर और अक्सर अदृश्य जोखिम (साथी software-engineering-guide पुस्तक का दीर्घजीवी प्रणालियों को बनाए रखने पर विषय इसे अधिक गहराई से कवर करता है)। ऑन-कॉल रोटेशन रिकॉर्ड के साथ संयुक्त वर्ज़न कंट्रोल ब्लेम डेटा, इस एकाग्रता को स्वचालित रूप से उजागर कर सकता है: उन घटकों के लिए देखें जहाँ एक एकल लेखक या एक एकल ऑन-कॉल प्रतिक्रियादाता एक सार्थक अवधि में परिवर्तनों या घटना प्रतिक्रियाओं के एक असंगत हिस्से का हिसाब रखता है।

एक प्रत्यक्ष संकेत के साथ क्रॉस-टीम निर्भरता घर्षण को मापें

ट्रैक करें कि एक क्रॉस-टीम अनुरोध, एक आवश्यक API परिवर्तन, एक साझा लाइब्रेरी अपडेट, एक समन्वित रिलीज़, उठाए जाने से लेकर हल होने तक कितना समय लेता है, आत्मा में विषय 2.6 के साइकल-टाइम विघटन के समान लेकिन विशेष रूप से अंतर-टीम पर लागू, टीम के भीतर नहीं। एक टीम जो किसी दूसरी टीम द्वारा स्वामित्व वाली एक निर्भरता के लिए लगातार हफ़्तों प्रतीक्षा करती है उसकी एक सहयोग समस्या है जो किसी भी टीम के अपने आंतरिक डिलीवरी मेट्रिक्स में साफ़-साफ़ नहीं दिखेगी।

दस्तावेज़ीकरण अस्तित्व नहीं, दस्तावेज़ीकरण खोजने-योग्यता को संकेत के रूप में उपयोग करें

पुराने या न खोजने योग्य पन्नों से भरा एक विकी अच्छे संचार का प्रमाण नहीं है केवल इसलिए क्योंकि सामग्री तकनीकी रूप से कहीं मौजूद है। जहाँ संभव हो, ट्रैक करें कि दस्तावेज़ीकरण को वास्तव में कितनी बार एक्सेस किया जाता है, एक नया टीम सदस्य कितनी बार यह रिपोर्ट करता है कि वे एक आवश्यक उत्तर नहीं खोज सके, या एक चैट चैनल में एक ही प्रश्न कितनी बार बार-बार पूछा जाता है क्योंकि उत्तर, दस्तावेज़ीकृत होने के बावजूद, खोजने योग्य नहीं था। यह सीधे दस्तावेज़ीकरण गुणवत्ता (विषय 4.6) को इस आयाम की सहयोग चिंताओं से जोड़ता है।

उत्पादक योगदान तक ऑनबोर्डिंग समय को एक प्रत्यक्ष प्रॉक्सी के रूप में ट्रैक करें

एक नए टीम सदस्य के शामिल होने से लेकर उनके पहले सार्थक, स्वतंत्र योगदान तक का समय एक संगठन में साझा समझ वास्तव में कितनी अच्छी तरह बहती है इसके लिए एक मज़बूत, व्यावहारिक प्रॉक्सी है: एक टीम जहाँ ज्ञान पूरी तरह लोगों के दिमाग़ों में रहता है वह धीरे और अप्रत्याशित रूप से ऑनबोर्ड होती है; वास्तव में अच्छे दस्तावेज़ीकरण, स्पष्ट स्वामित्व, और सुलभ मेंटरशिप वाली एक टीम तेज़ी से और अधिक लगातार ऑनबोर्ड होती है। इस मेट्रिक को स्पष्ट रूप से ट्रैक करें और एक लंबे या अत्यधिक परिवर्तनशील ऑनबोर्डिंग समय को केवल एक HR चिंता नहीं, एक सहयोग संकेत मानें।

केवल संगठन चार्ट नहीं, समय-समय पर वास्तविक संचार नेटवर्क मैप करें

एक संगठनात्मक चार्ट वर्णन करता है कि कौन किसे रिपोर्ट करने वाला है; यह शायद ही कभी वर्णन करता है कि काम पूरा करने के लिए वास्तव में कौन किससे बात करता है। संचार पैटर्न का समय-समय पर, हल्का विश्लेषण, कोड समीक्षा नेटवर्क (कौन किसके काम की समीक्षा करता है), या बैठक उपस्थिति ओवरलैप, एक वास्तविक सहयोग संरचना उजागर कर सकता है जो औपचारिक संगठन चार्ट से काफ़ी अलग है, अक्सर एक अनौपचारिक बॉटलनेक (एक व्यक्ति जिससे हर कोई गुज़रता है) या एक अलग-थलग जेब (एक उप-टीम जो व्यापक जानकारी प्रवाह से बह गई है) उजागर करता है जो अन्यथा अदृश्य रहेगी।

समझौते: लाभ और हानि

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

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

अपनी टीम के साथ चर्चा करने के प्रश्न

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

क्षेत्र दृष्टिकोण

स्टार्टअप। एक छोटी टीम में संचार स्वाभाविक रूप से निकटता और दैनिक बातचीत के माध्यम से होता है, और औपचारिक माप आमतौर पर अनावश्यक है। जिस जोखिम पर नज़र रखनी है वह है बस फ़ैक्टर का ख़तरनाक रूप से केंद्रित होना जैसे-जैसे टीम उस आकार से आगे बढ़ती है जहाँ अनौपचारिक अवशोषण अभी भी सबको छूता है, अक्सर आठ से बारह लोगों के आसपास।

छोटा व्यवसाय। एक सरल, समय-समय पर, ईमानदार बातचीत, “इस प्रणाली को समझने वाला एकमात्र व्यक्ति कौन है,” अक्सर औपचारिक इंस्ट्रूमेंटेशन की आवश्यकता के बिना सबसे महत्वपूर्ण ज्ञान-एकाग्रता जोखिमों को उजागर करती है। पहले ज्ञान के दो या तीन सबसे नाज़ुक, सबसे केंद्रित क्षेत्रों को दस्तावेज़ीकृत करने को प्राथमिकता दें।

एंटरप्राइज़। यहाँ क्रॉस-टीम निर्भरता घर्षण और ज्ञान एकाग्रता दोनों बुरी तरह पैमाना बदलते हैं, क्योंकि अधिक टीमों का अर्थ है अधिक समन्वय सतह क्षेत्र और अधिक महत्वपूर्ण प्रणालियाँ जो एक सिकुड़ते कार्यकालीन विशेषज्ञों के पूल के स्वामित्व में समाप्त हो सकती हैं। इस विषय द्वारा सुझाई गई इंस्ट्रूमेंटेशन में जान-बूझकर निवेश करें, क्योंकि अनौपचारिक जागरूकता वास्तव में इस पैमाने पर एक संगठन को कवर नहीं कर सकती।

सरकार। सार्वजनिक-क्षेत्र संगठनों में सामान्य दीर्घजीवी प्रणालियाँ और लंबे कर्मचारी कार्यकाल स्पष्ट स्थिरता के पीछे छिपा गंभीर बस-फ़ैक्टर जोखिम बना सकते हैं, क्योंकि एक प्रणाली जिसने एक दशक में हाथ नहीं बदले हैं वह पूरी तरह उन एक या दो लोगों पर निर्भर हो सकती है जो सेवानिवृत्ति के क़रीब हैं। ज्ञान-एकाग्रता माप को एक परिचालन-निरंतरता चिंता मानें, केवल एक इंजीनियरिंग शालीनता नहीं।

उदाहरण

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

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

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

संचार और सहयोग को सीधे मापने का प्रतिफल उन मूल कारणों को पकड़ना है जिन्हें अन्य आयाम ग़लत रूप से आरोपित करते हैं: एक गुणवत्ता समस्या जो एक परीक्षण अंतर जैसी दिखती है लेकिन वास्तव में एक संचार टूट-फूट है वह तब प्रयास बर्बाद करती है जब एक टीम अंतर्निहित समन्वय विफलता को ठीक करने की बजाय अधिक परीक्षण जोड़कर इसे ठीक करने की कोशिश करती है। ऊपर का बस-फ़ैक्टर उदाहरण इस प्रतिफल का सबसे स्पष्ट संस्करण दिखाता है: एक संगठन जो सक्रिय रूप से एक गंभीर ज्ञान-एकाग्रता जोखिम की खोज करता है और उसे ठीक करता है वह इसे एक वास्तविक संकट के दौरान खोजने की विनाशकारी क़ीमत से बचता है, जब एक महत्वपूर्ण प्रणाली को समझने वाला एकमात्र व्यक्ति वास्तव में अनुपलब्ध हो।

कुल स्वामित्व लागत अधिकांशतः इंस्ट्रूमेंटेशन प्रयास है, वर्ज़न कंट्रोल, ऑन-कॉल, और मुद्दा-ट्रैकिंग डेटा को ऐसे तरीक़ों से जोड़ना जो बॉक्स से बाहर स्वचालित नहीं हैं, साथ ही ज्ञान एकाग्रता और निर्भरता घर्षण की स्पष्ट रूप से समीक्षा करने का समय-समय पर अनुशासन। वह लागत एक वास्तविक बस-फ़ैक्टर संकट या एक दीर्घकालिक, असंबोधित क्रॉस-टीम समन्वय विफलता की तुलना में मामूली है।

विरोधी-पैटर्न और नुक़सान

इस आयाम को छोड़ना क्योंकि इसे स्वचालित रूप से इंस्ट्रूमेंट करना कठिन है: मूल कारणों को अन्य, मापने में आसान आयामों को ग़लत रूप से आरोपित छोड़ देता है।
एक संगठन चार्ट को वास्तविक संचार पैटर्न की एक सटीक तस्वीर मानना: अक्सर ग़लत, और वह अंतर ठीक वहीं है जहाँ छिपे हुए बॉटलनेक रहते हैं।
एक संकट खोज को मजबूर करने तक बस फ़ैक्टर को नज़रअंदाज़ करना: इस विषय द्वारा चेतावनी दी गई एकल सबसे हानिकारक विफलता मोड।
यह मान लेना कि दस्तावेज़ीकरण अस्तित्व दस्तावेज़ीकरण उपयोगिता के बराबर है: पुरानी या न खोजने योग्य सामग्री बहुत कम वास्तविक संचार मूल्य प्रदान करती है।
क्रॉस-टीम घर्षण मापना लेकिन एक बार मिलने पर एक स्पष्ट, ठीक करने योग्य मूल कारण पर कार्य न करना: निदानात्मक निवेश को बर्बाद करता है।
धीमी, परिवर्तनशील ऑनबोर्डिंग को एक इंजीनियरिंग सहयोग संकेत की बजाय विशुद्ध रूप से एक HR मुद्दा मानना: एक वास्तव में उपयोगी, मापने योग्य प्रॉक्सी को चूकता है।

परिपक्वता मॉडल

स्तर 1, आरंभ: संचार और सहयोग को बिल्कुल भी नहीं मापा जाता; बस फ़ैक्टर और क्रॉस-टीम घर्षण केवल संकट के माध्यम से खोजे जाते हैं।
स्तर 2, विकास: ज्ञान एकाग्रता की कुछ अनौपचारिक जागरूकता मौजूद है, लेकिन कोई सुसंगत माप या सक्रिय जाँच नहीं है।
स्तर 3, मानकीकरण: बस फ़ैक्टर और क्रॉस-टीम निर्भरता घर्षण को महत्वपूर्ण प्रणालियों और साझा सेवाओं के लिए संगठन-व्यापी लगातार मापा जाता है।
स्तर 4, प्रबंधन: संचार-नेटवर्क मैपिंग समय-समय पर छिपे हुए बॉटलनेक और अलग-थलग जेबों को उजागर करती है, और ऑनबोर्डिंग समय को साझा-समझ स्वास्थ्य के लिए एक प्रत्यक्ष प्रॉक्सी के रूप में ट्रैक किया जाता है।
स्तर 5, संयोजन: संगठन घटनाएँ कारणित करने से पहले ज्ञान-एकाग्रता जोखिम और क्रॉस-टीम घर्षण को सक्रिय रूप से कम करता है, और विशिष्ट हस्तक्षेपों की ओर इशारा कर सकता है, जान-बूझकर ज्ञान फैलाना, स्पष्ट निर्भरता प्रक्रियाएँ, जिन्होंने इस आयाम को मापने योग्य रूप से सुधारा।

चर्चा के लिए विचार

ईमानदारी से, हमारी एकल सबसे महत्वपूर्ण प्रणाली के लिए हमारा बस फ़ैक्टर क्या है?
पिछले चौथाई में किस क्रॉस-टीम निर्भरता ने सबसे अधिक घर्षण कारणित किया, और क्या हमने इसे मापा?
क्या एक नया टीम सदस्य हमारा दस्तावेज़ीकरण खोज पाएगा, या केवल यह पाएगा कि यह तकनीकी रूप से कहीं मौजूद है?
क्या हमारा अनौपचारिक संचार नेटवर्क हमारे संगठन चार्ट से मेल खाता है?
किस गुणवत्ता या संतुष्टि समस्या का वास्तव में एक सहयोग मूल कारण हो सकता है जिसकी हमने जाँच नहीं की है?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity,” ACM Queue (2021)।
Team Topologies, by Matthew Skelton and Manuel Pais (टीम अंतःक्रिया मोड और क्रॉस-टीम निर्भरता डिज़ाइन)।
Peopleware: Productive Projects and Teams, by Tom DeMarco and Timothy Lister (अनौपचारिक संचार संरचनाएँ और उत्पादकता पर उनका प्रभाव)।
Conway, Melvin E., “How Do Committees Invent?” (1968): संचार संरचना और प्रणाली संरचना के बीच संबंध पर Conway के नियम की उत्पत्ति।