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