1.7 इंजीनियरिंग मानक और अपवाद

अवलोकन और प्रेरणा

एक इंजीनियरिंग मानक (engineering standard) एक दस्तावेज़ीकृत, सहमत नियम है कि काम कैसे किया जाता है। उदाहरण के लिए, “सभी सेवाओं को एक हेल्थ-चेक एंडपॉइंट प्रस्तुत करना चाहिए,” या “सभी सार्वजनिक वेब पेजों को WCAG (Web Content Accessibility Guidelines) 2.2 लेवल AA को पूरा करना चाहिए।” मानक कोई सुझाव नहीं है, और न ही महज़ एक परंपरा है। यह एक ऐसी प्रतिबद्धता है जिसका पालन संगठन स्वयं करता है, आदर्श रूप से ऐसी जिसे आप जांच सकें। यह अध्याय मानकों के पूरे जीवनचक्र के बारे में है (कि एक बड़ा संगठन उन्हें कैसे लिखता, प्रकाशित करता, अपनाता, लागू करता, और विकसित करता है) और, उतना ही महत्वपूर्ण, यह कि वह उन मामलों को कैसे संभालता है जो वैध रूप से मानकों के दायरे से बाहर आते हैं, एक शासित अपवाद प्रक्रिया (exceptions process) (जिसे छूट प्रक्रिया / waiver process भी कहा जाता है) के माध्यम से: किसी बताए गए कारण के लिए किसी मानक से हटने की एक दस्तावेज़ीकृत, समय-सीमित अनुमति।

प्रेरणा यह है कि बड़े पैमाने पर, अनौपचारिक मानदंड काम करना बंद कर देते हैं। जब पांच इंजीनियर एक ही कमरे में होते हैं, तो “हम यहां चीज़ें कैसे करते हैं” बातचीत और रिसाव (osmosis) से फैलता है। जब पांच हज़ार इंजीनियर दर्जनों टीमों, तीन समय क्षेत्रों, और एक दशक के स्टाफ टर्नओवर में फैले होते हैं, तो वह अनकहा ज्ञान सैकड़ों असंगत स्थानीय आदतों में बंट जाता है। मानक वह तरीका हैं जिससे आप अपने कठिन परिश्रम से सीखे गए पाठों को एक बार लिखते हैं, ताकि हर टीम उन्हें विरासत में पाए, न कि हर एक को अपने ही आउटेज से दोबारा सीखे। वे संज्ञानात्मक भार को घटाते हैं, कोड समीक्षाओं को शैली के बजाय सार के बारे में बनाते हैं, लोगों को टीमों के बीच आने-जाने देते हैं, और ऑडिटरों तथा नियामकों को आकलन करने के लिए कुछ ठोस देते हैं।

लेकिन मानकों में अपनी एक विफलता की स्थिति होती है: कठोरता (rigidity)। ऐसा मानक जो कोई अपवाद स्वीकार नहीं करता, देर-सबेर वैध कार्य को रोक देगा: एक स्पाइक, कोई विक्रेता की बाध्यता, कोई सचमुच नया मामला जिसकी लेखकों ने कभी कल्पना ही नहीं की थी। टीमें फिर या तो ठप हो जाती हैं, या इससे भी बुरा, चुपचाप मानक की अनदेखी कर देती हैं, जिससे हर मानक की विश्वसनीयता क्षीण होती है। इसका उपाय वह पुरानी कहावत है “अपवाद नियम को सिद्ध करता है (the exception proves the rule)।” एक दृश्यमान, सिद्धांतबद्ध अपवाद प्रक्रिया ही वह चीज़ है जो मानकों को विश्वसनीय और मानवीय दोनों बनाए रखती है। यह अध्याय निर्णय-निर्माण और गवर्नेंस (अध्याय 1.5) और निर्णय अभिलेखों (अध्याय 1.6) पर आधारित है, और सीधे कोडिंग मानकों और शैली (अध्याय 2.1), चेकलिस्टों (अध्याय 12.2), और टेम्पलेटों (अध्याय 12.3) में समाहित होता है।

मुख्य सिद्धांत

एक मानक एक परिणाम बताता है, और एक कारण देता है। नियम के साथ तर्काधार; क्यों के बिना, लोग यह नहीं आंक सकते कि यह वास्तव में कब लागू होता है।
यदि इसे जांचा नहीं जा सकता, तो यह अभी मानक नहीं है। आकांक्षाओं की तुलना में परीक्षण-योग्य कथनों को प्राथमिकता दें।
मानक जीवंत दस्तावेज़ हैं। उन्हें वर्ज़न किया जाता है, स्वामित्व दिया जाता है, तारीख दी जाती है, और संशोधित किया जाता है, पत्थर पर नहीं खोदा जाता और छोड़ दिया नहीं जाता।
जहां संभव हो प्रवर्तन को स्वचालित करें; मानवीय समीक्षा को निर्णय (judgment) के लिए सुरक्षित रखें। मशीनें यांत्रिक चीज़ें जांचती हैं; लोग सार्थक चीज़ें जांचते हैं।
विचलन अपेक्षित हैं, शर्मनाक नहीं, लेकिन उन्हें दृश्यमान होना चाहिए। एक ईमानदार छूट हर बार चुपचाप अनुपालन न करने से बेहतर है।
हर अपवाद को समय-सीमित करें। एक स्थायी अपवाद मानक में एक दोष है; उसे सामने लाएं और मानक को ठीक करें।
शब्दजाल और आदेशों की तुलना में शब्द और उदाहरण बेहतर हैं। लोग उन मानकों का पालन करते हैं जिन्हें वे समझते हैं और जिनसे नक़ल कर सकते हैं।

सिफारिशें

ऐसे मानक लिखें जो स्पष्ट, परीक्षण-योग्य, और न्यायोचित हों

