व्यवसायिक नियम ऐसे दस्तावेज़ित करें कि टीम बदलने पर भी बने रहें

टीम परिवर्तन के बाद नियम क्यों गायब हो जाते हैं

व्यवसायिक नियम अक्सर एक बार में पूरी तरह से गायब नहीं होते। वे तब फीके पड़ते हैं जब कोई व्यक्ति चला जाता है और संदर्भ अपने साथ ले जाता है।

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

समस्या हैंडओवर के समय शुरू होती है। नए साथी आम तौर पर ऐप का एक्सेस, कुछ नोट्स, और एक त्वरित वॉकथ्रू पाते हैं। वे सीख लेते हैं कि कहां क्लिक करना है, पर यह नहीं कि नियम क्यों है, कब लागू होता है, या कौन इसे बदल सकता है। जो दिया जाता है वह प्रक्रिया की सतह होती है, अंदर की लॉजिक नहीं।

यह इसलिए है कि हैंडओवर तब भी फेल होते हैं जब लोग अच्छा करने का इरादा रखते हैं। लोग स्टेप्स बताते हैं जैसे 'रिक्वेस्ट को मंज़ूर करें' या 'इसे रिव्यू में भेजें', पर उन स्टेप्स के पीछे छिपे निर्णय छोड़ देते हैं। नया टीम‑मेंबर खुश‑पाथ एक बार फॉलो कर सकता है, पर परिस्थिति बदलते ही अटक जाता है।

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

यह उन ऐप्स में आम है जहाँ वर्कफ़्लो बदलते रहते हैं। AppMaster जैसे विज़ुअल प्लेटफ़ॉर्म में टीमें जल्दी लॉजिक बना सकती हैं, जो उपयोगी है। पर गति तभी मदद करती है जब हर एक एक्शन के पीछे का नियम भी सरल भाषा में स्पष्ट हो। वरना वर्कफ़्लो ऐप में रहता है जबकि उसका मतलब किसी के दिमाग में रह जाता है।

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

हर व्यवसायिक नियम में क्या होना चाहिए

एक व्यवसायिक नियम उस व्यक्ति के लिए समझ में आना चाहिए जिसने उसे बनाया न हो। यदि कोई नया साथी छह महीने बाद खोले, तो उसे चार बुनियादी सवालों के जवाब मिलने चाहिए: क्या घटना नियम शुरू करती है, क्या सत्य होना चाहिए, उसके बाद क्या होता है, और इसका मालिक कौन है।

अगर इन में से कोई भी हिस्सा गायब है, लोग अनुमान लगाते हैं। अनुमान गलत चरण, असंगत निर्णय और ऐसे ऐप्स देते हैं जो इस बात पर अलग व्यवहार करते हैं कि आख़िर किसने उन्हें आख़िरी बार बदला था।

एक स्पष्ट नियम में आम तौर पर पाँच हिस्से होते हैं:

• ट्रिगर - वह घटना जो नियम शुरू करती है
• शर्तें - वे तथ्य जो लागू होने से पहले सत्य होने चाहिए
• एक्शन - ऐप या टीम अगले क्या करेगी
• ओनर - वह भूमिका जो नियम को सही बनाए रखने के लिए जिम्मेदार है
• अपवाद - वे मामले जहाँ सामान्य नियम लागू नहीं होना चाहिए

ट्रिगर को एक वास्तविक घटना के रूप में लिखें, किसी धुंधले पल के रूप में नहीं। 'जब एक ऑर्डर को शिप्ड मार्क किया जाता है' स्पष्ट है। 'शिपिंग के बाद' स्पष्ट नहीं है।

शर्तों को इस तरह लिखें कि कोई और व्यक्ति बिना प्रश्न पूछे उनका परीक्षण कर सके। 'इनवॉइस 7 दिनों के लिए ओवरड्यू है' काम करता है। 'इनवॉइस लेट है' नहीं। वही नियम एक्शन पर भी लागू होता है। 'रिमाइंडर ईमेल भेजें और स्टेटस को Follow‑up needed में बदलें' कहीं बेहतर है बनाम 'टीम को सूचित करें'।

ओनर इसलिए मायने रखता है क्योंकि नियम जल्दी पुराने हो जाते हैं। एक डिस्काउंट अप्रूवल नियम Sales Operations का हो सकता है। एक रिफंड नियम Support या Finance का हो सकता है। जब कोई ओनर नहीं लिखा होता, तो पुरानी लॉजिक ऐप में ही रहती है क्योंकि कोई भी इसे ठीक करने के लिए ज़िम्मेदार नहीं समझता।

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

