हम भविष्य के ईआरपी सिस्टम में दस्तावेजों को जोड़ने और उत्पन्न करने की प्रक्रिया का दस्तावेजीकरण करते हैं

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

मैं पाठक को यथासंभव उपयोगी सामग्री देने की कोशिश करूंगा, और साथ ही परियोजना के हितों का पालन करूंगा और कार्यान्वयन और आंतरिक उपयोग की बारीकियों को नहीं बताऊंगा।

दिए गए:

• शांत विकास टीम और निश्चित रूप से परियोजना प्रबंधक। परियोजना की शुरुआत के समय, मैंने टॉम्स्क के एक स्टूडियो में एक कला निर्देशक के रूप में काम किया, फिर मैंने स्टार्टअप टीम पर काम किया
• एक विशेष घटना के लिए प्रबलित कंक्रीट की तारीखों के साथ स्टार्ट-अप - FRII में त्वरण शुरू होता है
• विभिन्न कनेक्शन स्थितियों के साथ एक दस्तावेज़ में 1 पृष्ठ से 100+ पृष्ठों तक विभिन्न आकारों के 15+ दस्तावेजों से टेम्पलेट्स का प्रारंभिक सेट
• तृतीय-पक्ष परियोजना जिसे भविष्य के समाधान के साथ एकीकृत किया जाना चाहिए
• डिज़ाइनर (विश्लेषक, डिज़ाइनर, डिज़ाइनर, कला निर्देशक, उत्पाद स्वामी, उत्पाद प्रबंधक सभी एक में लुढ़के)

उद्देश्य:

• समय पर एक परियोजना शुरू
• सिस्टम में नई कार्यक्षमता और यहां तक ​​कि अधिक प्रलेखन कनेक्ट करते समय अराजकता में छह महीने बाद टीम नहीं मरती (त्वरण के सफल समापन के मामले में)
• उपयुक्त दस्तावेज प्राप्त करने के लिए पत्रों की न्यूनतम संख्या और खर्च किए गए प्रयासों के साथ
• किसी भी टीम / किसी भी कर्मचारी के संदर्भ में प्रलेखन का अलगाव

मुझे तुरंत कहना होगा कि निम्नलिखित दस्तावेज़ टेम्पलेट बिना किसी कार्यप्रणाली के बनाए गए थे, मुझे विशेष रूप से परियोजना की बारीकियों, सामान्य ज्ञान और एक भयानक समय सीमा द्वारा निर्देशित किया गया था।

विश्लेषण और तैयारी

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

अगला कदम दस्तावेजों के मार्कअप की सफाई की स्थिति को समझना है। मैं समझा दूंगा। तथ्य यह है कि मुझे पहले से ही पूरा दस्तावेज प्राप्त हुए हैं मेथोडोलॉजिस्ट से - कौन, कब और कैसे मैंने इन दस्तावेजों को नहीं जाना, भले ही मुझे पता था कि यह बहुत कम दिया होगा। .Docx दस्तावेज़ कुछ इस तरह है जैसे टेक्स्ट के लिए xml और कुछ तत्व एक खुले दस्तावेज़ में नेत्रहीन दिखाई नहीं दे सकते, लेकिन दस्तावेज़ के मार्कअप में मौजूद हों। दस्तावेज़ जनरेटर और दस्तावेज़ को देखने के लिए विभिन्न सॉफ़्टवेयर इन मार्कअप तत्वों पर कैसे प्रतिक्रिया करेंगे, यह ज्ञात नहीं है। मुख्य शर्त Microsoft Word पर थी, लेकिन OpenOffice, LibreOffice हैं और ये सभी अलग-अलग परिणाम दे सकते हैं। इसलिए, सभी टेम्प्लेट पहले शैली की सफाई प्रक्रिया के माध्यम से चले गए - किसी भी डिजाइन का पूरा रीसेट और दस्तावेज़ शैलियों के साथ फिर से डिज़ाइन, कहीं दस्तावेज़ की संरचना को समायोजित करने के साथ। और इस प्रक्रिया के बाद भी, हमने पीढ़ी के बाद दस्तावेजों की सामग्री में समस्याएं एकत्र कीं। भविष्य में, मैं इस नतीजे पर पहुंचा कि यदि दस्तावेज़ छोटा है, तो इसे खरोंच से फिर से छांटना बेहतर है, और कार्यप्रणाली द्वारा प्रदान किए गए टेम्पलेट को काम में नहीं लेना चाहिए, इससे 5 पृष्ठों तक के दस्तावेजों पर समय की बचत होती है। कोई भी उस कारण की तलाश नहीं करना चाहता है कि क्यों कुछ हुआ, इन मामलों को डीबग करने की प्रक्रिया टीम के लिए बेहद थकाऊ है। उसी चरण में, यदि आपके पास दस्तावेजों का पैकेज है, तो आप एक समान दृश्य भाषा में आते हैं।

और जब से हमने दस्तावेज़ साफ करने का एक संस्कार किया, मेटा-इनफार्मेशन में ईस्टर अंडे का सुझाव दिया, क्योंकि लोग अच्छे दस्तावेज़ साझा करना पसंद करते हैं

दस्तावेजों की तैयारी से संबंधित सभी कार्यों के बाद, मैं स्वचालित पीढ़ी के लिए दस्तावेजों को चिह्नित करने के लिए आगे बढ़ा।

दस्तावेजों का मार्कअप

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

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

चर और इंटरफ़ेस प्रलेखन

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



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

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

सामग्री:

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

दस्तावेज़ कनेक्शन दस्तावेज़ीकरण

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



टेम्पलेट " दस्तावेज़ कनेक्शन ", मुझे आशा है कि यह किसी के लिए उपयोगी है।

सामग्री:

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

कुल मिलाकर

नतीजतन, मैंने दोनों दस्तावेजों में 362 लाइनें भरीं। प्रभावशाली मात्रा? लेकिन वास्तव में, यह 30+ डॉक्यूमेंट टेम्प्लेट है और दो साल (1-1.5 सप्ताह) में एक व्यक्ति के काम का कुल 40-60 घंटे खर्च होता है, इसमें टेम्प्लेट के संपादन और कनेक्शन कार्यों के शब्दों को छोड़कर।

परियोजना ने IIDF में सफलतापूर्वक त्वरण पारित किया और अपनी स्वयं की विकास टीम के रूप में आया। मौजूदा प्रलेखन के लिए धन्यवाद, नई टीम के सदस्यों को दस्तावेजों की पीढ़ी के संबंध में लंबे समय तक यह साबित नहीं करना था कि उनके सामने क्या किया गया था। सभी टीम के सदस्यों के पास किसी भी समय जुड़े दस्तावेजों की वर्तमान स्थिति तक पहुंच थी।

दस्तावेज़ पीढ़ी प्रक्रिया के प्रलेखन में मुख्य चरण:

• दस्तावेजों की सामग्री का विश्लेषण
• दस्तावेज़ स्वच्छता
• दस्तावेज़ मार्कअप के साथ समानांतर में चर को ठीक करें
• दस्तावेज़ टेम्पलेट्स को जोड़ने की बारीकियों को ठीक करें।

अंत तक पहुंचने के लिए धन्यवाद।