प्रलेखन - परियोजना आय का एक अलग आइटम

परिचय

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



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



ऐसी परिस्थितियां हैं जहां अनुबंध के तहत विकसित प्रलेखन का हिस्सा आंतरिक रूप से उपयोगी है। मैंने यह देखा है। ऐसे हालात हैं जब दस्तावेज के कारण परियोजनाएं पूरी तरह से बंद थीं। और मैंने यह देखा। लेकिन सामान्य द्रव्यमान में ये सिर्फ अपवाद हैं।



मैं ईमानदारी से इस राज्य को पसंद नहीं करता हूं।

मैं, समय-समय पर दस्तावेज़ीकरण विकसित कर रहा हूं, कॉर्पोरेट संसाधनों का एक भक्षक बनने के लिए सहमत नहीं हूं।

और मुझे इस बारे में कुछ कहना है।



प्रिय बिक्री, उत्पाद और परियोजना प्रबंधक - चलो प्रलेखन को अधिक सक्रिय रूप से बढ़ावा देते हैं। चलो इस पर पैसा बनाओ!

ग्राहक को प्रलेखन की आवश्यकता क्यों है?

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



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

क्योंकि इसमें अधिक समय लगेगा:



ग्राहक के लिए:

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

कलाकार:

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

यदि ग्राहक विफल हो जाता है, तो वह समाधान को समझने, विकसित करने और लागू करने की संभावना के साथ बहुत ही ठोस वित्तीय और अस्थायी नुकसान का अनुभव करेगा। यदि कलाकार विफल हो जाता है, तो वह बस एक कलाकार बनने के लिए संघर्ष करेगा। तुरंत या थोड़ी देर बाद।



यह पता चला है कि प्रलेखन का एक सक्षम सेट (अर्थात् सक्षम, और बड़ा नहीं) समाधान के जीवन को महत्वपूर्ण रूप से विस्तारित करने में सक्षम है।



समाधान के सेवा जीवन से संबंधित एक और महत्वपूर्ण तर्क इसकी लागत प्रति समय अवधि है। यह देखते हुए कि एक ग्राहक के लिए एक समाधान की लागत "प्रति वर्ष" है, वर्षों की संख्या से विभाजित सभी खर्चों का योग है, इसके नियमित रूप से टॉड को vitally दिलचस्पी होना चाहिए ताकि इस सूत्र में भाजक जितना संभव हो उतना बड़ा हो। यह 6 साल के लिए प्रणाली 2 साल के लिए काम करता है, और काफी कम से कम 3. अगर यह हर साल एक लाख बचत है।



बेशक, डेवलपर्स आपत्ति कर सकते हैं, “तो क्या? दो साल में, हमें उसी पैसे के लिए एक और निर्णय लेना है। हम बेहतर हैं! ” लेकिन, सबसे पहले, यह खेल नहीं है। और दूसरी बात, यह सीमित समय के लिए काम करता है, जिसके बाद ग्राहक ढूंढना अधिक कठिन हो जाता है।



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

ग्राहक को क्या देना है?

उपयोगी प्रलेखन की संरचना परियोजना से परियोजना में काफी भिन्न हो सकती है, हालांकि, मैं इसकी परिभाषा के लिए सामान्य दृष्टिकोण की सिफारिश कर सकता हूं।



व्यावसायिक संरचनाओं के लिए परियोजनाओं सहित ज्यादातर मामलों में, नामकरण और प्रलेखन की सामग्री का निर्धारण करते समय, आप GOST 34.201-89 और RD 50-34.698-90 के एक समूह पर निर्माण कर सकते हैं। अग्रिम में यह पूछना भी उपयोगी होगा कि ग्राहक के अपने विभागीय या कॉर्पोरेट मानक हैं (या निर्णय निर्माता की व्यक्तिगत प्राथमिकताएँ भी)।



बड़ी संख्या में दस्तावेजों के साथ, काम के समन्वय और बाद की योजना को सरल बनाने के लिए चरणों और / या सामग्री की समानता के अनुसार उन्हें व्यवस्थित करना वांछनीय है।



मैं निम्नलिखित श्रेणियों की पेशकश कर सकता हूं जो मैं खुद का उपयोग करता हूं:



1. पूर्वनिर्धारित। इसमें दस्तावेज़ शामिल होंगे जो समाधान के डिजाइन से पहले होंगे। सहित:

• सर्वेक्षण रिपोर्ट;
• अवधारणा;
• व्यवहार्यता अध्ययन;
• तकनीकी विनिर्देश, आदि।

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



2. डिजाइन। अनुमानित सब कुछ (लेकिन अभी तक लागू नहीं) समाधान से संबंधित है। परियोजना के बहुत सारे दस्तावेज हो सकते हैं (उदाहरण के लिए, समान GOST 34.201-89) और परियोजना से परियोजना तक, संभावित ग्राहक के लिए कुछ दस्तावेजों की उपयोगिता और आकर्षण पर जोर शिफ्ट हो सकता है, हालांकि, जिन दस्तावेजों में विवरण शामिल है, वे आमतौर पर सबसे अधिक मांग हैं:

• कार्य जो प्रस्तावित समाधान स्वचालित करता है;
• समाधान की कार्यक्षमता और आंतरिक संरचना के बारे में तकनीकी विवरण;
• काम करने के लिए डिज़ाइन किए गए समाधान के लिए आवश्यक क्रियाएं "जैसा कि यह होना चाहिए" (डेटा माइग्रेशन रणनीति, स्टाफ प्रशिक्षण योजना, नौकरी प्रमाणन, आदि)।

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