एक सरल फ़ॉर्मेट जिसे आप दोहरा सकते हैं

एक अच्छा नियम फ़ॉर्मेट एक सवाल का शीघ्र उत्तर देना चाहिए: क्या होता है, कब होता है, और कौन जिम्मेदार है?

सबसे आसान तरीका है हर नियम के लिए एक पेज, कार्ड या डेटाबेस रिकॉर्ड रखना। यह सरल सुनाई देता है, पर यह मायने रखता है। जब कई नियम एक ही दस्तावेज़ में मिल जाते हैं, छोटे‑छोटे अपवाद दब जाते हैं और ownership अस्पष्ट हो जाती है।

हर नियम की शुरुआत एक छोटा नाम और एक लाइन के उद्देश्य से करें। नाम को घटना को बताना चाहिए, अंदरूनी जार्गन नहीं। 'इनवॉइस को ओवरड्यू मार्क करें' 'AR status logic 3B' से स्पष्ट है। उद्देश्य बताता है कि नियम क्यों मौजूद है, जैसे 'भुगतान देर होने पर फाइनेंस को अलर्ट करने के लिए'।

दोहराने योग्य नियम टेम्पलेट

हर बार एक ही क्रम का प्रयोग करें:

• नियम का नाम
• उद्देश्य
• ट्रिगर
• शर्तें
• एक्शन
• ओनर
• अपवाद
• प्रभावी तिथि और अंतिम समीक्षा तिथि
• वर्शन नोट्स

यह क्रम काम करता है क्योंकि यह वही क्रम है जिसमें लोग सोचते हैं। पहले क्या नियम शुरू करता है। फिर क्या सत्य होना चाहिए। फिर ऐप को क्या करना चाहिए। अंत में कौन तय करेगा कि नियम अभी भी सही है।

प्रत्येक फ़ील्ड छोटी रखें। एक ट्रिगर आम तौर पर एक घटना होती है, जैसे 'ग्राहक ने फॉर्म जमा किया' या 'इनवॉइस की ड्यू डेट आ गई'। शर्तें सरल चेक हों, जैसे 'राशि $500 से ऊपर है' या 'ग्राहक खाता सक्रिय है'। एक्शन दृश्य परिणाम होते हैं: संदेश भेजना, स्टेटस बदलना, टास्क बनाना, या अनुरोध ब्लॉक करना।

ओनर फ़ील्ड को न छोड़ें। ओनर केवल उस व्यक्ति का नाम नहीं है जिसने सिस्टम में नियम टाइप किया; यह वह भूमिका है जो तय करती है कि नियम अभी भी बिजनेस से मेल खाता है या नहीं।

अपवाद, तिथियाँ और वर्शन नोट्स के लिए भी जगह रखें, भले वे शुरू में अनावश्यक लगें। नियम बदलते हैं। कोई पूछेगा कि किसी शर्त को क्यों जोड़ा गया, कब थ्रेशहोल्ड बदला गया, या क्या पुराना अपवाद अभी भी लागू है। एक छोटा नोट जैसे 'v2: नीति अपडेट के बाद लिमिट $250 से $500 कर दी' कई घंटे बचा सकता है।

अगर आपकी टीम AppMaster का उपयोग करके वर्कफ़्लो‑भारी ऐप बनाती है, तो यह फ़ॉर्मेट विज़ुअल लॉजिक के साथ अच्छी तरह मिल जाता है। लिखित नियम ट्रिगर, निर्णय और एक्शन फ्लो के बगल में रखे जा सकते हैं, ताकि ऐप व्यवहार और बिजनेस अर्थ दोनों मेल में रहें।

कदम‑दर‑कदम: नियम कैसे लिखें

छोटे से शुरू करें। पूरे सिस्टम से शुरुआत न करें। किसी एक वर्कफ़्लो की एक घटना चुनें, जैसे 'नया ऑर्डर unpaid मार्क हुआ' या 'सपोर्ट टिकट क्लोज़ हुआ'। एक ही घटना नियम को पढ़ने और बाद में अपडेट करने में आसान रखती है।

फिर ट्रिगर को एक सादा वाक्य में लिखें। अच्छे ट्रिगर ठीक‑ठीक बताते हैं कि नियम कब शुरू होता है: 'जब ग्राहक रिफंड अनुरोध जमा करे'। 'यदि आवश्यक हो' या 'जब उपयुक्त हो' जैसे धुंधले शब्दों से बचें। अगर दो लोग वाक्य पढ़कर अलग‑अलग पल का ख्याल कर सकें, तो उसे फिर से लिखें।