एक अच्छा मानक एक छोटा, स्वतः-निहित दस्तावेज़ है जिसका आकार पूर्वानुमेय हो ताकि पाठकों को पता हो कि कहां देखना है। एक मानक टेम्पलेट (अध्याय 12.3) अपनाएं और इसे हर जगह उपयोग करें। आवश्यक अनुभागों में शामिल हैं:

शीर्षक और पहचानकर्ता: उद्धरण के लिए एक स्थिर नाम और संदर्भ संख्या।
स्थिति: ड्राफ्ट, सक्रिय, अधिस्थापित (superseded), या सेवानिवृत्त, तारीख के साथ।
नियम: एक परिणाम के रूप में, स्पष्ट और असंदिग्ध रूप से बताया गया (“must,” “should,” “may,” जिनका उपयोग जानबूझकर RFC 2119 के आवश्यकता कीवर्ड परंपराओं के अनुसार किया गया हो)।
तर्काधार: यह नियम क्यों मौजूद है; वह लागत या जोखिम जिसे यह रोकता है।
उदाहरण: एक अनुपालक उदाहरण और एक गैर-अनुपालक उदाहरण; ठोस, अमूर्त से बेहतर है।
इसे कैसे जांचा जाता है: वह स्वचालित परीक्षण, लिंटर नियम, या समीक्षा चरण जो इसे सत्यापित करता है।
स्वामी और समीक्षा तिथि: इसे कौन बनाए रखता है और इसे अगली बार कब दोबारा देखा जाएगा।

तर्काधार और “इसे कैसे जांचा जाता है” फ़ील्ड ही वे चीज़ें हैं जो एक वास्तविक मानक को एक इच्छा से अलग करती हैं। यदि आप यह नहीं बता सकते कि कोई नियम क्यों मौजूद है, तो सवाल करें कि क्या उसे होना चाहिए। यदि आप यह नहीं बता सकते कि अनुपालन कैसे सत्यापित किया जाता है, तो नियम असंगत रूप से लागू किया जाएगा और उससे नाराज़गी होगी।

हर मानक को एक अच्छी-प्रथा चेकलिस्ट के साथ जोड़ें

मानक गंतव्य को परिभाषित करते हैं। एक अच्छी-प्रथा चेकलिस्ट (good-practice checklist), पुष्टि करने योग्य ठोस चरणों या वस्तुओं की एक छोटी, क्रमबद्ध सूची, लोगों को वहां पहुंचने में मदद करती है और उन्हें समीक्षा से पहले स्वयं-सत्यापन करने देती है। सार्वजनिक-क्षेत्र की इंजीनियरिंग पुस्तिकाएं इस पैटर्न का भारी उपयोग करती हैं। NHS Wales और Digital Health and Care Wales (DHCW) व्यावहारिक चेकलिस्टों के साथ इंजीनियरिंग मानक प्रकाशित करते हैं, और UK Government Digital Service (GDS) अपने Service Standard और Technology Code of Practice को Service Manual के कार्रवाई-योग्य मार्गदर्शन के साथ जोड़ता है। चेकलिस्ट मानक का उपयोग-योग्य रूप है: “क्या आपने एक एक्सेसिबिलिटी ऑडिट जोड़ी है? क्या आपने स्क्रीन रीडर से परीक्षण किया है? क्या आपने कीबोर्ड-केवल नेविगेशन को कवर किया है?” चेकलिस्ट पैटर्न के पूर्ण विवरण के लिए अध्याय 12.2 देखें।

मानकों को वहां प्रकाशित करें जहां लोग पहले से काम करते हैं, और उन्हें खोजने योग्य बनाए रखें

मानकों को Markdown के रूप में वर्ज़न कंट्रोल (एक सोर्स रिपॉज़िटरी) में संग्रहीत करें, जिन्हें एक खोजने-योग्य आंतरिक साइट पर रेंडर किया जाए, ताकि उन्हें इतिहास, पुल रिक्वेस्ट के माध्यम से समीक्षा, और डिफ़ मुफ़्त में मिलें, वही तर्क जो निर्णय अभिलेखों (अध्याय 1.6) के लिए है। एक कैटलॉग, एक टेम्पलेट, एक खोज बॉक्स। सतह पर लाना (surfacing) भंडारण जितना ही मायने रखता है। संबंधित मानक को पुल-रिक्वेस्ट टेम्पलेट, लिंटर के एरर संदेश, और सेवा के स्कैफ़ोल्डिंग से लिंक करें, ताकि सही नियम काम के क्षण पर सामने आए, न कि किसी ऐसे फ़ोल्डर में जिसे कोई नहीं देखता।

पहले स्वचालन के माध्यम से, फिर मानवीय समीक्षा के माध्यम से लागू करें

किसी मानक को लागू करने के दो तरीके हैं, और परिपक्व संगठन दोनों का जानबूझकर उपयोग करते हैं:

स्वचालित प्रवर्तन: लिंटर, फ़ॉर्मेटर, स्टैटिक विश्लेषण, पॉलिसी-एज़-कोड (उदाहरण के लिए, Open Policy Agent (OPA)), सतत एकीकरण (CI) गेट, और आर्किटेक्चर फ़िटनेस फ़ंक्शन (स्वचालित परीक्षण जो यह दावा करते हैं कि कोई डिज़ाइन गुण अभी भी बना हुआ है)। स्वचालन सुसंगत, अथक, तत्काल, और निर्विवाद है, जो इसे मानकों के यांत्रिक बहुसंख्य (फ़ॉर्मेटिंग, नामकरण, निर्भरता नियम, आवश्यक मेटाडेटा) के लिए आदर्श बनाता है।
मानवीय समीक्षा: कोड समीक्षा, आर्किटेक्चर समीक्षा बोर्ड, और सुरक्षा समीक्षा, उस चीज़ के लिए सुरक्षित जिसे मशीनें आंक नहीं सकतीं: क्या कोई एब्स्ट्रैक्शन सुदृढ़ है, क्या कोई ट्रेड-ऑफ बुद्धिमानीपूर्ण है, क्या किसी मानक का आशय (intent) पूरा होता है भले ही उसका शब्द असहज हो।

