सिटिजन डेवलपमेंट सर्वशक्तिमान नहीं—यह 'ड्राफ्ट डेवलपमेंट' है 5/7 भाग
प्रस्तावना
चौथी कड़ी में हमने देखा कि कोड में न लिखे गए संसाधन भविष्य की नकारात्मक विरासत बन जाते हैं। यहाँ हम फिर पूछना चाहेंगे—क्या सिटिजन डेवलपमेंट प्रोडक्शन सिस्टम बनाने की विधि है?
सीधा उत्तर है कि सिटिजन डेवलपमेंट प्रोडक्शन का ढांचा नहीं है। उसका सार यह है कि उपयोगकर्ता दृष्टि की आवश्यकताओं को “चलते-फिरते रूप” में उतारने वाला ‘ड्राफ्ट डेवलपमेंट’ है।
यदि इस नज़रिए के बिना सिटिजन डेवलपमेंट को “कोई भी तुरंत सिस्टम बना ले” वाला जादुई औज़ार समझ लिया गया, तो इतिहास की तरह फिर से नकारात्मक विरासत की बाढ़ आ जाएगी। तो आइए देखें कि ‘ड्राफ्ट डेवलपमेंट’ का अर्थ क्या है और इसे कैसे उपयोग में लाना चाहिए।
पूरी श्रृंखला
- सिटिजन डेवलपमेंट का भविष्य देखने की कोशिश── इतिहास, वर्तमान, जेनरेटिव एआई और आगे 0/7(जापानी संस्करण)
- सिटिजन डेवलपमेंट क्या EUC की वापसी है?── कामी एक्सेल से मिली ऐतिहासिक सीख 1/7(जापानी संस्करण)
- क्या ‘कामी एक्सेल’ सचमुच खलनायक था?── उद्धारकर्ता से नकारात्मक विरासत तक 2/7
- आधुनिक सिटिजन डेवलपमेंटट प्लेटफ़ॉर्म का उजाला और अंधेरा 3/7
- जनरेटिव एआई कौन-सी विरासत बचाएगा, किन्हें छोड़ेगा 4/7
- सिटिजन डेवलपमेंट सर्वशक्तिमान नहीं—यह ‘ड्राफ्ट डेवलपमेंट’ है 5/7(यह लेख)
- दृष्टिकोण का अंतर नकारात्मक विरासत कैसे पैदा करता है 6/7
- सिटिजन डेवलपमेंट का भविष्य दृष्टि── विरासत जन्म लेती रहती है, फिर भी उसे वश में करो 7/7(जापानी संस्करण)
‘ड्राफ्ट डेवलपमेंट’ का मूल्य क्या है
सिटिजन डेवलपमेंट के तहत बने ऐप या टूल को अक्सर “अधूरा” या “खुरदुरा” कहा जाता है। लेकिन वही “खुरदरापन” इसका मूल्य है।
उपयोगकर्ता दृष्टि की आवश्यकताएँ उभर आती हैं
कल्पना कीजिए कि बिक्री विभाग ने लो-कोड से ग्राहक प्रबंधन ऐप बनाया है। उसमें रोज़मर्रा के काम में महसूस होने वाला “ऐसा न हो तो मुश्किल होगी” वाला अनुभव सीधे झलकता है।
- इनपुट फ़ील्ड का स्तर और बारीकियाँ
- सूची दृश्य में किन जानकारी को रखना है
- बटन की व्यवस्था और प्रवाह कितना सहज है
ये बातें केवल “आवश्यकता दस्तावेज़” से स्पष्ट नहीं होतीं। शब्दों में विनिर्देश लिखने पर भी उपयोगकर्ता की बारीकी और “काम की संवेदना” छूट जाती है। चलते-फिरते प्रोटोटाइप से ही “यह चलेगा” या “वास्तव में असुविधाजनक है” जैसी प्रतिक्रियाएँ वास्तविक रूप में सामने आती हैं।
गलतफ़हमियों और कमियों का शीघ्र पता चलना
जब हाथ में चलता हुआ ड्राफ्ट हो तो “यहाँ खोज सुविधा न हो तो परेशानी होगी”, “अनुमोदन फ्लो तीन चरण नहीं, दो चरण होना चाहिए” जैसी आवश्यकताओं की गलत पहचान या कमी जल्दी पकड़ में आ जाती है।
पारंपरिक विकास में अक्सर “आवश्यकता दस्तावेज़ पढ़कर विशेषज्ञ ने कल्पना से डिज़ाइन किया” जाता था। परिणामस्वरूप सिस्टम बनने के बाद “सोचा था उससे अलग” जैसी शिकायतें उठतीं और रीवर्क सामान्य बात थी। सिटिजन डेवलपमेंट ऐसे व्यर्थ रीवर्क को घटाने वाला मजबूत हथियार बन सकता है।
प्रोडक्शन में सीधे ले जाने का जाल
फिर भी ड्राफ्ट को जस का तस प्रोडक्शन बनाना खतरनाक है। इसके पीछे बड़े जाल छिपे हैं।
- स्केलेबिलिटी: छोटा विभाग इसे चला लेता है, पर पूरे संगठन में लागू करते ही प्रदर्शन की सीमा टूट जाती है।
- सुरक्षा: पहुँच नियंत्रण या लॉग प्रबंधन कमजोर रहते हैं, जिससे ऑडिट और अनुपालन की शर्तें पूरी नहीं हो पातीं।
- रखरखाव: काम व्यक्ति-निर्भर रह जाता है; निर्माता के स्थानांतरित या सेवानिवृत्त होते ही सब ब्लैक बॉक्स बन जाता है।
अर्थात “ड्राफ्ट में मूल्य है” और “ड्राफ्ट को ही प्रोडक्शन बना दो” बिल्कुल अलग बातें हैं। ऐसा किया तो वही संरचना दोहराई जाएगी जिसने कामी एक्सेल को अस्थायी उद्धारकर्ता से नकारात्मक विरासत में बदल दिया।
विशेषज्ञों के साथ भूमिकाओं का विभाजन
तो सिटिजन डेवलपमेंट के परिणामों का क्या करें? उत्तर स्पष्ट है।
- सिटिजन = ड्राफ्ट तैयार करें: उपयोगकर्ता दृष्टि को ठोस रूप दें और प्रोटोटाइप पेश करें।
- विशेषज्ञ = स्वच्छ प्रतिलिपि बनाएँ: विस्तारयोग्यता, सुरक्षा और रखरखाव जैसी गैर-कार्यात्मक आवश्यकताओं को पूरा करते हुए प्रणाली को फिर से बनाएं।
इस भूमिकाविभाजन को सख्ती से लागू करने पर दोनों पक्ष अपनी ताकतों को अधिकतम कर सकते हैं। सिटिजन अपने “जमीनी अनुभव” को सीधे टूल में ढालते हैं। विशेषज्ञ गुणवत्ता और स्थायित्व की गारंटी देने वाली स्वच्छ प्रतिलिपि तैयार करते हैं।
पारंपरिक तरीकों में जहाँ “आवश्यकता दस्तावेज़ के भरोसे कल्पना से डिज़ाइन” किया जाता था, वहाँ ड्राफ्ट की मौजूदगी से शुरुआत से ही अधिक स्पष्ट बहस संभव होती है। इससे विकास दक्षता बढ़ती है और अंतिम सिस्टम की गुणवत्ता बेहतर होती है।
गवर्नेंस से क्या बचाना है
सिटिजन डेवलपमेंट को स्वस्थ रूप से चलाने के लिए संगठनात्मक नियम अनिवार्य हैं।
- स्पष्टता: “सिटिजन डेवलपमेंट के परिणाम प्रोटोटाइप तक सीमित रहेंगे, और उनका उपयोग भी सीमित दायरे में होगा” यह स्पष्ट नीति बनाएं।
- सूचीकरण: छोड़े गए ऐप या RPA को नियमित रूप से सूचीबद्ध करें और आवश्यकता पड़ने पर उन्हें समाप्त करने की प्रक्रिया रखें।
- स्थानांतरण प्रक्रिया: उपयोगी ड्राफ्ट को हमेशा आईटी विभाग को सौंपें ताकि वे स्वच्छ प्रतिलिपि बनाकर प्रोडक्शन में लाएँ। इस प्रवाह को संगठन की औपचारिक प्रक्रिया बनाएं।
ऐसी गवर्नेंस व्यवस्था से कामी एक्सेल जैसी नकारात्मक विरासत को फिर से जन्म देने का जोखिम काफी घट जाता है। उलटे, यदि नियम न हों तो सिटिजन डेवलपमेंट “अनियंत्रित ऐप निर्माता” बन जाएगा और तकनीकी ऋण ही बढ़ेगा।
सारांश
सिटिजन डेवलपमेंट “हर कोई प्रोडक्शन सिस्टम बना ले” वाला सर्वशक्तिमान तंत्र नहीं है। लेकिन जब इसे “ड्राफ्ट” के रूप में इस्तेमाल किया जाए तो यह आवश्यकताओं की गलतफ़हमी और कमी घटाता है और उपयोगकर्ता दृष्टि से भरे डिज़ाइन को संभव बनाता है।
प्रोडक्शन की जिम्मेदारी विशेषज्ञों की है, ड्राफ्ट बनाने का काम सिटिजन का। इस भूमिकाविभाजन को निभाने से सिटिजन डेवलपमेंट नकारात्मक विरासत नहीं बल्कि भविष्य की उत्पादकता सुधार का आधार बनता है।
दूसरे शब्दों में, सिटिजन डेवलपमेंट का वास्तविक अर्थ “लोकतंत्रीकृत आवश्यकताओं की परिभाषा प्रक्रिया” में है। यह समझ होने पर ही सिटिजन डेवलपमेंट संगठन के लिए टिकाऊ शक्ति बन सकता है।
अगली कड़ी: दृष्टिकोण का अंतर नकारात्मक विरासत कैसे पैदा करता है 6/7