ज्ञान प्रबंधन: क्या दस्तावेजों की जरूरत है और उनमें क्या तय करना है

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

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

संस्कृति परियोजना कार्यक्रम

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

• वैज्ञानिक;
• कारखाने;
• डिजाइन;
• सेवा संस्कृति।

उनमें से प्रत्येक ने सॉफ्टवेयर परियोजनाओं के प्रबंधन के दृष्टिकोण को प्रभावित किया। और किसी ने एक दूसरे के साथ संगतता के बारे में नहीं सोचा।



वक्ता के बारे में: मैक्सिम त्सेपकोव आईटी वास्तुकार और व्यापार विश्लेषक, नौसिखिया और फुर्तीली संगठनों और सर्पिल गतिशीलता के दुनिया में विशेषज्ञ।

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

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


लेकिन यह समझना महत्वपूर्ण है कि प्रलेखन के बारे में अधिकांश पाठ्यपुस्तकों को आरयूपी युग में लिखा गया था, जिसमें प्रक्रिया के संगठन का उद्देश्य बजट और समय सीमा को पूरा करना था। यह काम नहीं किया, लेकिन पाठ्यपुस्तकें बनी रहीं, और उन्होंने नई पाठ्यपुस्तकें नहीं लिखीं ।

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

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

स्टाइल गाइड विकसित करते समय, वे UX पर ध्यान केंद्रित करते हैं। प्रलेखन एक ही है - परियोजना की डॉक शैली गाइड पर।

मुझे उम्मीद है कि रिपोर्ट सिद्धांतों और अवधारणाओं को देगी, जिसके आधार पर आप स्थिति में सुधार कर सकते हैं और अपनी परियोजना में दस्तावेजों के साथ समस्याओं को हल कर सकते हैं।

दस्तावेज - संचार के लिए

मुख्य विचार, जिसमें से मैं आगे बढ़ता हूं, यह है कि दस्तावेज़ स्वयं-मूल्यवान नहीं हैं, लेकिन संचार प्रदान करते हैं। जैसे इंटरफेस खुद ही मायने नहीं रखते, वे उपयोगकर्ता को उस कार्यक्षमता के साथ प्रदान करते हैं जो सर्वर साइड में छिपी होती है।

दस्तावेजों का रूप, साथ ही इंटरफेस, संचार के लक्ष्यों से विकसित किया गया है।

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

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

• निर्णय लेने के लिए;
• वर्तमान संचार;
• समय में ज्ञान का संरक्षण ("छह महीने में मेरे लिए");
• अन्य लोगों को ज्ञान का हस्तांतरण;
• वर्तमान कार्य में सहायता, आदि।

प्रत्येक गंतव्य का अपना विवरण प्रकार होता है, - दृष्टिकोण - अपनी स्वयं की विवरण विधि ।

दस्तावेज़ गुणवत्ता मानदंड

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

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

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

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

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

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

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

नेत्रहीन रूप से अजीब चीजें करने की आवश्यकता नहीं है जो व्यवसाय को समझ में नहीं आता है कि वे क्यों चाहते थे। आमतौर पर उसके पास पूरी तरह से तर्कसंगत आधार होते हैं, जिसमें से खुदाई करने के बाद यह पता चलता है कि पूरी तरह से अलग चीजें करने की आवश्यकता है।

हम प्रोजेक्ट दस्तावेज़ डिज़ाइन करते हैं

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

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

उपयोग की प्रक्रिया में आगे, हम गुणवत्ता का मूल्यांकन करते हैं, और इसे उसी तरह से सुधारते हैं जैसे कि प्रयोज्यता और यूएक्स।


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


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

इस तथ्य से नहीं कि आपको इन दस्तावेजों की आवश्यकता है। यह विशेष रूप से आवश्यकताओं और विकास कार्यों पर लागू होता है।

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


ऐसे कई विकल्प और अभ्यास हैं। वे सभी विकास प्रक्रिया से निकटता से संबंधित हैं, क्योंकि यह इस प्रक्रिया में है कि संचार उत्पन्न होता है। अपनी प्रक्रिया को देखें और इसके लिए कलाकृतियों को पर्याप्त बनाएं।


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

आवश्यकताओं

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

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

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

इसके अलावा, रुचियां और अपेक्षाएं बदल सकती हैं, और यदि ऐसा होता है, तो समय में इसे ठीक करना महत्वपूर्ण है।


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

अगर हम उपयोगकर्ता संतुष्टि के बारे में बात करते हैं, तो वहां विशेषज्ञता की एक पंक्ति भी दिखाई दी: एक यूआई डिजाइनर जो उपस्थिति के साथ उपयोगकर्ता की संतुष्टि के लिए जिम्मेदार है, प्रयोज्य - उपयोग के बारे में और एक यूएक्स विशेषज्ञ जो सहज ज्ञान युक्त इंटरफ़ेस मास्टरबिलिटी पर काम करता है। यह बॉर्डर भी शिफ्ट हो रहा है। आपकी विशिष्ट परियोजना में, यह अलग हो सकता है, क्योंकि उद्यम विकास एक चीज है, जिसके लिए एक प्रशिक्षण प्रणाली है, और उपयोगकर्ता 1C एकाउंटेंट की तरह कहीं भी नहीं जाएगा, क्योंकि यह उसका कार्यस्थल है। और एक और मामला, उदाहरण के लिए, मोबाइल विकास। यदि स्टोर स्टाफ का टर्नओवर ऐसा है कि विक्रेता या स्टोर कीपर औसतन 3-6 महीने काम करता है, तो 2 दिनों में काम करने के लिए मोबाइल एप्लिकेशन विकसित करने का सवाल है, न कि 2 सप्ताह का प्रशिक्षण, प्रासंगिक है।


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