अंगूठे का नियम: जो जांचा जा सकता है उसे स्वचालित करें, और दुर्लभ मानवीय ध्यान को निर्णय पर खर्च करें। हर मानक जिसे आप समीक्षा से CI में ले जा सकते हैं, समीक्षकों को उस सोच के लिए मुक्त करता है जो केवल वे कर सकते हैं।

विचलनों को एक दस्तावेज़ीकृत अपवाद/छूट प्रक्रिया के साथ शासित करें

कोई भी मानक हर मामले में फिट नहीं बैठता, इसलिए बचने के रास्ते (escape hatch) को जानबूझकर डिज़ाइन करें। एक अच्छी अपवाद प्रक्रिया यह निर्दिष्ट करती है:

छूट कौन दे सकता है: जोखिम के अनुपात में एक नामित, जवाबदेह प्राधिकरण (एक कम-दांव वाली शैली विचलन के लिए एक तकनीकी प्रमुख; एक सुरक्षा-नियंत्रण छूट के लिए एक आर्किटेक्चर या सुरक्षा बोर्ड)। यह सीधे अध्याय 1.5 के गवर्नेंस मॉडल से जुड़ता है।
क्या दर्ज किया जाना चाहिए: वह मानक जिससे विचलन किया जा रहा है, विशिष्ट कारण, दायरा, प्रतिपूरक नियंत्रण या शमन (mitigations), और स्वीकार किया गया जोखिम। इसे एक निर्णय अभिलेख (अध्याय 1.6) के रूप में दर्ज करें ताकि तर्काधार सुरक्षित रहे।
एक अनिवार्य समाप्ति तिथि: हर छूट एक स्पष्ट अंतिम तिथि के साथ समय-सीमित होती है। यह सबसे महत्वपूर्ण नियम है: यह किसी अस्थायी अपवाद को चुपचाप स्थायी नीति बनने से रोकता है।
आवधिक समीक्षा: एक स्वामी खुली छूटों की एक निश्चित अंतराल पर समीक्षा करता है और या तो उन्हें ताज़ा न्यायोचन के साथ नवीनीकृत करता है, जब कार्य अनुपालक हो जाए तो उन्हें बंद कर देता है, या, यदि वही अपवाद बार-बार होता रहे, तो इसे इस प्रमाण के रूप में मानता है कि मानक स्वयं गलत है और उसे संशोधित करता है।

यह अंतिम बिंदु “अपवाद नियम को सिद्ध करता है” का सार है। किसी एक मानक के विरुद्ध छूटों की एक निरंतर धारा अनुशासन की विफलता नहीं है। यह डेटा है। यह आपको बताती है कि मानक गलत तरीके से कैलिब्रेट किया गया है, और समाधान मानक को विकसित करना है, अपवाद देते रहना नहीं।

मानकों को स्पष्ट स्वामित्व के साथ जीवंत दस्तावेज़ों के रूप में मानें

हर मानक को एक स्वामी (एक भूमिका, केवल एक व्यक्ति नहीं) दें जो उसे वर्तमान बनाए रखने के लिए जवाबदेह हो, और एक समीक्षा अंतराल (कम से कम वार्षिक)। किसी भी व्यक्ति के लिए पुल रिक्वेस्ट या RFC (request for comments) के माध्यम से बदलाव प्रस्तावित करने का एक हल्का रास्ता प्रदान करें, एक लिखित प्रस्ताव जिसे अपनाए जाने से पहले प्रतिक्रिया के लिए प्रसारित किया जाता है। मानकों को वर्ज़न करें, उन्हें स्पष्ट रूप से अप्रचलित (deprecate) घोषित करें, और बदलावों की घोषणा करें। एक मानक कैटलॉग जिसे कभी संशोधित नहीं किया जाता, लोककथा (folklore) में सड़ जाता है जिसे लोग चुनिंदा रूप से उद्धृत करते हैं और जिस पर कम भरोसा करते हैं।

समझौते: लाभ और हानि

विकल्प	लाभ	हानि
कई विस्तृत मानक	संगति, आसान ऑनबोर्डिंग, ऑडिट-तैयार	कठोरता; रखरखाव का बोझ; अभ्यास से आगे निकल सकते हैं
कुछ उच्च-स्तरीय मानक	लचीले; कम रखरखाव	असंगति; प्रति टीम अधिक पुनः-बहस
स्वचालित प्रवर्तन	सुसंगत, तत्काल, अथक, स्केलेबल	अग्रिम लागत; झूठी सकारात्मकताएं; आशय के प्रति अंधा
मानवीय समीक्षा प्रवर्तन	आशय और बारीकी को आंकता है	धीमा, असंगत, बड़े पैमाने पर एक बाधा (बॉटलनेक)
सख़्त, कोई अपवाद नहीं	सरल संदेश; धोखा देने को कुछ नहीं	वैध कार्य को रोकता है; चुपचाप अनुपालन न करने को बढ़ावा देता है
शासित अपवाद प्रक्रिया	मानकों को विश्वसनीय और मानवीय बनाए रखती है	गवर्नेंस, अभिलेखों, और अनुसरण की आवश्यकता

केंद्रीय तनाव संगति बनाम लचीलेपन का है। एक मानक भिन्नता को हटाने के लिए मौजूद है; एक अपवाद प्रक्रिया उस भिन्नता को स्वीकार करने के लिए मौजूद है जो वास्तव में न्यायोचित है। कठोरता की ओर बहुत अधिक झुकें और लोग आपके मानकों के इर्द-गिर्द रास्ता निकाल लेंगे। ढिलाई की ओर बहुत अधिक झुकें और मानकों का कोई अर्थ नहीं रह जाता। अपवाद प्रक्रिया वह दबाव वाल्व है जो आपको एक दृढ़ रेखा बनाए रखने और वास्तविकता के बारे में ईमानदार बने रहने देती है।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

