डेवलपर्स के लिए आमतौर पर कॉर्पोरेट ज्ञान के आधार के साथ एक समस्या है - यह या तो एक शून्य में बदल जाता है, क्योंकि इसे भरने की कोई प्रेरणा नहीं है या तो एक जिम्मेदार व्यक्ति के साथ, या सोवियत अपार्टमेंट से चीजों से भरी बालकनी में, हर कोई योगदान देता है, लेकिन वे यादृच्छिक रूप से, जानकारी जल्दी से पुरानी हो जाती है, और यह हमेशा अद्यतन करने के लिए समय नहीं है।
इससे कैसे बचें, या कम से कम संभावित लागत को कम करें? अपने कॉर्पोरेट आधार को गर्म और दीपक कैसे बनाएं? मैं जवाब देने की कोशिश करूंगा।
सहयोग शैली प्रलेखन
इस तरह के एक दृष्टिकोण, सहयोगी दस्तावेज है, यह मूल रूप से चिकित्सा के क्षेत्र में दिखाई दिया, जब निदान करने का निर्णय रोगी और कई डॉक्टरों द्वारा सामूहिक रूप से किया जाता है।
आईटी के क्षेत्र में एक महत्वपूर्ण उदाहरण Google डॉक्स, विकी, जीथब, किसी भी प्रणाली में आंतरिक सम्मेलनों और एक परियोजना पर एक साथ काम करने की क्षमता है।
यह विचार डेवलपर्स, विशेषज्ञों, आलोचकों को प्रलेखन पर काम को जल्द से जल्द शामिल करने, एक साथ अंतराल की पहचान करने के लिए है।
यह क्यों आवश्यक है?
सबसे पहले, बस कारक को कम करना कॉर्पोरेट ज्ञान में एक अड़चन है, जहां ज्ञान धारकों की संख्या एकता में बदल जाती है। आपको डेवलपर के सिर से व्हाइटबोर्ड, टिकट, बातचीत से रसोई में एक ही स्थान पर इस तरह के ज्ञान को स्थानांतरित करने की आवश्यकता है ताकि हर कोई उनके साथ काम कर सके और योगदान दे सके।
दूसरे, परियोजनाओं के लिए नए लोगों के प्रवेश को सरल बनाने के लिए, जो विशेष रूप से वितरित टीमों और आउटसोर्सिंग डेवलपर्स की एक निश्चित संख्या के साथ महत्वपूर्ण है, साथ ही उन कंपनियों के लिए जिनके पास एक बहुत विशिष्ट व्यवसाय क्षेत्र है, एक तैयार-विशेषज्ञ को खोजने का मौका शून्य है।
तीसरा, एक ध्वनि कॉर्पोरेट संस्कृति के गठन के लिए, पारदर्शिता "शब्दों में नहीं"। इस तरह के माहौल में एक डेवलपर पेशेवर विकास के बिंदुओं को स्पष्ट रूप से समझता है, वह कंपनी में कौन सी अन्य तकनीकों की कोशिश कर सकता है, क्या सीखना है।
क्या करें?
कॉर्पोरेट ज्ञान आधार के भीतर दस्तावेज़ीकरण टीम के किसी भी सदस्य द्वारा लिखा जा सकता है, इस अवसर को उनके लिए सरल बनाने की आवश्यकता है, फिर उन्हें लगेगा कि वे परिणाम के मालिक हैं - शामिल।
हालांकि, आपको निश्चित रूप से एक ऐसे व्यक्ति की आवश्यकता है जो एक सूचना वास्तुकार के कार्यों पर ले जाएगा - सही ढंग से रिक्त स्थान में एक समान नियम, संरचना, तर्क, शैली, स्थान दस्तावेज़ निर्धारित करें।
टीम के सदस्यों को दस्तावेज़ बनाने और संपादित करने की संभावना खोलें, पहले खेल के नियमों पर सहमत हुए। इन नियमों को अधिकतम करने के लिए स्वचालित करें - टीम पर भरोसा न करें, टेम्प्लेट बनाएं, टैग के साथ टैग सामग्री को स्वचालित रूप से बनाएं, रिपॉजिटरी से नॉलेज बेस पर अपलोड करना कॉन्फ़िगर करें (मैं इस बारे में एक अलग लेख बनाना चाहता हूं, वैसे)।
यह महत्वपूर्ण है कि डेवलपर्स देखें कि दस्तावेज कॉर्पोरेट विकी में मरने के लिए नहीं जाते हैं।
एक महत्वपूर्ण सिद्धांत: एक आंतरिक दस्तावेज़ की परिभाषा, यह वह क्षण होता है जब इसमें संशोधन या टिप्पणियां की जाती थीं , जो वास्तव में, सहयोग का क्षण होता है। यह इसका मूल्य है, वे इस पर समय बिताना चाहते हैं। पूरक न करें - इसका मतलब है कि वितरण प्रक्रिया, खोज का कार्यान्वयन खराब रूप से व्यवस्थित है, या उपकरण असुविधाजनक है।
इस दृष्टिकोण की संभावित समस्याएं एक स्नोबॉल के रूप में संपादन और टिप्पणियों का संचय है, इसका ट्रैक रखना मुश्किल है, डुप्लिकेट दस्तावेज़ अक्सर बनाए जाते हैं।
ऐसा होने से रोकने के लिए, आप कर सकते हैं और चाहिए: A. टीम को एक वेक्टर पर सेट करें, नियमों का सेट और उनका पालन न करने की प्रक्रिया को जटिल करें (उदाहरण के लिए, हम निर्माण बटन को कॉन्फ्लुएंस में छिपाते हैं और टेम्पलेट चयन को अनिवार्य बनाते हैं)। ख। अधिकारों को समझदारी से समझाना और सूचना वास्तुकला के लिए जिम्मेदार लोगों के लिए संपादन प्रक्रियाओं को सुविधाजनक रूप से कॉन्फ़िगर करना।
और तब परिपूर्ण दुनिया आएगी
डेवलपर्स एक-दूसरे से सवाल पूछना बंद नहीं करेंगे, जिनमें बेवकूफ और दोहराव शामिल हैं । वे ज्ञान के आधार पर सभी उत्तरों को अपने दम पर खोजना नहीं सीखेंगे। हमारे पास आंतरिक हास्य होता है, जब कॉन्फ्लुएंस सर्च इंडेक्स की सीमाओं के कारण, डेवलपर्स को कुछ नहीं मिल सकता है, वे मुझसे एक सूचना वास्तुकार के रूप में पूछते हैं। इसे हम स्वेता-आधारित खोज कहते हैं।
इन सीमाओं के बावजूद, ज्ञान आधार की बहुत संरचना, पृष्ठों के एकीकृत नामकरण, लेबल का उपयोग उन्हें खोज और ज्ञान बनाने के लिए प्रेरित करेगा ताकि, उदाहरण के लिए, वे लगातार दोहराए जाने वाले सवालों का जवाब न दें।
एक और जीवन हैक जो हमने लागू किया है, वह हमेशा दस्तावेज़ों में एक व्यावसायिक संदर्भ शामिल करता है, भले ही वह किसी पुस्तकालय या कक्षा का वर्णन हो या किसी कार्य के लिए एक चेकलिस्ट हो, यह समझना महत्वपूर्ण है कि क्लाइंट के लिए इसका क्या अर्थ है।
अब अभ्यास करना है
अगला भाग "हाउ" के बारे में होगा, जो इन सिद्धांतों को लागू करने के लिए कॉन्फ्लुएंस की आंतरिक विशेषताओं (हाँ, हम एटलसियन स्टैक का उपयोग करते हैं) का उपयोग किया जा सकता है।
टेम्पलेट्स
हमने विभिन्न प्रकार के दस्तावेजों के लिए तैयार किए गए टेम्पलेट बनाए हैं जो हम सबसे अधिक बार लिखते हैं - तकनीकी विनिर्देश, कैसे-करें, चेकलिस्ट। उन्हें व्यवस्थापक स्पेस पैनल में कॉन्फ़िगर किया जा सकता है। टेम्प्लेट की आवश्यकता होती है ताकि दस्तावेज़ बनाते समय डेवलपर उसके सामने एक खाली पृष्ठ न देख सके, उसके पास पहले से ही इस या उस अनुभाग में क्या लिखना है, इसके निर्देश हैं। यदि आप चाहते हैं कि एक निश्चित प्रकार के दस्तावेज़ एक खंड में आते हैं और मेटा-सूचना उन पर प्रदर्शित की जाती है (यह सुविधाजनक है, उदाहरण के लिए, एक जटिल उत्पाद के घटकों या एक योजना के अनुसार माइक्रोसिस्टर्स के सेट का वर्णन करने के लिए), तो खाका बनाएं, यह अधिकतम गति पर एक टेम्पलेट की तरह है।
उनमें हम पेज लेआउट, हेडिंग सेट करते हैं, जहां यह केवल कुछ शब्दों को बदलने के लिए रहता है, एक स्टेटस, इमेज, टेबल, कोड ब्लॉक और यहां तक कि वैरिएबल के साथ एक हेडर।
चर पूर्व-कॉन्फ़िगर सामग्री तत्व हैं जिनके लिए एक और दस्तावेज़ संपादक को महत्व देना चाहिए, उदाहरण के लिए, पाठ दर्ज करें या किसी सूची से चयन करें।
आप पहले से टेम्प्लेट में टैग भी जोड़ सकते हैं, यदि यह दस्तावेज़ का एक संकीर्ण प्रकार है, तो आप उपयोगकर्ताओं को समीक्षकों के रूप में उल्लेख कर सकते हैं, उदाहरण के लिए, यदि नाम, जीरा मैक्रो द्वारा एक स्पष्ट वर्कफ़्लो है, और जीरा से टिकट संलग्न करें। हमारा अनुभव बताता है कि 80 प्रतिशत तक कार्यों को टेम्प्लेट से कवर किया जा सकता है।
पेज लेआउट
एक अन्य महत्वपूर्ण तत्व टीम स्पेस में एक समझने योग्य और सुंदर लैंडिंग पृष्ठ का निर्माण है। ऐसा करने के लिए, हम पेज लेआउट और मैक्रोज़ पैनल, कॉलम और सेक्शन का उपयोग करते हैं।
नीचे हमारी विकास टीम के स्थानों में से एक का एक उदाहरण है।
अनुकूल पृष्ठ नामों का उपयोग करें। जैसा कि आप जानते हैं, Confluence समान स्थान के समरूप पृष्ठ नामों का समर्थन नहीं करता है। स्पष्ट पृष्ठ नामों को बनाए रखें, जैसे कि
बुरा नाम पायथन
आंतरिक सेवाओं की टीम के लिए
अच्छा नाम पायथन स्टाइलगाइड
लेबल
कनफ्लुएंस में कंटेंट इंडेक्सिंग से संबंधित सर्च एल्गोरिदम की कुछ सीमाएँ हैं। और कॉरपोरेट नॉलेज बेस के लिए, यह सटीक रूप से खोज और कनेक्टिविटी है जो सबसे अधिक दबाव वाले मुद्दे हैं। हमारे पास नॉलेज बेस में एक पूरा लेख है जिसे कंफ्लुएंस सर्च को कैसे हराया जाए, अगर आप चाहें, तो मैं इसे टिप्पणियों में साझा करूंगा।
इन सीमाओं को दूर करने के लिए, हम एक लेबल प्रणाली का उपयोग करते हैं। वास्तव में, ये वे टैग हैं जो सामग्री के विषय को चिह्नित करते हैं, और वे आपको एक विशेष विषय की सामग्री को एक तरह से RSS फ़ीड (लेबल द्वारा मैक्रो सामग्री) के रूप में एक स्थान पर एकत्र करने की अनुमति देते हैं। इसलिए हमने विषय सूचकांक को कॉन्फ़िगर किया है।
यदि आपके पास पहले से ही डेटाबेस में सैकड़ों पृष्ठ हैं, तो मैं आपको निम्नलिखित अभ्यासों से शुरू करने की सलाह देता हूं:
- निम्नलिखित URL https: // <my-host-name> /labels/listlabels-alphaview.action पर सभी लेबल की सूची देखें।
- उन्नत खोज स्ट्रिंग में किसी भी लेबल के साथ टैग नहीं की गई सभी सामग्री ढूंढें: टाइप करें: पेज NOT लेबलटैक्स्ट: [एक टू जेड] नहीं लेबलटैक्स: [0 से 9]।
आप अभी क्या कर सकते हैं?
- डेवलपर्स को संपादित करने का अधिकार दें, लेकिन बुद्धिमानी से।
- कमांड स्पेस की संरचना के बारे में सोचें, एक सुविधाजनक लैंडिंग पेज बनाएं।
- टेम्पलेट कस्टमाइज़ करें।
- लेबल का उपयोग करें।
- जाओ और किसी और के दस्तावेज़ को संपादित करें या एक टिप्पणी लिखें, काम करने के लिए इस दस्तावेज़ को प्राप्त करें।