कस्टम फोकस कलाकृतियों

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

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

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

प्रोजेक्ट मोशन नॉलेज

स्क्रैम-प्रक्रिया में परियोजना आंदोलन के बारे में ज्ञान उत्पन्न करने के लिए विशेष बिंदु हैं:

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

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

दीर्घकालिक विवरण

दीर्घकालिक विवरण बनाते समय, मुख्य प्रश्न यह निर्धारित करना है कि विवरण किन मामलों का समर्थन करेगा । विकल्प पूरी तरह से अलग हो सकते हैं:

• सिस्टम के साथ काम करने के लिए एक नया उपयोगकर्ता सिखाएं।
• सिस्टम के दुर्लभ कार्यों पर संदर्भ जानकारी प्रदान करें।
• एक नए डेवलपर के लिए सिस्टम के वैचारिक डिजाइन का परिचय दें।
• सुधार के लिए लेखक को सिस्टम के डिवाइस के टुकड़े को याद करने में मदद करने के लिए।
• नए डेवलपर द्वारा विकास के लिए डिवाइस मॉड्यूल सिस्टम का वर्णन करें।
• समर्थन इंजीनियर को सिस्टम डिवाइस के बारे में जानकारी प्रदान करें।

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

सार्वभौमिक विवरण विस्तृत, महंगा, अप्रासंगिक और अनावश्यक भी है, क्योंकि आप इसके विवरण के कारण इसमें आवश्यक जानकारी नहीं पा सकते हैं।

उद्देश्य को ठीक करना , अनुपालन का मूल्यांकन करना, याद रखना आवश्यक है: दस्तावेज़ जितना अधिक विस्तृत होगा, उतना ही महंगा होगा।

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

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

उसी समय, "क्यों और किस लिए" पर लौटते हुए, हम सारांश में निर्णयों के तर्क को ठीक करना नहीं भूलते हैं, और न केवल "क्या करना है।" संक्षेप में, लेकिन यह महत्वपूर्ण है।


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

संचार अर्थ देता है

आइए थोड़ा सा पीछे हटें और चर्चा करें कि संचार का अर्थ है।


यह सब आरयूपी युग की धारणा से शुरू होता है, जिसने ऑब्जेक्ट-ओरिएंटेड अप्रोच (ओओपी) को जन्म दिया। यदि हम वस्तुओं और कनेक्शनों में दुनिया का विघटन करते हैं, तो हमें दुनिया की स्पष्ट रूप से व्याख्या की गई तस्वीर मिलती है।


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

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


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

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

आईटी के बाहर की योजनाओं का ऑर्थोगोनल स्रोत एसएमडी कार्यप्रणाली है (रिपोर्ट "सोच की एक अलग संरचना के साथ संचार - टैक्सोनॉमी बनाम लोगोोनॉमी" देखें )।

दस्तावेज़ प्रबंधन के सिद्धांत

1. दस्तावेज़ में कोई लेखक नहीं है।

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

एक महत्वपूर्ण परिणाम इस सिद्धांत से है कि एक दस्तावेज में विकी-सिस्टम में एक लेखक और अनुभव नहीं है: मैंने देखा कि क्या सुधार करना है, इसे तुरंत करें, समन्वय केवल असहमति से आवश्यक है।

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

2. दस्तावेज़ धीरे-धीरे बनाया जाता है।

एक बड़ा दस्तावेज़ लिखे जाने से पहले अप्रचलित हो जाता है। अवधारणाओं को संक्षिप्त करने के लिए पर्याप्त है, और आवश्यकतानुसार विस्तार करना। हम उस दस्तावेज़ का हिस्सा करते हैं जो वर्तमान कार्य से संबंधित है।

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

3. सामग्री फॉर्म से अधिक महत्वपूर्ण है।

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

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

4. हम निशान छोड़ते हैं।

यह अन्य महत्वपूर्ण सिद्धांत बैठकों के मिनट, वार्तालापों के सारांश की चिंता करता है। यही है, हमने टास्क ट्रैकर में 1-2 वाक्यों के सारांश को लाइव, चैटिंग और नीचे लिखा है। , , -, , .

. , , , . . , , . - , . , .

— , , .. , - , -, , , , . : , .

:

• Archimate.
• Archimate.
• - , Domain Driven Design.
• OMG Essence.
• viewpoint' ISO 42010.

. , , .

, , . , , , , , , , , : , .

, Wiki — , , , , , .. , - . CUSTIS MediaWiki. , Jira Confluence, OpenSource http://4intra.net. , , wiki- , .

— . Slack, Task Tracker Google Docs, .

. , wiki. wiki git, - wiki- , .

— , .

, , .

, « » . , : « , ?» , . , , « » , British Petroleum. , , , .


. . , .

, , 5–7 , . .

, , , C# , . .

— . — , wiki — , . . , , , . , , .

— , . BBC , , , . , , . , , .

IBM: — .

IBM : , - , . , . IBM , . , , , , , , , « , , ». . — , , .

• .
• .
• , .
• , .
• — .

mtsepkov.org (, , wiki) , agile , .

— . , : , , , , Knowledge Conf .

25 TeamLead Conf . , .