आपके पैमाने के लिए सही संख्या कितने मानकों की है, और क्या आपके मानक कठोरता की ओर या असंगति की ओर बहक रहे हैं? कैटलॉग स्वयं एक ट्रेड-ऑफ है: कई विस्तृत मानक कठोरता और रखरखाव के बोझ की कीमत पर संगति, आसान ऑनबोर्डिंग, और ऑडिट-तैयारी खरीदते हैं, जबकि कुछ उच्च-स्तरीय मानक लचीले तो रहते हैं लेकिन हर टीम को वही सवाल दोबारा तय करने देते हैं। किसी बड़े एंटरप्राइज़ या सरकारी निकाय के लिए, सही आकार इस पर निर्भर करता है कि आप वास्तव में कितनी भिन्नता सहन कर सकते हैं बनाम आपके ऑडिटरों और आपकी ऑनबोर्डिंग को कितना तय किया जाना चाहिए। प्रमाण लाएं: आपके पास कितने सक्रिय मानक हैं, पिछले साल कितनों की समीक्षा हुई, और टीमें कितनी बार उन चीज़ों पर दोबारा बहस करती हैं जिन्हें कोई मानक सुलझा सकता था। एक कैटलॉग जो अभ्यास से आगे निकल जाता है, लोककथा बन जाता है, और एक जो बहुत पतला है वह हर टीम पर लागत डाल देता है। जानबूझकर तय करें कि किसे मानक बनने योग्य है, और उन्हें छांट दें जो अब अपने अस्तित्व को उचित नहीं ठहराते।
किसी मानक का शब्द स्वचालित रूप से पास हो जाता है जबकि उसका आशय चुपचाप उल्लंघित होता है, और आप इसे कहां पकड़ेंगे? स्वचालन सुसंगत, अथक, और आशय के प्रति अंधा है, जिसका अर्थ है कि एक लिंटर या पॉलिसी जांच हरा (green) दिखा सकती है जबकि असली लक्ष्य (एक सुदृढ़ एब्स्ट्रैक्शन, एक बुद्धिमानीपूर्ण ट्रेड-ऑफ, सचमुच एक्सेसिबल पेज) चूक जाता है। अंगूठे का नियम है जो जांचा जा सकता है उसे स्वचालित करना और दुर्लभ मानवीय समीक्षा को निर्णय पर खर्च करना, और कठिन हिस्सा यह सहमत होना है कि किन मानकों का ऐसा आशय है जिसे कोई CI गेट दावा नहीं कर सकता। उदाहरण लाएं: ऐसे मानक जिन्हें लोग शाब्दिक रूप से संतुष्ट करते हैं जबकि उद्देश्य को हरा देते हैं, जैसे एक हेल्थ-चेक एंडपॉइंट जो स्वस्थ रिपोर्ट करता है जबकि सेवा टूटी हुई है, या ऐसा कोड जो फ़ॉर्मेटर से गुज़र जाता है लेकिन अर्थ को धुंधला कर देता है। विनियमित परिवेशों में, आशय सुरक्षा और संरक्षा (security) नियंत्रणों के लिए सबसे ज़्यादा मायने रखता है, जहां एक हरा चेकबॉक्स असली जोखिम छुपा सकता है। तय करें कि कौन-से मानक विशेष रूप से आशय आंकने के लिए एक मानवीय समीक्षक रखते हैं, और उन मानकों को परिणाम के इर्द-गिर्द शब्दबद्ध करें ताकि मशीन और समीक्षक दोनों एक ही लक्ष्य को निशाना बनाएं।
छूट-से-मानक फीडबैक लूप का स्वामी कौन है, और किस बिंदु पर एक बार-बार होने वाला अपवाद आपको नियम बदलने के लिए मजबूर करता है? किसी एक मानक के विरुद्ध छूटों की एक निरंतर धारा अनुशासनहीनता नहीं बल्कि डेटा है, और यह संकेत तब तक बर्बाद होता है जब तक कोई इसे पढ़ने और उस पर कार्रवाई करने के लिए जवाबदेह न हो। प्रतिस्पर्धी विचार यह है कि किसी मानक को संशोधित करना वास्तविक काम है, इसलिए उसके नीचे की गलत-कैलिब्रेटेड नियम को ठीक करने की तुलना में छूटों पर मुहर लगाते रहना आसान बना रहता है। संख्याएं लाएं: कौन-से मानक सबसे अधिक अपवाद उत्पन्न करते हैं, क्या छूटें वास्तव में समय-सीमित हैं और एक निश्चित अंतराल पर समीक्षा की जाती हैं, और कितनी चुपचाप स्थायी बन गईं। एंटरप्राइज़ और सरकार में सुरक्षा-महत्वपूर्ण और संरक्षा-महत्वपूर्ण मानकों के लिए, एक छूट को प्रतिपूरक नियंत्रण, एक शमन, स्वीकार किया गया जोखिम, और एक कठोर समाप्ति तिथि दर्ज करनी चाहिए, अन्यथा एक अस्थायी विचलन एक अदस्तावेज़ीकृत नीति बन जाता है जो अगले ऑडिट में सामने आता है। खुली छूटों की समीक्षा के लिए एक स्वामी नियुक्त करें, एक सीमा तय करें जिस पर बार-बार होने वाले अपवाद मानक संशोधन को ट्रिगर करें, और एक स्थायी अपवाद को मानक में ठीक किए जाने वाले दोष के रूप में मानें।
क्या सही मानक काम के क्षण पर सामने आता है, या यह किसी ऐसे फ़ोल्डर में रहता है जिसे कोई नहीं खोलता? एक मानक जिसे कोई नहीं ढूंढ सकता वह भाग्य से लागू होता है, और बड़े पैमाने पर अधिकतर गैर-अनुपालन अवज्ञा नहीं बल्कि अज्ञानता है: एक इंजीनियर को कभी पता ही नहीं था कि नियम मौजूद है या जब मायने रखता था तब वह उसे ढूंढ नहीं सका। प्रतिस्पर्धी विचार प्रयास है, क्योंकि पुल-रिक्वेस्ट टेम्पलेट, लिंटर के एरर संदेश, और सेवा स्कैफ़ोल्डिंग में किसी मानक को सतह पर लाने में वास्तविक एकीकरण कार्य लगता है जो एक एकल केंद्रीय साइट नहीं करती। खोजने-योग्यता के बारे में प्रमाण लाएं: इंजीनियर आज वास्तव में मानकों को कैसे ढूंढते हैं, क्या कोई नया कर्मचारी एक मिनट से कम समय में उस एक्सेसिबिलिटी या सुरक्षा नियम को ढूंढ सकता है जो उसके कार्य को नियंत्रित करता है, और समीक्षक कितनी बार ऐसे मानक का हवाला देते हैं जिसे लेखक ने बस देखा ही नहीं था। किसी बड़े एंटरप्राइज़ या सरकारी निकाय के लिए, ऑडिटर तेज़ी से न केवल यह पूछ रहे हैं कि क्या कोई मानक मौजूद है बल्कि यह भी कि क्या वह निर्णय के बिंदु पर संप्रेषित और सुलभ था, इसलिए सतह पर लाने को मानक का हिस्सा मानें, बाद का विचार नहीं, और मापें कि क्या लोग जब उन्हें ज़रूरत हो तब नियम तक पहुंच सकते हैं।
हर सक्रिय मानक का स्वामी कौन है, इसकी आखिरी बार समीक्षा कब हुई, और आप उन मानकों को कैसे पहचानेंगे जो चुपचाप लोककथा में सड़ गए हैं? मानक चुपचाप क्षय होते हैं: तीन साल पहले किसी ऐसे फ्रेमवर्क के लिए लिखा गया नियम जिसका आप अब उपयोग नहीं करते, अभी भी कैटलॉग में बैठा है, चुनिंदा रूप से उद्धृत होता है और कम भरोसा किया जाता है, उन मानकों की विश्वसनीयता को खींचता है जो अभी भी सही हैं। किसी बड़े संगठन के लिए स्वामित्व की लागत स्वयं समीक्षा अंतराल है, जो तब तक एक बोझ जैसा महसूस होता है जब तक कोई आउटेज या ऑडिट ऐसे मानक को उजागर नहीं करता जो अब वास्तविकता से मेल नहीं खाता। चर्चा में संख्याएं लाएं: कितने मानकों का एक नामित स्वामी है (एक भूमिका, केवल एक चला गया व्यक्ति नहीं), पिछले साल कितनों की समीक्षा हुई, कितने औपचारिक रूप से अप्रचलित घोषित हैं बनाम बस बासी हैं, और किनका सबसे अधिक और सबसे कम हवाला दिया जाता है। एंटरप्राइज़ और सरकारी परिवेशों में, एक ऑडिटर उम्मीद करता है कि हर मानक वर्ज़न किया गया, तारीखयुक्त, और प्रदर्शनीय रूप से वर्तमान हो, इसलिए एक न्यूनतम समीक्षा अंतराल पर सहमत हों, हर मानक को एक जवाबदेह स्वामी सौंपें, और उन्हें सेवानिवृत्त करें जो अब अपने अस्तित्व को उचित नहीं ठहराते इससे पहले कि वे बाकी पर भरोसे को कमज़ोर करें।
क्या छूट देने का अधिकार वास्तव में उस मानक के जोखिम के अनुपात में है जिसे छूट दी जा रही है? एक शैली विचलन और एक सुरक्षा-नियंत्रण विचलन एक जैसा निर्णय नहीं है, फिर भी कई संगठन या तो दोनों को एक भारी-भरकम बोर्ड के पास भेजते हैं (जो वैध कार्य को ठप कर देता है) या दोनों को एक ही तकनीकी प्रमुख के माध्यम से फिसल जाने देते हैं (जो एक गंभीर जोखिम को किसी ऐसे व्यक्ति द्वारा स्वीकार करवाता है जिसके पास उसे स्वीकार करने का जनादेश नहीं है)। तनाव जवाबदेही के विरुद्ध गति का है: बहुत अधिक स्वीकृति घर्षण चुपचाप गैर-अनुपालन को बढ़ावा देता है, जबकि बहुत कम का मतलब है कि महत्वपूर्ण विचलन एक चैट थ्रेड में लहरा दिए जाते हैं। अपने मानकों का उनके स्वीकृति प्राधिकरणों के साथ एक मानचित्र लाएं, साथ ही हाल ही में दी गई छूटों का एक नमूना, और जांचें कि क्या किसी ने संबंधित बोर्ड, प्रतिपूरक नियंत्रण, शमन, और दर्ज जोखिम स्वीकृति के बिना किसी सुरक्षा-महत्वपूर्ण या संरक्षा-महत्वपूर्ण नियंत्रण को छूट दे दी। एंटरप्राइज़ और सरकार के लिए, यह कर्तव्यों के पृथक्करण (separation of duties) का प्रश्न है जिसकी नियामक सीधे जांच करते हैं, इसलिए मानकों के हर वर्ग को उसके जोखिम के अनुपात में एक नामित प्राधिकरण से जोड़ें, और सुनिश्चित करें कि जोखिम स्वीकार करने वाला व्यक्ति वास्तव में परिणामों के लिए जवाबदेह है।

