एक ऑटोमेशन प्रोजेक्ट में कितने दिन लगते हैं?

जब कोई ऑटोमेशन प्रोजेक्ट प्रस्तावित किया जाता है, तो पहला सवाल आमतौर पर होता है "कितने दिन लगेंगे"। इसका कोई एक सही जवाब नहीं है, क्योंकि अवधि असल में कितना कोड लिखा गया इससे तय नहीं होती। समान आकार दिखने वाले दो प्रोजेक्ट बहुत अलग हो सकते हैं — एक हफ़्ते में, दूसरा महीने भर में। यह अंतर डेटा की संरचना और शामिल निर्णयकर्ताओं की संख्या में होता है।

अवधि तय करने वाले तीन चरण

एक ऑटोमेशन प्रोजेक्ट में मोटे तौर पर तीन चरण होते हैं: डेटा और नियमों की तैयारी, निर्माण, और टेस्टिंग व मंज़ूरी। बताई गई समयसीमा आमतौर पर सिर्फ़ निर्माण चरण को कवर करती है। असल में सबसे ज़्यादा समय पहले और आख़िरी चरण में बर्बाद होता है।

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

डेटा की संरचना अवधि को कैसे प्रभावित करती है

अगर जानकारी एक ही जगह, लगातार तरीके से रखी है, तो निर्माण तेज़ी से आगे बढ़ता है। अगर वही जानकारी अलग-अलग फ़ाइलों में, अलग फ़ॉर्मेट में, आंशिक रूप से हाथ से रखी गई है, तो पहले इस गड़बड़ी को ठीक करना ज़रूरी है। किसी सिस्टम में स्प्रेडशीट को थोक में डालने के लिए ज़रूरी तैयारी के बारे में हमने इस लेख में बताया है; यही तर्क ऑटोमेशन प्रोजेक्ट की डेटा तैयारी पर भी लागू होता है।

व्यवहार में, सबसे ज़्यादा समय तब बर्बाद होता है जब प्रोजेक्ट की शुरुआत में मान लिया जाता है कि "डेटा पहले से साफ़ है", और गड़बड़ी बीच में जाकर पता चलती है। निर्माण शुरू करने से पहले नमूना डेटा की जाँच करना, बाद में पीछे जाने से तेज़ है।

निर्णयकर्ताओं की संख्या कोड की लाइनों से ज़्यादा मायने रखती है

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

एक ही निर्णयकर्ता वाला साधारण काम — जैसे स्वतः बनने वाली रिपोर्ट — कुछ दिनों में लाइव हो सकता है। कई विभागों को छूने वाली प्रक्रिया में समान तकनीकी दायरे के बावजूद ज़्यादा समय लगता है।

एक वास्तविक समयसीमा कैसे बनाएँ

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

• डेटा आज कहाँ है, और किस फ़ॉर्मेट में?
• अपवाद पहले से स्पष्ट हैं, या प्रोजेक्ट के दौरान सामने आएँगे?
• कौन मंज़ूरी देता है, और किस क्रम में?
• क्या टेस्टिंग के लिए असली नमूना डेटा तैयार है?

अगर इन सवालों का स्पष्ट जवाब दिया जा सके, तो बताई गई समयसीमा वास्तविकता के करीब होगी। अगर जवाब अस्पष्ट हैं, तो समयसीमा भी अस्पष्ट रहेगी — ऐसे में पहला कदम अनुमान देना नहीं, बल्कि इन अनिश्चितताओं को स्पष्ट करना है।

छोटे दायरे से शुरुआत समय घटाती है

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

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

सबसे तेज़ ऑटोमेशन प्रोजेक्ट कितनी जल्दी हो सकता है?

एक दोहराए जाने वाले काम, व्यवस्थित डेटा और एक ही निर्णयकर्ता वाला साधारण प्रोजेक्ट कुछ दिनों में लाइव हो सकता है। दायरा और मंज़ूरी देने वालों की संख्या समय बढ़ा देती है।

समय सबसे ज़्यादा किस वजह से बढ़ता है?

आमतौर पर कोड की वजह से नहीं, बल्कि बिखरे हुए डेटा और लंबी मंज़ूरी प्रक्रिया की वजह से। अलग-अलग समय पर कई लोगों को शामिल करने वाले प्रोजेक्ट, तकनीकी रूप से सरल होने पर भी हफ़्तों तक खिंच सकते हैं।

समय का अनुमान अक्सर भरोसेमंद क्यों नहीं होता?

क्योंकि अनुमान आमतौर पर सिर्फ़ निर्माण चरण को कवर करता है; डेटा तैयारी, टेस्टिंग और मंज़ूरी शामिल नहीं होते। एक वास्तविक अनुमान इन तीनों चरणों को अलग-अलग कवर करता है।