चौहत्तर दिनों से भौतिक सीमा तक: Jensen Huang की "प्रकाश की गति" वाली सोच इंजीनियरिंग में क्या बदलती है
परिचय: समय-सारिणी समझने से पहले उसे बेहतर क्यों बनाएँ?
एक टीम कहती है कि किसी प्रक्रिया में चौहत्तर दिन लगते हैं। वह इसे बहत्तर दिन करने का प्रस्ताव देती है। प्रस्ताव प्रगति जैसा लगता है। लेकिन अगर अलग व्यवस्था में मूल काम छह दिनों में पूरा हो सकता हो तो?
ये संख्याएँ किसी विधि को समझाने का उदाहरण हैं, किसी खास परियोजना का वादा नहीं। Jensen Huang मौजूदा प्रक्रिया को शुरुआती बिंदु मानने से पहले उसकी मूल सीमा खोजने के लिए "प्रकाश की गति" वाली सोच का वर्णन करते हैं।
महत्वपूर्ण सवाल उन्हीं लोगों से अधिक मेहनत माँगने का नहीं है। सवाल यह है कि जरूरी काम और विरासत में मिली देरी के बीच अंतर कैसे करें।
1. मौजूदा प्रक्रिया एक साक्ष्य है, प्रकृति का नियम नहीं
स्थापित समय-सारिणी में कई अलग चीजें हो सकती हैं: भौतिक काम, इंतजार, अनुमतियाँ, जिम्मेदारी का हस्तांतरण, समूह में प्रसंस्करण [Batching] और ऐसे कारणों से किए गए समझौते जो अब लागू नहीं होते।
निरंतर सुधार [Continuous Improvement] उस मौजूदा व्यवस्था से शुरू होता है। वह पूछता है कि प्रक्रिया थोड़ी बेहतर कैसे बन सकती है।
मूल सिद्धांतों से तर्क [First-principles Reasoning] उससे पहले का सवाल पूछता है। वास्तव में क्या होना जरूरी है और उसे अलग ढंग से होने से क्या रोकता है?
इससे अनुभव बेकार नहीं हो जाता। अनुभवी लोग अक्सर ठीक-ठीक जानते हैं कि कोई कठिन चरण क्यों मौजूद है। उद्देश्य उन कारणों को फिर समझना है, न कि समय-सारिणी को ही स्पष्टीकरण मान लेना।
2. हर महत्वपूर्ण आयाम की सीमा खोजिए
"प्रकाश की गति" संबंधित सीमाओं के अंतर्गत संभव की सीमा का संक्षिप्त संकेत है। इसका अर्थ यह नहीं कि हर व्यापारिक गतिविधि वास्तव में प्रकाश के चलने की गति से सीमित है।
कंप्यूटिंग में इन आयामों में मेमोरी में डेटा का स्थानांतरण [Memory Movement], ऊर्जा, प्रतिक्रिया-विलंब [Latency], प्रसंस्करण दर [Throughput], लागत और निर्माण समय शामिल हो सकते हैं। कोई डिजाइन एक आयाम में अपनी सीमा के करीब हो सकता है, जबकि दूसरे में काफी गुंजाइश बची हो।
इन आयामों को अलग करना उपयोगी है। एक उत्तर जल्दी देने वाली प्रणाली, अनेक अनुरोधों को कुशलता से संसाधित करने के लिए बनाई गई प्रणाली से अलग हो सकती है। एक को अनुकूलित करना [Optimising] दूसरे को अपने-आप अनुकूलित नहीं करता।
सब कुछ अंतिम डिजाइन में जोड़ने से पहले टीम को समझना चाहिए कि हर उद्देश्य क्या माँगता है।
3. आदर्श आधाररेखा तय कीजिए, फिर अंतर समझाइए
छह दिनों का उदाहरण तभी उपयोगी बनता है जब बाकी अड़सठ दिनों की जाँच की जाए।
उस अंतर का कुछ हिस्सा उचित हो सकता है। धीमी प्रक्रिया की लागत कम हो सकती है, वह दुर्लभ उपकरण का अधिक न्यायसंगत इस्तेमाल कर सकती है या जरूरी निरीक्षण का अवसर दे सकती है। दूसरी देरी दोहराए जाने वाले निर्णयों या ऐसे क्रम से आ सकती है जिस पर हाल में किसी ने सवाल नहीं किया।
यह अभ्यास उन विकल्पों को सामने लाता है। दो दिन बचाए जा सकते हैं या नहीं, इस पर बहस करने के बजाय टीम चर्चा कर सकती है कि वह मूल आधाररेखा से कहीं बड़ा अंतर क्यों स्वीकार कर रही है।
इसलिए भौतिक न्यूनतम निर्णय के लिए एक संदर्भ बिंदु है। वह अपने-आप सही व्यावसायिक समय-सीमा नहीं बन जाता।
4. सरलता का अर्थ अनावश्यक जटिलता हटाना है
परिष्कृत कंप्यूटिंग प्रणाली में एक-दूसरे से संपर्क करने वाले कई हिस्से हो सकते हैं, फिर भी उसका उद्देश्य सरल हो सकता है। जटिलता तब समस्या बनती है जब वह उस उद्देश्य की सेवा किए बिना मौजूद हो।
Huang का तरीका यह पूछना है कि क्या कोई घटक, चरण या निर्भरता [Dependency] जरूरी है। अगर जरूरी है, तो उसे समझिए। अगर नहीं, तो पूछिए कि वह अब भी क्यों मौजूद है।
यह प्रणाली के हिस्से इतना हटाते जाने से अलग है कि वह अपना काम ही न कर सके। बिजली आपूर्ति, शीतलन, परीक्षण और विश्वसनीयता केवल इसलिए वैकल्पिक नहीं हो जाते कि वे आरेख को जटिल बनाते हैं।
उपयोगी लक्ष्य ऐसा डिजाइन है जिसमें जरूरतें पूरी करने लायक जटिलता हो, लेकिन ऐसी अतिरिक्त जटिलता न हो जो केवल आदत बनाए रखती है।
5. नेताओं को समझना चाहिए कि वास्तविक काम कहाँ होता है
परियोजना रिपोर्ट देरी का वर्णन करते हुए उसका कारण छिपा सकती है। जहाँ काम होता है, वहाँ स्पष्टीकरण अधिक साफ हो सकता है।
केबल कैसे लगाई जाती है? कोई घटक इंतजार क्यों करता है? कौन सा निर्णय अगले कार्य को रोकता है? ये सवाल व्यापक प्रणाली को उसे बनाने वाली छोटी कार्रवाइयों से जोड़ते हैं।
तत्परता तभी उपयोगी होती है जब वह वास्तविक बाधा हटाए। काम समझे बिना अधिक कठोर समय-सीमा बार-बार दोहराने से इंजीनियरिंग की प्रगति नहीं होती।
नेतृत्व को सीमा सामने लाने, सही विशेषज्ञता एकत्र करने और स्वीकार्य समझौते तय करने में मदद करनी चाहिए।
निष्कर्ष: सुधार का जश्न मनाने से पहले आधाररेखा पर सवाल कीजिए
"प्रकाश की गति" वाली सोच की ताकत क्यों पूछने का अनुशासन है। यही क्रम क्यों? इतना इंतजार क्यों? यही डिजाइन क्यों? कौन सी सीमाएँ भौतिकी से आती हैं और कौन सी विकल्पों से?
ये जवाब स्पष्ट होने पर निरंतर सुधार [Continuous Improvement] को बेहतर बुनियाद मिलती है। टीम विरासत में मिली प्रक्रिया को चमकाने के बजाय उस प्रक्रिया को सुधार सकती है जिसे वह समझती है।
यह विधि वादा नहीं करती कि चौहत्तर दिनों की हर परियोजना छह दिन में पूरी होगी। वह टीम से यह जानने को कहती है कि ऐसा क्यों नहीं होता। यह जानकारी उसके बाद आने वाले हर निर्णय की गुणवत्ता बदल देती है।
Powered By K7