क्षेत्रीय दृष्टिकोण

स्टार्टअप। कैटलॉग को छोटा रखें: केवल उन कुछ नियमों को लिखें जिनकी अनुपस्थिति वास्तव में आपको नुकसान पहुंचाएगी, जैसे एक फ़ॉर्मेटर कॉन्फ़िग, एक हेल्थ-चेक आवश्यकता, और कीबोर्ड-नेविगेबल पेज, और प्रत्येक को समीक्षा बैठक के बजाय एक लिंटर या CI जांच से लागू करें। छूट बोर्ड को पूरी तरह छोड़ दें; इस पैमाने पर कोड में एक तारीखयुक्त TODO और पुल रिक्वेस्ट में एक-पंक्ति का नोट एक बिल्कुल ठीक समय-सीमित अपवाद है। आपका सबसे दुर्लभ संसाधन इंजीनियरिंग का ध्यान है, इसलिए उन समस्याओं के लिए मानक लिखने से बचें जो आपके पास अभी नहीं हैं।

छोटा व्यवसाय। बिना किसी समर्पित मानक स्वामी और एक तंग बजट के साथ, अपने मानकों को बनाने के बजाय खरीदें: UK GDS Service Standard, OWASP सुरक्षा मार्गदर्शन, या अपने फ्रेमवर्क के अनुशंसित लिंट नियमों जैसे प्रकाशित आधाररेखाओं को अपनाएं, और अपने टूल तथा होस्टेड CI में पहले से बने चेकों पर निर्भर रहें। उन कुछ चीज़ों के लिए जो वास्तव में आपके लिए विशिष्ट हैं, स्थानीय नियमों का एक छोटा पेज रखें। जो भी इंजीनियरिंग का नेतृत्व करता है वह टिकट में अपवाद देता और दर्ज करता है, एक समाप्ति तिथि के साथ, ताकि एक हल्की प्रक्रिया भी ईमानदार बनी रहे।

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

