टीमों के बीच परियोजना के दोहराए गए काम हटाएँ

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

कंपनी के हर काम की सूची इसका उत्तर नहीं है। महत्वपूर्ण काम शुरू होने से पहले अर्थपूर्ण ओवरलैप पहचानने के लिए टीमों को पर्याप्त दृश्यता और उसे सुलझाने का हल्का रास्ता चाहिए। हर छोटे काम के लिए केंद्रीय स्वीकृति कतार दोहराव की जगह प्रतीक्षा ला सकती है।

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

दोहराव और उपयोगी समानांतर काम में अंतर करें

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

इसी तरह, साझा घटक हमेशा सस्ता नहीं होता। उसमें समन्वय, समझौता, रखरखाव या अनुमतियाँ लग सकती हैं जिनकी मूल टीमों को जरूरत नहीं थी। साझा करने की कुल लागत और परिणामों की तुलना अलग समाधान बनाए रखने से करें।

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

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

ओवरलैप का छोटा रजिस्टर बनाएँ

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

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

पहला ऑडिट सीमित क्षेत्र तक रखें, जैसे एक विभाग या जुड़े कार्यप्रवाह। पूरी कंपनी की सूची उपयोगी होने से पहले पुरानी पड़ सकती है। वहीं से शुरू करें जहाँ बार-बार की माँग, साझा निर्भरता या संसाधन की होड़ वास्तविक ओवरलैप दर्शाती हो।

संवेदनशील ग्राहक विवरण रजिस्टर में कॉपी न करें। उद्देश्य काम को खोजने योग्य बनाना है, हर मूल रिकॉर्ड तक व्यापक पहुँच देना नहीं। जरूरत हो तो नियंत्रित पहुँच वाले साक्ष्य की कड़ी दें।

चार संभावित परिणामों पर ओवरलैप बातचीत करें

जब दो पहल समान दिखें, तो उनके मालिकों और स्वीकृति समझने वाले व्यक्ति को साथ लाएँ। समस्या, आबादी, आउटपुट और सीमाएँ तुलना करें। पूछें कि केवल एक प्रयास जारी रहे तो क्या खोएगा।

चार परिणामों में से एक चुनें:

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

ये निर्णय विकल्प हैं, परिपक्वता की रैंकिंग नहीं। जोड़ना अपने-आप सर्वोत्तम नतीजा नहीं है। उपयोगी बदलाव यह है कि दोहराव डिलीवरी के बाद संयोग से मिलने के बजाय स्पष्ट समझौता बने।

रखरखाव कौन करेगा, दर्ज करें। साझा संपत्ति का रखरखाव करने वाली टीम न हो तो आगे दोहरा काम बढ़ सकता है, क्योंकि मूल चीज़ जरूरत पूरी न करे तो हर उपभोक्ता उसका विकल्प बनाएगा।

उदाहरण: दो एस्केलेशन डैशबोर्ड

अनसुलझे एस्केलेशन का डैशबोर्ड बनाने वाली काल्पनिक सहायता टीम सोचें। इंजीनियरिंग ऑपरेशंस टीम समान नाम की रिपोर्ट बना रही है। नेतृत्व पहले कहता है कि एक प्रयास रद्द करें।

मालिक स्वीकृति की शर्तों की तुलना करते हैं। सहायता टीम को बिना जिम्मेदार व्यक्ति वाले ग्राहक मामले पहचानने हैं। इंजीनियरिंग को अलग-अलग घटनाओं में बार-बार होने वाली सेवा विफलताएँ देखनी हैं। नाम मिलते हैं, पर परिचालन प्रश्न अलग हैं।

टीमें पुनः उपयोग योग्य हिस्सा खोजती हैं: दोनों को केस पहचानकर्ताओं और सेवा नामों का विश्वसनीय मिलान चाहिए। वे सहमत होती हैं कि इंजीनियरिंग ऑपरेशंस मिलान बनाए रखेगा, जबकि दोनों टीमें अपनी रिपोर्ट रखेंगी। वे डेटा परिभाषाओं का समन्वय करती हैं और निष्कर्षण काम दोहराने से बचती हैं।