अगले चरण में शर्तों को हाँ‑या‑ना चेक में बदलें। इससे नियम टेस्टेबल बनता है। 'हाई‑वैल्यू ग्राहक के लिए' लिखने के बजाय लिखें 'क्या ग्राहक प्राथमिकता सपोर्ट प्लान पर है?' या 'क्या ऑर्डर टोटल $500 से ऊपर है?' स्पष्ट चेक बहस हटाते हैं।

फिर एक्शन को सटीक शब्दों में परिभाषित करें। '1 घंटे के अंदर भुगतान रिमाइंडर ईमेल भेजें' स्पष्ट है। 'जल्दी फॉलो‑अप करें' नहीं। अगर एक्शन डेटा बदलता है, तो फील्ड का नाम दें। अगर यह संदेश भेजता है, तो बताएं किसे जाता है। अगर यह टास्क बनाता है, तो कहें कहाँ दिखाई देगा।

ओनर को भूमिका के रूप में नामित करें, व्यक्ति के रूप में नहीं। लोग छोड़ते हैं, जॉब बदलते हैं, या एक‑दूसरे की जगह कवर करते हैं। 'Support manager' 'Emma' से लंबे समय तक लागू रहता है। अगर एक भूमिका नियम को अप्रूव करती है और दूसरी उसे निष्पादित करती है, दोनों का नाम दें।

सहेजने से पहले कहीं और किसी अनजान व्यक्ति से पढ़वाएं। उन्हें बिना अतिरिक्त संदर्भ के तीन सवालों के जवाब मिल जाने चाहिए: क्या शुरू करता है? क्या सत्य होना चाहिए? अगले क्या होगा? अगर वे हिचकिचाते हैं, तो नियम में अभी भी अंतर हैं।

ऐप वर्कफ़्लो में एक वास्तविक उदाहरण

कस्टमर सपोर्ट एक अच्छा टेस्ट केस है क्योंकि प्रक्रिया अक्सर बदलती है और छोटी गलतियाँ असल प्रभाव डालती हैं। अगर नोट्स अस्पष्ट हों, तो अगला व्यक्ति एक ही टिकट को बिलकुल अलग तरीके से हैंडल कर सकता है।

कल्पना कीजिए एक सपोर्ट ऐप जहाँ एजेंट इनकमिंग रिक्वेस्ट को ट्रायेज़ करते हैं। एक साझा नियम उन अर्जेंट टिकट्स को कवर करता है जिन्हें सामान्य कतार से तेज़ ध्यान की जरूरत है।

उदाहरण: सपोर्ट एस्केलेशन नियम

Rule name: हाई‑वैल्यू खातों के लिए अर्जेंट टिकट एस्केलेशन

Trigger: एक सपोर्ट एजेंट किसी टिकट को Urgent के रूप में मार्क करता है

Conditions: ग्राहक Premium या Enterprise प्लान पर है, या टिकट को पहली प्रतिक्रिया के बिना 30 मिनट से अधिक इंतज़ार हुआ है

Actions: ऐप ऑन‑ड्यूटी सपोर्ट लीड को नोटिफिकेशन भेजता है, टिकट को एस्केलेशन कतार में असाइन करता है, और स्टेटस को Escalated में अपडेट करता है

Owner: Customer Support Operations Manager

Exception: यदि टिकट पहले से किसी इंजीनियर को असाइन है जो एक सक्रिय आउटेज पर काम कर रहा है, तो ऐप उसे फिर से असाइन नहीं करता। यह मौजूदा असाइनी को रखता है, सपोर्ट लीड के लिए एक इंटरनल नोट जोड़ता है, और स्टेटस को In Progress पर छोड़ देता है

अब एक वास्तविक केस का विचार करें। एक Enterprise खाते का ग्राहक पासवर्ड पॉलिसी परिवर्तन के बाद लॉगिन नहीं कर पा रहा है। एजेंट टिकट को Urgent मार्क करता है। चूँकि अकाउंट टाइप नियम से मेल खाता है, ऐप तुरंत एस्केलेट कर देता है, भले ही पहली‑प्रतिक्रिया टाइमर ने 30 मिनट पूरे न किए हों।

एक अलग केस दिखाता है कि अपवाद क्यों मायने रखता है। ज्ञात आउटेज के दौरान एक अर्जेंट टिकट आता है और एक इंजीनियर पहले से ही उस पर काम कर रहा है। अपवाद न होता तो टिकट नई कतार में जाकर सबको भ्रमित कर देता। लिखित अपवाद से सिस्टम ownership स्पष्ट रखता है और फिर भी सपोर्ट लीड को अलर्ट करता है।