सरकार। अपने इंजीनियरिंग मानकों को DHCW और GDS परंपरा में खुले तौर पर प्रकाशित करें, और प्रत्येक को एक चेकलिस्ट के साथ जोड़ें जिसे टीमें सेवा मूल्यांकन से पहले पूरा करती हैं, ताकि अनुपालन जनता और निगरानी निकायों के लिए दृश्यमान हो। एक नामित वरिष्ठ जवाबदेह स्वामी को महत्वपूर्ण छूटों का प्राधिकरण बनाएं, और हर अपवाद को विशिष्ट मानदंड, प्रतिपूरक नियंत्रण या अंतरिम शमन, एक उपचार योजना, और एक कठोर समाप्ति तिथि दर्ज करने की आवश्यकता रखें। खरीद और पारदर्शिता नियमों का मतलब है कि आपके मानक और आपके विचलन दोनों सार्वजनिक रिकॉर्ड का हिस्सा बन जाते हैं, इसलिए ऑडिटेबिलिटी और ट्रेसेबिलिटी को शुरू से ही डिज़ाइन आवश्यकताओं के रूप में मानें।

उदाहरण

स्टार्टअप। सात लोगों की एक स्टार्टअप ठीक तीन लिखित मानक रखती है (एक साझा फ़ॉर्मेटर कॉन्फ़िग, एक हेल्थ-चेक एंडपॉइंट आवश्यकता, और “सभी सार्वजनिक पेज कीबोर्ड-नेविगेबल होने चाहिए”), प्रत्येक को समीक्षा बैठक के बजाय एक लिंटर या CI जांच से लागू किया जाता है। जब एक इंजीनियर को एक फेंक-देने-योग्य प्रोटोटाइप शिप करना होता है जो हेल्थ-चेक नियम को तोड़ता है, तो कोई छूट बोर्ड नहीं होता: वह कोड में एक तारीखयुक्त TODO और पुल रिक्वेस्ट में यह बताते हुए एक-पंक्ति का नोट छोड़ती है कि क्यों और कब वह इसे ठीक करेगी। यह स्टार्टअप के पैमाने पर एक समय-सीमित अपवाद है, ईमानदार और दृश्यमान, बिना किसी प्रक्रिया के बोझ के। तीनों जांच कोड समीक्षा को शैली के बजाय सार के बारे में रखकर अपनी लागत वसूल कर लेती हैं।

एंटरप्राइज़। एक वैश्विक बैंक लगभग चालीस सक्रिय मानकों की एक आंतरिक इंजीनियरिंग पुस्तिका बनाए रखता है, प्रत्येक एक टेम्पलेट में एक तर्काधार, उदाहरणों, और एक लिंक की गई अच्छी-प्रथा चेकलिस्ट के साथ। लगभग 70% स्वचालित रूप से लागू होते हैं: फ़ॉर्मेटिंग, निर्भरता नीति, अनिवार्य सेवा मेटाडेटा, और पॉलिसी-एज़-कोड के रूप में एन्कोड किए गए सुरक्षा नियंत्रण जो CI पाइपलाइन को विफल कर देते हैं। एक भुगतान टीम को एक ऐसे डेटाबेस पर शिप करना होता है जो अभी तक एक अनिवार्य एन्क्रिप्शन फ़ीचर का समर्थन नहीं करता। रिलीज़ को रोकने के बजाय, वे मानक का नाम लेते हुए, प्रतिपूरक नियंत्रण (एप्लिकेशन-लेयर एन्क्रिप्शन), और 90-दिन की समाप्ति तिथि के साथ एक छूट दाखिल करते हैं। सुरक्षा बोर्ड इसे स्वीकृत करता है और दर्ज करता है। नब्बे दिन बाद, समीक्षा में पता चलता है कि प्लेटफ़ॉर्म अब उस फ़ीचर का मूल रूप से समर्थन करता है, और छूट बंद कर दी जाती है। मानक बना रहा, काम शिप हुआ, और विचलन अगले ऑडिट के लिए पूरी तरह ट्रेस करने योग्य है।

सरकार। DHCW और GDS दृष्टिकोण पर आधारित एक राष्ट्रीय स्वास्थ्य एजेंसी अपने इंजीनियरिंग मानकों को खुले तौर पर प्रकाशित करती है, प्रत्येक को एक चेकलिस्ट के साथ जोड़ा गया है जिसे टीमें सेवा मूल्यांकन से पहले पूरा करती हैं। WCAG 2.2 AA तक एक्सेसिबिलिटी एक कठोर मानक है, जिसे CI में एक स्वचालित ऑडिट प्लस एक मैनुअल मूल्यांकन द्वारा लागू किया जाता है। एक विरासती (legacy) क्लिनिकल सिस्टम रोगी-सुरक्षा-महत्वपूर्ण कार्यक्षमता को जोखिम में डाले बिना तुरंत एक एक्सेसिबिलिटी मानदंड को पूरा नहीं कर सकता। टीम एक समय-सीमित अपवाद का अनुरोध करती है। एक नामित वरिष्ठ जवाबदेह स्वामी इसे स्वीकृत करता है, और विशिष्ट मानदंड, अंतरिम शमन (एक सहायता-प्राप्त पहुंच फ़ोन लाइन), उपचार योजना, और छह महीने की समाप्ति तिथि दर्ज करता है, ठीक वही ट्रेस-योग्य, समीक्षा-योग्य प्रमाण बनाते हुए जिसकी निगरानी निकायों को आवश्यकता होती है (अध्याय 4.6, 10.4)।