नतीजा पुनः उपयोग और समन्वय है, जबरन विलय नहीं। निर्णय समझाने के लिए उदाहरण गढ़ा गया है। यह साबित नहीं करता कि हर दो डैशबोर्ड अलग रहें या साझा डेटा हमेशा ओवरलैप हल करे।

काम आते समय पुनरावृत्ति रोकें

नई पहल लेने में छोटी जाँच जोड़ें: “क्या संबंधित काम पहले से मौजूद है और किससे बात हुई है?” सामान्य काम के लिए यह त्वरित खोज और बातचीत होनी चाहिए। बड़े टीम-पार वादे औपचारिक समीक्षा माँग सकते हैं।

परिणाम के सुसंगत वर्णन और दिखने वाले मालिक उपयोग करें। व्यापक परियोजना नाम खोजने से आंतरिक कोड नाम के नीचे छिपा काम छूट सकता है। रिकॉर्ड में उपयोगकर्ता की समस्या रखें ताकि संगठन की शब्दावली जाने बिना लोग उसे खोज सकें।

बार-बार आने वाली माँगें साझा कार्यशाला बोर्ड पर देखें। ओवरलैप और निर्णय दर्ज करें, फिर टीम के सामान्य ट्रैकर से कड़ी जोड़ें। बोर्ड अपने-आप दोहराव पकड़ता है या परियोजना प्रणाली सिंक करता है, ऐसा दावा न करें।

कुछ समन्वय चक्रों के बाद जाँचें कि रजिस्टर मददगार है या नहीं। क्या टीमों को मौजूदा काम पहले मिला? क्या साझा संपत्तियों के मालिक मिले? क्या समन्वय से लाभ से अनुपातहीन देरी हुई? वास्तविक मामला देखने के लिए रेट्रोस्पेक्टिव विचारों में से प्रारूप चुनें।

निर्णय मापें, गढ़ी हुई बचत नहीं

खुरदरे अनुमानों का घटाव ऐसे न बताएँ जैसे “इतने घंटे बचाए” मापा हुआ परिणाम हो। दर्ज करें कि कौन-सा काम रोका, पुनः उपयोग या बदला गया और अनुमान को अनुमान कहें। साक्ष्य हो तो समय के साथ रखरखाव का बोझ और डिलीवरी परिणाम तुलना करें।

हानिकारक एकीकरण भी देखें। साझा टीम पर अधिक भार आ जाए तो सूची में सफलता दिख सकती है, जबकि बाकी सबका काम धीमा हो। दोहरा काम और अत्यधिक निर्भरता दोनों समझने योग्य समस्याएँ हैं।

अक्सर पूछे जाने वाले प्रश्न

अलग-अलग टूल इस्तेमाल करने वाली टीमों में दोहरा काम कैसे खोजें?

परिणामों, डिलिवरेबल, मालिकों और स्रोत लिंक का छोटा साझा रजिस्टर रखें। विस्तृत स्थिति हर टीम की आधिकारिक प्रणाली में रहे। साझा परत को ओवरलैप खोजने योग्य बनाना चाहिए, हर काम की नकल नहीं।

क्या मिलते-जुलते प्रोजेक्ट हमेशा जोड़ने चाहिए?

नहीं। उपयोगकर्ता, स्वीकृति, सीमाएँ और रखरखाव तुलना करें। जोड़ने से जरूरी अंतर मिट सकते हैं या समन्वय लागत बढ़ सकती है। पुनः उपयोग और समन्वित अलग डिलीवरी भी वैध परिणाम हैं।

साझा डिलिवरेबल का मालिक कौन होना चाहिए?

रखरखाव के अधिकार और क्षमता वाला व्यक्ति या टीम चुनें और उपयोग करने वालों की जिम्मेदारी स्पष्ट करें। स्पष्ट मालिक के बिना साझा रुचि रखरखाव योजना नहीं है।