यही सादे नियम फ़ॉर्मेट का असली लाभ है। एक नया एजेंट देख सकता है कि क्या नियम शुरू करता है, क्या सत्य होना चाहिए, ऐप क्या करेगा, और नियम बदलने पर अंतिम निर्णय किसका होगा।

भ्रम पैदा करने वाली सामान्य गलतियाँ

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

धुंधला शब्दवालेपन सबसे बड़ी समस्या में से एक है। 'जल्दी', 'बड़ा', 'उच्च जोखिम', या 'महत्वपूर्ण' जैसे शब्द तब तक स्पष्ट लगते हैं जब तक दो लोग उन्हें अलग‑अलग परिभाषित न कर लें। 'जल्दी किसी बड़े ऑर्डर की समीक्षा करें' उपयोगी नियम नहीं है। 'किसी भी ऑर्डर की समीक्षा करें जो $5,000 से ऊपर हो और 2 बिज़नेस घंटे के भीतर' उपयोगी है।

एक और सामान्य गलती नीति और ऐप व्यवहार को एक ही वाक्य में मिलाना है। नीति इरादा बताती है। नियम बताता है कि ऐप क्या करेगा। जब दोनों एक साथ भरे जाते हैं, पाठक असल व्यवहार छूट जाते हैं।

उदाहरण के लिए, 'VIP ग्राहकों को अतिरिक्त देखभाल मिले, इसलिए संदिग्ध रिफंड फाइनेंस को जाएँ' बहुत खुला छोड़ देता है। नीति नोट अलग रखें और नियम को इस तरह लिखें: 'अगर ग्राहक टियर = VIP और रिफंड फ्रॉड रिव्यू के लिए फ़्लैग है, केस को Finance को असाइन करें।'

इन रेड फ्लैग्स पर नजर रखें:

• कोई स्पष्ट ओनर नहीं
• अपवाद लंबे पैराग्राफ़ में दबे हुए हों
• एक ही रिकॉर्ड में कई नियम मिश्रित हों
• लॉजिक टिकट्स, स्प्रेडशीट्स और ऐप सेटिंग्स में बिखरी हो
• ट्रिगर परिणाम का वर्णन करे बजाय शुरुआत की घटना के

इसे बचाने का सरल तरीका है नियमों को एक‑एक करके दस्तावेज़ करना। हर नियम को अपना रिकॉर्ड दें, भले ही कई नियम एक ही वर्कफ़्लो से संबंधित हों। इससे अपडेट सुरक्षित और टेस्टिंग आसान होती है।

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

सहेजने से पहले एक त्वरित चेकलिस्ट

किसी नियम को डन मार्क करने से पहले इसे नए साथी की तरह पढ़ें। अगर कोई अगले हफ्ते जुड़ जाए, क्या वह बिना पूछे नियम का पालन कर लेगा कि किसी फ़ील्ड का क्या मतलब है, यह कब शुरू होता है, या परिणाम को कौन अप्रूव करता है?

एक अच्छा नियम सिर्फ पढ़ने में आसान नहीं, सत्यापित करने में आसान होना चाहिए। अगर कोई शर्त 'बड़ा ऑर्डर' या 'निष्क्रिय ग्राहक' कहती है, तो ऐप में ठीक‑ठीक क्या मतलब है, परिभाषित करें। टेस्टेबल शब्दावली अनुमान हटाती है और हैंडओवर को आसान बनाती है।

हर बार यह छोटा चेकलिस्ट उपयोग करें:

• क्या नया साथी नियम अकेले फॉलो कर सकता है?
• क्या हर शर्त परीक्षण के लिए पर्याप्त स्पष्ट है?
• क्या दस्तावेज़ में उपयोग किए गए शब्द ऐप के फ़ील्ड नामों से मेल खाते हैं?
• क्या वर्तमान ओनर स्पष्ट रूप से नामित है?
• क्या अपवाद और किनारे के मामलों को लिखित किया गया है?
• क्या अंतिम समीक्षा तिथि दिखाई दे रही है?

फ़ील्ड नाम लोगों की अपेक्षा से ज़्यादा मायने रखते हैं। अगर दस्तावेज़ में 'customer status' लिखा है पर ऐप में फ़ील्ड का नाम 'account_state' है, लोग अनुमान लगाना शुरू कर देते हैं। सटीक लेबल का उपयोग करें जो सिस्टम में हैं।