व्यावसायिक मामला: प्रेरणाएं, ROI, और TCO

एक मानक की लागत उसे लिखने, उसकी जांच को स्वचालित करने, और उसे बनाए रखने में लगने वाला समय है। प्रतिफल हर बार तब चुकता है जब जांच चलती है, और हर बार जब किसी इंजीनियर को रुककर किसी सुलझे हुए सवाल पर बहस नहीं करनी पड़ती। मानक बार-बार होने वाली, बिखरी हुई निर्णय लागत को एक बार की लेखन लागत में बदल देते हैं, वही अर्थशास्त्र जो निर्णय अभिलेखों (अध्याय 1.6) का है, प्रवर्धित इसलिए क्योंकि एक मानक हज़ारों भविष्य के उदाहरणों को नियंत्रित करता है, न कि एक अतीत की पसंद को।

कुल स्वामित्व लागत (TCO) पर, किसी सिस्टम को बनाने, चलाने, और बनाए रखने की पूर्ण आजीवन लागत, मानक सबसे बड़ी लाइन-आइटमों को घटाते हैं: ऑनबोर्डिंग (नए कर्मचारी संगति को रिवर्स-इंजीनियर करने के बजाय उसे विरासत में पाते हैं), रखरखाव (एक समान कोड बदलने में सस्ता है), और आश्वासन (ऑडिट तब सस्ते होते हैं जब अनुपालन मशीन-जांच-योग्य हो और विचलन पहले से ही दस्तावेज़ीकृत हों)। अपवाद प्रक्रिया उस ROI को उसके मुख्य खतरे से बचाती है: मानकों का उपेक्षित लोककथा में क्षय होना। एक विश्वसनीय छूट प्रक्रिया मानकों पर भरोसा बनाए रखती है, और भरोसेमंद मानक ही वे हैं जिनका लोग वास्तव में पालन करते हैं। यह सब छोड़ने की लागत किसी भी डैशबोर्ड पर अदृश्य होती है। यह धीमी ऑनबोर्डिंग, असंगत गुणवत्ता, और ऑडिट निष्कर्षों के रूप में सामने आती है, और यह हर नई टीम और हर प्रस्थान के साथ बढ़ती जाती है।

एंटी-पैटर्न और नुकसान

बिना तर्काधार के नियम: एक मानक जिसे कोई नहीं समझता वह एक ऐसा मानक है जिसे कोई सही ढंग से लागू नहीं कर सकता या ईमानदारी से चुनौती नहीं दे सकता।
आकांक्षात्मक, अजांच-योग्य मानक: “कोड को बनाए रखने-योग्य होना चाहिए” एक मूल्य है, मानक नहीं; इसे लागू या चुनौती नहीं दी जा सकती।
कोई अपवाद प्रक्रिया नहीं: वैध कार्य को रोकने और चुपचाप गैर-अनुपालन को सहन करने के बीच एक झूठे विकल्प को मजबूर करता है।
स्थायी अपवाद: बिना समाप्ति तिथि की छूटें जो चुपचाप असली, अदस्तावेज़ीकृत नीति बन जाती हैं।
बिना अभिलेख के छूटें: गलियारे या चैट थ्रेड में दी गई छूटें, अगले ऑडिट और अगले इंजीनियर के लिए अदृश्य।
संकेत की अनदेखी करना: इसे इस प्रमाण के रूप में पढ़ने के बजाय कि मानक को बदलने की आवश्यकता है, वही अपवाद बार-बार देना।
कुरेदने-से-प्रवर्तन: समीक्षकों पर यह पकड़ने के लिए निर्भर रहना जो एक लिंटर को पकड़ना चाहिए था, यांत्रिक चीज़ों पर निर्णय बर्बाद करना।
मानकों का कब्रिस्तान: एक बार लिखा गया कैटलॉग, किसी का स्वामित्व नहीं, कभी समीक्षा नहीं की गई, चुनिंदा रूप से उद्धृत, कुछ ही लोगों द्वारा भरोसा किया गया।
शब्दजाल द्वारपाल-वृत्ति: मानक जो अपने पाठकों के बजाय अपने लेखकों के लिए लिखे गए हों, नक़ल करने के लिए कोई उदाहरण नहीं।

परिपक्वता मॉडल

