चंचल और ज्ञान प्रबंधन दोस्त हैं?

पहले से ही कई बार, सम्मेलनों और व्याख्यान में सहयोगियों के साथ संवाद करते हुए, मुझे यह सवाल मिला:

ऐसा लगता है कि इसका जवाब देने का समय तय कर दिया गया है।

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

आइए हम अग्नि प्रकट के साथ शुरू करते हैं। इसके लेखक सीधे कहते हैं कि

"यही कारण है कि दाईं ओर क्या है के महत्व को नकारे बिना, हम अभी भी बाईं ओर के मूल्य पर अधिक मूल्य देते हैं"

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

"लोग और बातचीत प्रक्रियाओं और उपकरणों से अधिक महत्वपूर्ण हैं।"

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

इस अध्ययन के परिणाम घोषणा के पहले थीसिस की पुष्टि करते हैं। यह मुझे लगता है कि प्रश्न के पैर इस तथ्य से बढ़ रहे हैं कि विकास में कई लोगों द्वारा ज्ञान के प्रबंधन को दस्तावेज के रूप में समझा जाता है, न कि अनुभव के हस्तांतरण में लोगों के बीच बातचीत।

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

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

या जोड़ी प्रोग्रामिंग । यहां तक ​​कि विकिपीडिया हमें इस उपकरण के बारे में बताता है:

फायदे:

***

tutorship

हर कोई, यहां तक ​​कि एक नौसिखिया प्रोग्रामर, कुछ ऐसा जानता है जो दूसरों को नहीं पता है। पेयर प्रोग्रामिंग इस ज्ञान को फैलाने का एक दर्द रहित तरीका है।

***

ट्रेनिंग

प्रोग्रामर लगातार ज्ञान का आदान-प्रदान करते हैं।

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

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

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

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

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

एक पोस्ट में मैंने केवल कुछ उदाहरण दिए हैं। आइए टिप्पणियों में चर्चा करें कि अन्य चुस्त उपकरण क्या ज्ञान प्रबंधन उपकरण हैं। खैर, या चर्चा क्यों मैं गलत हूँ :)