3. काम करना। इसमें इस बात की जानकारी शामिल है कि डिज़ाइन किए गए समाधान को कैसे रखा जाना चाहिए / कॉन्फ़िगर किया जाना चाहिए या बहुत विशिष्ट कार्य स्थितियों में प्रारंभिक जानकारी प्रदान की जानी चाहिए। सहित:

• स्वचालन वस्तु पर तकनीकी उपकरणों के लेआउट;
• बिजली की आपूर्ति सर्किट और संचार चैनल;
• कॉन्फ़िगरेशन फ़ाइलों का वर्णन;
• निर्देशिका और डेटाबेस की प्रारंभिक सामग्री का वर्णन;
• नैदानिक ​​विधियों का वर्णन, आदि।

यह अमूल्य है यदि ग्राहक अपने आप (कम से कम आंशिक रूप से) समाधान का संचालन और रखरखाव करने की योजना बना रहा है।



4. संचालन। सभी बताते हैं कि समाधान के साथ कैसे काम किया जाए। सबसे पहले, ये विभिन्न मैनुअल, निर्देश और तकनीकी नियम हैं। डिजाइन और काम करने के विपरीत, ग्राहक के परिचालन दस्तावेज के ग्राहक को समझाने के लिए शायद ही कभी आवश्यक हो। जब तक कि ग्राहक को शोक-लेखकों के काम के परिणामों के पिछले उपयोग से एक गहरी भावनात्मक और भावनात्मक आघात नहीं मिला।



5. प्रशासनिक और नियामक। यदि समाधान में ग्राहक की संगठनात्मक संरचना (व्यक्तिगत कार्यों को बदलने से और व्यक्तिगत कर्मचारियों को संगठन पदानुक्रम के स्तर पर परिवर्तन करने के लिए आश्वस्त करना) में हस्तक्षेप शामिल है, तो प्रतिष्ठित कार्यालयों में ऐसे आयोजन दस्तावेजों के साथ होते हैं। और शायद ही कभी, जब ग्राहक खुद यह काम करने के लिए उत्सुक होता है। यह उसके पहले से ही भारी बोझ (और बजट, निश्चित रूप से) को हल्का करने का प्रस्ताव करने का एक अच्छा कारण है। इस श्रेणी में प्रलेखन में शामिल हैं:

• सेवाओं के प्रावधान या कार्यों के अभ्यास के लिए प्रशासनिक नियम;
• इकाइयों के कामकाज के लिए नियम;
• संरचनात्मक इकाइयों पर नियम;
• मसौदा आदेश जो कुछ संगठनात्मक परिवर्तनों का परिचय देते हैं;
• नौकरी का विवरण, आदि।

6. शैक्षिक। मैंने इसे जानबूझकर परिचालन से अलग किया है। यहां मैं उन सामग्रियों को शामिल करने का प्रस्ताव करता हूं जो हमारे समाधान की मदद से अपने कार्यों को पूरा करने के लिए ग्राहक के प्रशिक्षण का आयोजन करती हैं। ये सामग्री विशेष रूप से उच्च कर्मचारी टर्नओवर (कॉल सेंटर, खुदरा नकदी डेस्क, आदि) की स्थितियों में महत्वपूर्ण हैं। प्रशिक्षण में शामिल हैं:

• प्रशिक्षण कार्यक्रम और ज्ञान के "छात्रों" द्वारा अधिग्रहित नियंत्रण;
• शिक्षण सामग्री;
• प्रशिक्षण पाठ्यक्रम (ऑडियो-वीडियो सहित)।

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



मैं विशेष रूप से दो दस्तावेजों पर ध्यान केन्द्रित करना चाहता हूं। "आंसू" उन्हें संदर्भ से बाहर है। यह है:

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

मेरी विनम्र राय में, इन दस्तावेजों को सभी अनुमोदन और हस्ताक्षर के साथ कागज के रूप में किसी भी परियोजना में होना चाहिए।

ग्राहक की पेशकश कैसे करें?

इस विषय पर बहुत कुछ लिखा जा चुका है और जितना मैं लिख सकता हूं उससे बहुत बेहतर। मेरा मामूली अनुभव केवल यह बताता है कि अगर कम या ज्यादा सक्षम प्रलेखन विशेषज्ञ हैं, तो कुछ भी हस्तक्षेप नहीं करेगा:

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

निष्कर्ष के बजाय ...

... मैं प्रलेखन और ग्राहक की जरूरतों के नामकरण के बारे में एक कहानी साझा करूंगा।



किसी तरह मैं एक गंभीर ग्राहक के लिए एक गंभीर समाधान के विकास में भाग लेने के लिए हुआ। जब मैंने आवश्यकताओं को देखा, तो मुझे थोड़ी हैरानी हुई: एक तकनीकी-कार्यशील परियोजना के 35+ दस्तावेजों के क्रम का विकास उनमें निर्धारित था। यानी लगभग पूरे 34 वें GOST।



सतर्क प्रश्न के लिए "आपको इस सभी धन की आवश्यकता क्यों है?" ग्राहक ने कुछ इस तरह से उत्तर दिया: "पड़ोसी कार्यालय के प्रतिस्पर्धी विभाग ने केवल सिस्टम को स्वीकार किया है, जो 20 दस्तावेजों से लैस था। "हम अपने विकास को सामान्य की आँखों में कम ठोस देखने की अनुमति नहीं दे सकते हैं!"



और आप कहते हैं - "बिक्री के लिए नहीं!"