ओनर को भी एक वास्तविकता जांच चाहिए। पुराने मैनेजर के नाम वाला नियम अक्सर किसी भी ओनर जैसा माना जाता है। टीम या भूमिका नामित करें अगर वह बेहतर लगे, पर सुनिश्चित करें कि किसी वर्तमान व्यक्ति को अपडेट के लिए ज़िम्मेदार माना गया हो।

रिव्यू तिथि आपकी ताज़गी की जाँच है। भले ही फ़ॉर्मेट स्पष्ट हो, जब यह पता न हो कि नियम पिछली बार महीने पहले या तीन साल पहले देखा गया था, तब वह अविश्वसनीय हो जाता है।

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

नियमों को वर्तमान रखने के अगले कदम

हर नियम से शुरू न करें। उस वर्कफ़्लो से शुरू करें जो सबसे ज़्यादा बदलता है। वहीं अक्सर भ्रम पहले दिखता है, खासकर हैंडओवर, नीति अपडेट या ऐप परिवर्तन के बाद।

एक ऐसी प्रक्रिया चुनें जिसका असल प्रभाव हो, जैसे ऑर्डर अप्रूवल्स, रिफंड अनुरोध, या लीड राउटिंग। अगर आप एक व्यस्त वर्कफ़्लो को अच्छी तरह दस्तावेज़ कर सकें, बाकी आसान हो जाएगा।

अपडेट को सामान्य काम का हिस्सा बनाएं

नियम पुराने तब होते हैं जब किसी परिवर्तन के बाद उन्हें अपडेट न किया जाए। इसका समाधान सरल है: जब भी प्रक्रिया बदले, ऐप बदले, या ओनर बदले, संबंधित नियम रिकॉर्ड की समीक्षा करें।

एक छोटा व्यवहार बड़े क्लीनअप प्रोजेक्ट से बेहतर काम करता है। जब कोई फ़ॉर्म एडिट करे, कोई स्टेटस बदले, कोई अप्रूवल स्टेप जोड़े, या शर्त अपडेट करे, संबंधित नियम को उसी समय चेक करना चाहिए।

एक व्यावहारिक रूटीन कुछ ऐसा दिखता है:

• एक ऐसा वर्कफ़्लो चुनें जो अक्सर बदलता है
• नियम अपडेट का मालिक एक भूमिका असाइन करें
• हर प्रक्रिया या ऐप परिवर्तन के दौरान नियम की समीक्षा करें
• नियम को उस जगह स्टोर करें जहाँ टीम पहले से काम करती है
• आख़िरी अपडेट की तिथि और कारण नोट करें

जहाँ आप नियम स्टोर करते हैं वह मायने रखता है। अगर टीम शेयरड वर्कस्पेस, प्रोजेक्ट टूल या ऐप स्पेक में काम करती है, तो नियम वहीं रखें बजाय किसी अलग फ़ोल्डर के जिसे कोई नहीं खोलता। अच्छा वर्कफ़्लो डॉक्यूमेंटेशन उस समय आसानी से मिलना चाहिए जब किसी को इसकी ज़रूरत हो।

एक साधारण उदाहरण: अगर सपोर्ट लीड रिफंड लिमिट $100 से $150 बदलता है, तो अपडेट एक ही समय पर दो जगह होना चाहिए — ऐप लॉजिक और नियम रिकॉर्ड। अगर केवल एक जगह अपडेट होता है, तो टीम अनुमान लगाने लगेगी।

लॉजिक को दिखाई देने वाला बनाने वाले टूल्स का उपयोग करें

अगर आप प्रोसेस‑भारी ऐप्स बनाते हैं, तो मदद मिलती है जब लॉजिक देखना आसान हो। AppMaster एक उदाहरण है: टीमें बैकएंड, वेब और मोबाइल ऐप व्यवहार विज़ुअली बना सकती हैं, जो प्रक्रिया बदलते समय ट्रिगर, शर्तें और एक्शन ट्रेस करना आसान बनाता है। फिर भी लिखित नियम जरूरी है क्योंकि वह फ्लो के पीछे का कारण समझाता है, सिर्फ़ फ्लो नहीं।

लक्ष्य परफ़ेक्ट डॉक्यूमेंटेशन नहीं है। लक्ष्य वर्तमान डॉक्यूमेंटेशन है। अगर नियम स्पष्ट, आसानी से मिलने योग्य और काम बदलने पर समीक्षा की जाने वाली हो, तो वह अगले व्यक्ति के लिए भी अर्थपूर्ण रहेगा।