स्तर 1 (आरंभ): मानक वरिष्ठ इंजीनियरों के दिमाग में जनजातीय ज्ञान हैं, प्रतिक्रियात्मक रूप से लागू किए गए। प्रवर्तन तदर्थ कोड-समीक्षा कुरेदना है; विचलन अदृश्य हैं; “हम इसे कैसे करते हैं” टीम-दर-टीम और किसने बदलाव की समीक्षा की, उसके अनुसार बदलता है।
स्तर 2 (विकास): कुछ मानक लिखे गए हैं, असंगत प्रारूपों और बिखरे हुए स्थानों में, और अपनाने की दर टीम-दर-टीम व्यापक रूप से बदलती है। प्रवर्तन अधिकतर मैनुअल है। अपवाद अनौपचारिक रूप से होते हैं, बिना अभिलेखों या समाप्ति तिथियों के।
स्तर 3 (मानकीकरण): एक एकल कैटलॉग, एक टेम्पलेट, हर मानक के लिए तर्काधार और उदाहरण, और अच्छी-प्रथा चेकलिस्ट, टीमों में सुसंगत रूप से लागू। यांत्रिक बहुसंख्य के लिए स्वचालित प्रवर्तन। नामित स्वीकृतिकर्ताओं, दर्ज तर्काधार, और समय-सीमित छूटों के साथ एक दस्तावेज़ीकृत अपवाद प्रक्रिया।
स्तर 4 (प्रबंधन): मानक प्रणाली को आधार रेखाओं के विरुद्ध मापा जाता है। आप स्वचालित रूप से बनाम मानवीय समीक्षा द्वारा लागू मानकों का हिस्सा, प्रति मानक छूट की मात्रा, बंद होने में लगने वाला समय, और कितनी छूटें खुली रहते हुए समाप्त हो गईं, ट्रैक करते हैं, और इन्हें गवर्नेंस फ़ंक्शन को रिपोर्ट करते हैं। स्वीकृति प्राधिकरण जोखिम के अनुपात में है और ऑडिट किया जाता है; समीक्षा अंतराल और समाप्ति को सद्भावना के बजाय प्रमाण पर लागू किया जाता है; एक मानक जिसकी छूट दर एक सहमत सीमा को पार करती है उसे संशोधन के लिए फ़्लैग किया जाता है।
स्तर 5 (ऑर्केस्ट्रेट): मानक काम के क्षण पर सामने आते हैं और पॉलिसी-एज़-कोड तथा फ़िटनेस फ़ंक्शनों द्वारा लागू किए जाते हैं। छूटों को संकेत के रूप में खोदा जाता है ताकि बार-बार होने वाले अपवाद लगातार मानकों को विकसित करने के लिए प्रेरित करें, और अभ्यास बदलने पर कैटलॉग को फिर से संतुलित किया जाता है। मानक, चेकलिस्ट, और छूटें एक अनुकूलनशील जीवंत प्रणाली हैं जो ऑनबोर्डिंग, डिलीवरी, और ऑडिट में एकीकृत है।

चर्चा के लिए विचार

आपके कौन-से मानक आप एक परीक्षण-योग्य नियम और एक स्पष्ट तर्काधार के साथ बता सकते हैं, और कौन-से वास्तव में बस आकांक्षाएं हैं?
आपके मानकों का कितना हिस्सा स्वचालित रूप से लागू होता है बनाम किसी समीक्षक के देखने से? दस और को CI में ले जाने के लिए क्या लगेगा?
आज विचलन कहां होते हैं, और क्या आपको पता भी चलेगा? क्या वे दर्ज और समय-सीमित हैं, या चुप?
आपके सबसे सुरक्षा- या संरक्षा-महत्वपूर्ण मानक के विरुद्ध छूट देने की अनुमति किसे है, और क्या वह प्राधिकरण जोखिम के अनुपात में है?
अपने सबसे अधिक छूट-प्राप्त मानक को देखें। क्या यह एक अनुशासन की समस्या है, या मानक बस गलत है?
हर सक्रिय मानक की आखिरी बार समीक्षा कब हुई थी, और इसका स्वामी कौन है? कौन-से चुपचाप लोककथा बन गए हैं?

मुख्य निष्कर्ष

एक इंजीनियरिंग मानक एक परिणाम के रूप में बताया गया नियम है, एक तर्काधार, उदाहरणों, और इसे जांचने के एक तरीके के साथ: यदि इसे जांचा नहीं जा सकता, तो यह अभी मानक नहीं है।
हर मानक को एक अच्छी-प्रथा चेकलिस्ट के साथ जोड़ें ताकि लोग स्वयं-सत्यापन कर सकें, सार्वजनिक-क्षेत्र पुस्तिका पैटर्न (NHS Wales / DHCW, UK GDS) का अनुसरण करते हुए।
मानकों को वर्ज़न कंट्रोल में संग्रहीत करें, उन्हें नामित स्वामियों और समीक्षा तिथियों के साथ जीवंत बनाए रखें, और उन्हें काम के क्षण पर सामने लाएं।
लिंटर, पॉलिसी-एज़-कोड, और फ़िटनेस फ़ंक्शनों के साथ जांच-योग्य को स्वचालित करें; निर्णय के लिए मानवीय समीक्षा सुरक्षित रखें।
विचलनों को एक दस्तावेज़ीकृत, समय-सीमित अपवाद/छूट प्रक्रिया के साथ शासित करें: नामित स्वीकृतिकर्ता, दर्ज तर्काधार, अनिवार्य समाप्ति, आवधिक समीक्षा।
एक बार-बार होने वाला अपवाद मानक को ठीक करने का संकेत है, न कि बस छूट देते रहने का: “अपवाद नियम को सिद्ध करता है।” अध्याय 1.5 (गवर्नेंस), 1.6 (निर्णय अभिलेख), 2.1 (कोडिंग मानक), 12.2 (चेकलिस्ट), और 12.3 (टेम्पलेट) देखें।

संदर्भ और आगे पढ़ने के लिए

UK Government Digital Service, Government Service Standard, Technology Code of Practice, and GOV.UK Service Manual.
NHS Digital / NHS England, Service Standard and engineering guidance.
Digital Health and Care Wales (DHCW) / NHS Wales, published engineering standards and good-practice checklists.
Scott Bradner, RFC 2119: Key Words for Use in RFCs to Indicate Requirement Levels (IETF, 1997).
World Wide Web Consortium (W3C), Web Content Accessibility Guidelines (WCAG) 2.2.
Neal Ford, Rebecca Parsons, and Patrick Kua, Building Evolutionary Architectures (fitness functions as automated governance).
Torin Sandall et al., Open Policy Agent documentation (policy-as-code).
GitLab, The GitLab Handbook: a public example of living, version-controlled organizational standards.
Google, Software Engineering at Google (Winters, Manshreck, Wright): standards, readability, and automated enforcement at scale.
Atul Gawande, The Checklist Manifesto: the case for checklists as professional practice.