दो हफ़्ते के स्प्रिंट का नौवां दिन है, और डिलीवरी टीम एक ही तरह की उलझन में फंसी हुई है। इंजीनियर Slack पर पूछ रहे हैं कि कौन सा टिकट असल में तैयार है, QA लीड ऐसे एनवायरनमेंट का इंतज़ार कर रहा है जिसका कोई मालिक नहीं है, और प्रोडक्ट ओनर एक साधारण स्टेटस अपडेट मांग रहा है जिसे तैयार करने में असल काम से ज़्यादा समय लगता है। आप प्रोजेक्ट मैनेजर हैं, और आप यह तय नहीं कर पा रहे हैं कि वर्कफ़्लो के शोर (बेकार की चीज़ों) को ऑटोमेट करें या पहले वर्कफ़्लो को बेहतर और व्यवस्थित करें। आपके इंतज़ार करने के हर घंटे के साथ, स्टेटस पिंग, छूटे हुए हैंडऑफ़ और दोबारा काम करने (rework) में और ज़्यादा समय बर्बाद होता है।
किसी भी चीज़ को ऑटोमेट करने से पहले, हमें यह देखना होगा कि समय कहाँ और क्यों जा रहा है। फिर हमें ऐसे काम को अलग करने का तरीका चाहिए जिसे ऑटोमेट करना सुरक्षित हो, और उस काम को अलग करना होगा जो बार-बार होने वाला तो लगता है लेकिन असल में उसमें फ़ैसला लेने का जोखिम होता है। आखिर में, हमें ऑटोमेशन के लिए एक ऐसा लक्ष्य चुनने का साफ़ तरीका चाहिए जो डिलीवरी में मदद करे, न कि कोई नई समस्या या विफलता (failure mode) पैदा करे।
समस्या को ठीक से समझने के लिए, इस स्प्रिंट टाइमलाइन को देखें और गौर करें कि तालमेल कहाँ बिगड़ रहा है और काम कहाँ बस धीमा चल रहा है।
यह पैटर्न आमतौर पर तीन जगहों पर दिखता है। जब प्लान एक जगह नहीं दिखता, तो स्टेटस की रिक्वेस्ट बढ़ जाती हैं; जब ‘काम पूरा होने की परिभाषा’ (Definition of Done) साफ़ नहीं होती, तो हैंडऑफ़ (काम का हस्तांतरण) फेल हो जाते हैं; और जब ज़िम्मेदारी साफ़ नहीं होती, तो काम में रुकावटें (ब्लॉकर) बनी रहती हैं। PM अक्सर एक आम गलती करते हैं कि वे सबसे पहले स्टेटस अपडेट को ऑटोमेट करते हैं क्योंकि यह स्टेकहोल्डर्स को तुरंत मददगार लगता है। नतीजा यह होता है कि टीम वही कन्फ्यूजन तेज़ी से आगे बढ़ाती है और अब सिस्टम पर कम भरोसा करती है, क्योंकि ऑटोमेटेड रिपोर्टिंग ज़मीनी हकीकत से अलग होती है।
जब कोई स्टेप बार-बार दोहराया जाने वाला लगे, तो पूछें कि असल में वह किस तरह का काम है। कुछ स्टेप्स फैसले लेने वाले होते हैं, जैसे स्कोप में बदलाव को मंज़ूरी देना या रिलीज़ की तारीख चुनना। कुछ स्टेप्स हैंडऑफ़ होते हैं, जैसे टिकट को ‘बिल्ड’ से ‘टेस्ट’ में ले जाना या कैंपेन एसेट को लीगल टीम को सौंपना। कुछ स्टेप्स डेटा एंट्री वाले होते हैं, जैसे टूल्स के बीच फ़ील्ड्स को कॉपी करना या वीकली अपडेट को फ़ॉर्मेट करना। ऑटोमेशन तब सबसे सुरक्षित होता है जब स्टेप डेटा एंट्री का हो और इनपुट स्थिर हों।
फैसलों में बहुत ज़्यादा बदलाव की गुंजाइश होती है और गलत फैसले की कीमत अक्सर बाद में पता चलती है। बिना सही गाइडलाइंस के उन्हें ऑटोमेट करने से सही समझ (जजमेंट) सिर्फ़ अंदाज़ा बन जाती है। हैंडऑफ़ तब फेल होते हैं जब भूमिकाएँ और स्वीकार्यता के मानदंड (acceptance criteria) साफ़ नहीं होते, इसलिए ऑटोमेशन तभी मदद कर सकता है जब हम यह तय कर लें कि ‘तैयार’ होने का क्या मतलब है और कौन ज़िम्मेदार है। डेटा एंट्री वह जगह है जहाँ AI शुरू में ही मदद कर सकता है, क्योंकि हम इसे ऑडिट कर सकते हैं, दोबारा चला सकते हैं और रैंडम चेक (स्पॉट चेक) कर सकते हैं।
इस तुलना वाली एक्टिविटी का इस्तेमाल करके यह पहचानने की प्रैक्टिस करें कि कौन से स्टेप्स ऑटोमेट करने के लिए काफ़ी स्थिर हैं और किनमें इंसानी समझ की ज़रूरत है।