नई सेवा बनाते समय कभी ऐसा मन होता है कि शुरुआत से ही सभी सुविधाओं से लैस एक संपूर्ण प्रणाली की रूपरेखा तैयार कर ली जाए। लगता है कि सदस्य प्रबंधन, भुगतान, सुझाव और आँकड़ों तक सब कुछ एक साथ डिज़ाइन करके एक ही बार में पूरा कर देना कहीं अधिक कुशल होगा। लेकिन अक्सर, जितने बड़े स्तर पर ऐसी परियोजनाओं की शुरुआत होती है, अंततः उनके ठीक से काम न करने की आशंका उतनी ही अधिक होती है। इस घटना को एक वाक्य में समेटने वाला अनुभवजन्य नियम ही ‘गॉल का नियम (Gall's Law)’ है।
सरल शब्दों में, गॉल के नियम का अर्थ है कि ‘अच्छी तरह काम करने वाली जटिल प्रणाली हमेशा पहले से अच्छी तरह काम कर रही किसी सरल प्रणाली से विकसित होती है।’ अमेरिकी बाल रोग विशेषज्ञ और लेखक जॉन गॉल (John Gall) ने प्रणालियों के विफल होने के तरीकों का अध्ययन करते हुए यह बात कही थी। आज सॉफ़्टवेयर डिज़ाइन और उत्पाद विकास में इसे अक्सर उद्धृत किया जाता है।
इस सामग्री में हम क्रम से देखेंगे कि गॉल के नियम की पृष्ठभूमि क्या थी, इसके तीन वाक्यों का क्या अर्थ है, इसके वास्तविक उदाहरण कौन-से हैं और व्यावहारिक काम में इस नियम का पालन कैसे किया जा सकता है।
सरलता से जटिलता की ओर विकसित होने वाली प्रणालियों का सिद्धांत
एक बाल रोग विशेषज्ञ की लिखी प्रणालियों की कहानी
जॉन गॉल एक बाल रोग विशेषज्ञ थे, जिन्होंने अमेरिका के मिशिगन राज्य के ऐन आर्बर में 40 वर्षों से अधिक समय तक बच्चों का इलाज किया। उन्होंने मिशिगन विश्वविद्यालय में बाल रोग के क्लिनिकल एसोसिएट प्रोफ़ेसर के रूप में भी काम किया। उनका मुख्य कार्य बच्चों के विकास और व्यवहार संबंधी समस्याओं से जुड़ा था, लेकिन वे अलग से समय निकालकर इस बात के उदाहरण जुटाते थे कि छोटी-बड़ी प्रणालियाँ अपेक्षा के अनुरूप काम क्यों नहीं करतीं।
- पहली पुस्तक (General Systemantics): 1975 में उन्होंने तब तक जुटाए गए विफलताओं के उदाहरणों और उनसे मिली सीख को ‘सामान्य प्रणालीशास्त्र’ नामक पुस्तक में प्रकाशित किया।
- पुनर्प्रकाशन (Systemantics): 2 वर्ष बाद, 1977 में यह ‘प्रणालीशास्त्र: प्रणालियाँ कैसे काम करती हैं और विशेष रूप से कैसे विफल होती हैं’ शीर्षक से दोबारा प्रकाशित हुई और व्यापक रूप से पढ़ी गई।
- संशोधित संस्करण (The Systems Bible): 1986 में लगभग दोगुने विस्तार वाला संस्करण 2 प्रकाशित हुआ और 2002 में संस्करण 3 ‘सिस्टम बाइबिल’ शीर्षक से आया।
इस पुस्तक ने मर्फ़ी के नियम और पीटर के सिद्धांत की तरह छोटे और चुटीले वाक्यों के माध्यम से प्रणालियों के गुणों को समझाया। इनमें सबसे प्रसिद्ध हुआ वाक्य आगे चलकर लोगों के बीच ‘गॉल का नियम’ कहलाने लगा। हालाँकि, पुस्तक में इसे यह नाम नहीं दिया गया था।
नियम को बनाने वाले तीन वाक्य
गॉल के नियम को आम तौर पर एक ही कथन के रूप में प्रस्तुत किया जाता है, लेकिन मूल पाठ में लगातार तीन वाक्य हैं।
(1) सफल जटिल प्रणालियों की शुरुआत सरल होती है
अच्छी तरह काम करने वाली किसी जटिल प्रणाली के विकास को पीछे की ओर देखें, तो हमेशा ऐसी सरल प्रणाली मिलती है जो अच्छी तरह काम कर रही थी। इसका अर्थ है कि जटिलता शुरू से डिज़ाइन नहीं की गई थी, बल्कि कार्यशील अवस्था बनाए रखते हुए धीरे-धीरे जुड़ती गई।
(2) शुरुआत से ही जटिल बनाई गई प्रणाली को सुधारकर इस्तेमाल भी नहीं किया जा सकता
गॉल ने दृढ़ता से कहा कि शून्य से एक ही बार में डिज़ाइन की गई जटिल प्रणाली काम नहीं करती और उसमें जोड़-तोड़ या पैबंद लगाकर भी उसे चलाया नहीं जा सकता। इसका कारण यह है कि उसके हिस्से आपस में किस तरह जुड़कर काम करेंगे, यह सब पहले से जानना संभव नहीं होता। काग़ज़ पर संपूर्ण दिखने वाला डिज़ाइन भी जब वास्तव में आपस में जुड़कर काम करने लगता है, तो कई जगह एक साथ अनपेक्षित टकराव सामने आने लगते हैं।
(3) फिर से किसी सरल चीज़ से शुरुआत करनी चाहिए
ऐसे में समाधान एक ही है। नई, सरल और काम करने वाली प्रणाली बनाएँ और वहीं से उसे फिर विकसित करें। इसका अर्थ है कि पहले लगाई गई मेहनत छोड़ना भले ही खले, लेकिन काम न करने वाले विशाल डिज़ाइन से चिपके रहने के बजाय छोटे स्तर पर दोबारा शुरुआत करना अंततः अधिक तेज़ होता है।
हालाँकि, गॉल ने इस कथन से पहले यह शर्त भी जोड़ी थी कि सरल प्रणाली काम कर भी सकती है और नहीं भी। उनका कहना यह नहीं था कि सरलता सफलता की गारंटी देती है, बल्कि यह था कि सफल जटिल प्रणालियों की शुरुआत सरल थी।
नियम को दर्शाने वाले उदाहरण
प्रणाली डिज़ाइनरों द्वारा उद्धृत किए जाने के साथ गॉल का नियम सूचना प्रौद्योगिकी के क्षेत्र में फैला। प्रणाली डिज़ाइनर केन ऑर (Ken Orr) ने 1981 में ही इस कथन का परिचय दिया था और 1991 से ऑब्जेक्ट ओरिएंटेड डिज़ाइन के प्रमुख विशेषज्ञ ग्रेडी बूच (Grady Booch) ने अपनी कई पुस्तकों में इसे बार-बार उद्धृत किया।
छोटी शुरुआत से विकसित हुआ वर्ल्ड वाइड वेब
वर्ल्ड वाइड वेब की शुरुआत एक बेहद सरल संरचना से हुई थी, जिसमें दस्तावेज़ों को लिंक से एक-दूसरे से जोड़ा जाता था। शुरू में यह शोधकर्ताओं के बीच सामग्री साझा करने का साधन था, लेकिन काम कर रहे मूल ढाँचे पर क्रमशः चित्र, खोज, खरीदारी और वीडियो जुड़ते गए और यह आज की विशाल प्रणाली बन गया। शुरुआत में ही इसके सभी उपयोग तय नहीं किए गए थे, इसलिए नई सुविधाएँ स्वाभाविक रूप से अपनी जगह बना सकीं।
शुरुआत से ही विशाल रूप में डिज़ाइन किया गया मानक
इसके विपरीत, शुरुआत से ही हर परिस्थिति को समेटने की कोशिश करने वाले जटिल तकनीकी विनिर्देश अक्सर व्यावहारिक उपयोग में अपनी जगह नहीं बना पाए। अलग-अलग प्रोग्रामों को जोड़ने वाले वितरित ऑब्जेक्ट मानक कॉर्बा (CORBA) का अक्सर ऐसे उदाहरण के रूप में उल्लेख किया जाता है, जिसकी शुरुआत विशाल विनिर्देशों से हुई, लेकिन जिसका व्यापक उपयोग नहीं हो पाया।
व्यावहारिक काम में गॉल के नियम का पालन कैसे करें
गॉल का नियम छोटे विकास चक्रों में निर्माण करने और बार-बार सुधारने वाले एजाइल विकास (Agile Software Development) के अनुकूल है। विशेष रूप से एक्सट्रीम प्रोग्रामिंग (Extreme Programming) यह सलाह देती है कि पहले सबसे सरल चीज़ बनाई जाए और सुविधाएँ बाद में जोड़ी जाएँ।
(1) पहले सबसे छोटा पूर्ण उत्पाद बनाएँ
पहले ऐसा न्यूनतम उत्पाद प्रस्तुत करें जो सुविधाएँ कम होने पर भी शुरू से अंत तक वास्तव में काम करता हो। उपयोगकर्ताओं की प्रतिक्रिया देखकर केवल आवश्यक चीज़ें जोड़ते जाने से अनुपयोगी डिज़ाइन पर लगने वाली मेहनत कम की जा सकती है।
(2) हमेशा कार्यशील अवस्था बनाए रखें
हर बार कोई सुविधा जोड़ने पर जाँचें कि प्रणाली अब भी ठीक से काम कर रही है या नहीं। एक ही बार में बड़ा बदलाव करने के बजाय छोटे बदलाव करके तुरंत परीक्षण करने से समस्या का कारण खोजना भी आसान होता है।
(3) जल्दबाज़ी में बनाए गए विशाल ढाँचों से सावधान रहें
आजकल कृत्रिम बुद्धिमत्ता वाले कोडिंग उपकरणों से बड़ी प्रणाली पल भर में बनाई जा सकती है, लेकिन तेज़ी से उसे जोड़ देने का अर्थ यह नहीं है कि गॉल द्वारा बताई गई विफलता से बचा जा सकता है। गति जितनी बढ़ती है, छोटी शुरुआत का सिद्धांत उतना ही अधिक महत्वपूर्ण हो जाता है।
गॉल का नियम जटिल प्रणालियाँ बनाने से मना नहीं करता, बल्कि यह सलाह देता है कि जटिलता तक पहुँचने का एक विशिष्ट रास्ता है। बड़े और शानदार डिज़ाइन की तुलना में आज ठीक से काम करने वाली एक छोटी प्रणाली आपको अधिक दूर तक ले जाती है।
छोटे स्तर पर बनाना, उसे ठीक से काम करने योग्य बनाना और फिर एक-एक कदम आगे बढ़ाते हुए उसका विस्तार करना—यही मज़बूत प्रणाली की दिशा में पहला कदम है।
