टीम में ज्ञान और दक्षता: खोज, देखें, पंप करें

एक कर्मचारी जो बहुत कुछ जानता है, जानता है कि कैसे और अपने घास के मैदान में आग लगाने के लिए तैयार है, ज़ाहिर है, अच्छी तरह से किया गया। लेकिन अगर यह नायक छुट्टी पर जाता है या यहां तक ​​कि क्विट करता है, तो कठिन समय आता है। यह पता चला है कि न केवल बहुत कुछ जानना महत्वपूर्ण है, बल्कि इस ज्ञान को साझा करने में सक्षम होना भी है।



अलेक्सी ट्रोसिन ( मोरोज़ ) लगभग 20 वर्षों से पेशे में है, वह 2002 से परियोजना और उत्पाद प्रबंधक के रूप में काम कर रहा है। इस समय के दौरान, उन्होंने विभिन्न कंपनियों में काम किया, 2 से 150 लोगों की टीमों का नेतृत्व किया, और अब फिनम में विकास का प्रबंधन करता है। यहां, एलेक्स ने एक ऐसी प्रणाली बनाई जो न केवल ज्ञान फैलाने में मदद करती है, बल्कि डेवलपर्स को सही व्यवसाय और टीम दिशा में बढ़ने के लिए प्रेरित करती है। हालांकि, सभी टीमों में सिस्टम का उपयोग नहीं किया जाता है। क्यों? हम इस बारे में सीखते हैं, साथ ही कट के नीचे उपयोग किए जाने वाले दृष्टिकोण भी।

लेख सेंट टीमलड कॉन्फ पर एलेक्सी ट्रॉशिन की एक रिपोर्ट पर आधारित है, जो बताता है कि फिनम में ज्ञान का प्रसार कैसे किया जाता है: जेडी की ताकत और कौशल कैसे बढ़ता है, कैसे पैडावन प्रशिक्षित होते हैं और फोर्स के डार्क साइड पर क्या होता है (यह इसके बिना कहां होगा)।

उत्पाद और फिनम आईटी टीम

सबसे पहले, मैं कंपनी के संदर्भ को निर्धारित करने के लिए हमारे कुछ उत्पादों के बारे में बात करूँगा।

वेबसाइट Finam.ru - वित्तीय जानकारी के साथ कई अलग-अलग वर्गों के साथ-साथ उपयोगी सेवाओं के साथ वित्तीय विषयों पर साइट नंबर 1, उदाहरण के लिए, एक ऑनलाइन स्टॉक स्टोर। उदाहरण के लिए, आप Apple का एक हिस्सा खरीद सकते हैं और किसी को जन्मदिन के लिए दे सकते हैं।

FinamTrade ट्रेडिंग प्लेटफॉर्म , जिसमें शुरुआती लोगों के लिए शून्य कमीशन दर भी है।

Comon.ru - पेशेवर व्यापारियों के लेनदेन की स्वचालित पुनरावृत्ति की एक प्रणाली - शुरुआती निवेशकों के लिए एक समाधान और जिनके पास अपना स्वयं का निवेश पोर्टफोलियो बनाने के लिए पर्याप्त खाली समय नहीं है।

व्यापारियों के लिए सामाजिक नेटवर्क और बहुत कुछ ।

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

विकास में, हम विभिन्न प्रौद्योगिकी ढेर का उपयोग करते हैं:

• सीमावर्ती: React.js, VUE.js.
• भाषाएँ: सी #, पीएचपी, सी ++, जावा, मोबाइल।
• डेटाबेस: MSSQL, PostgreSQL, Oracle।
• प्लेटफ़ॉर्म: SharePoint, 1C, डायसॉफ्ट, MS CRM और बहुत कुछ।

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



रंग से, मैंने दिखाया कि टीमों को अलग-अलग तरीकों से आयोजित किया जाता है। कुछ एक उत्पाद बनाते हैं, अन्य कई उत्पाद बनाते हैं। और ऐसे उत्पाद हैं जो कई टीमों को एक साथ विकसित कर रहे हैं (उदाहरण के लिए, एक आंतरिक बैक ऑफिस)।

मैं अपनी कहानी को दो टीमों के उदाहरणों पर ले जाऊंगा, मैं सशर्त रूप से उन्हें टीम 1 और टीम 2 कहूंगा।

टीम १

पहली टीम ने एक आंतरिक सूचना प्रणाली विकसित की। प्रारंभ में, यह इस तरह दिखता था:

• एक कर्मचारी मंच के वर्तमान संस्करण में एक विशेषज्ञ था। इस प्लेटफ़ॉर्म को नई रेल में स्थानांतरित करने का एक कार्य था, क्योंकि पुराने संस्करण का अब समर्थन नहीं किया गया था।
• हमने एक नया कर्मचारी लिया जो मंच के नए संस्करण में एक विशेषज्ञ था। वह इस नए संस्करण में सभी कार्यक्षमता को पोर्ट करने में शामिल था।

टीम 2

दूसरी टीम ने कई आंतरिक सिस्टम विकसित किए:

• एक कर्मचारी एक प्रणाली में एक विशेषज्ञ है।
• एक अन्य कर्मचारी अन्य प्रणालियों में एक विशेषज्ञ है।
• और कुछ प्रणालियों को दोनों कर्मचारियों द्वारा एक साथ विकसित किया गया था।

विशेषज्ञों के बारे में

यह कोई संयोग नहीं है कि शब्द "विशेषज्ञ" ऊपर पाठ में हाइलाइट किया गया है। मैं स्पष्ट करना चाहता हूं कि विशेषज्ञ इस बातचीत के ढांचे में कौन है। स्टार वार्स से एक मास्टर के रूप में, इस व्यक्ति के पास पावर: अपने विषय क्षेत्र में, प्रौद्योगिकी में, उत्पाद में गहरी क्षमता है। यह आमतौर पर एक व्यवसाय के लिए सुविधाजनक है, क्योंकि यह एक प्रविष्टि बिंदु देता है: विशेषज्ञों से पूछा जाता है कि यह कैसे करना है या यह कब किया जाएगा, अगर यह नए कार्यों का सवाल है, या वे सवाल पूछते हैं कि क्या कुछ टूट गया है या सही ढंग से काम नहीं कर रहा है।

मैं फिल्म "स्टार वार्स" से जेडी मास्टर के रूप में इस तरह के एक विशेषज्ञ की कल्पना करता हूं - वह कुछ भी कर सकता है (अच्छी तरह से, या लगभग सब कुछ)।


लेकिन जेडी विशेषज्ञ में इसकी कमियां हैं:

• उसे लंबे समय तक "उठाए" रहने की आवश्यकता है ताकि वह इस बल को स्वीकार करे।
• जब वह छुट्टी पर जाता है, तो यह हमेशा होता है: "हम सभी क्या करने जा रहे हैं?"

इन माइनस के प्रभाव को दूर करने के लिए, हमने योग्यता मैट्रिसेस को बनाए रखने के लिए एक प्रणाली विकसित की है, जिसकी चर्चा मैं बाद में करूंगा। मैं ध्यान देता हूं कि हमने इसे सभी टीमों में लागू नहीं किया था, लेकिन केवल जहां समस्याएं थीं। छोटी-छोटी टीमों में सबसे खराब चीजें थीं।

हमारा मुख्य सिरदर्द सवाल था "क्या होता है अगर विशेषज्ञ को कुछ होता है, जैसा कि नीचे दी गई तस्वीर में मास्टर योदा के साथ है?"



और आपने शायद बस कारक की अवधारणा के बारे में भी सुना है।

बस कारक

बस कारक व्यक्तिगत परियोजना के सदस्यों के बीच जानकारी की एकाग्रता का एक उपाय है।

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

जब आपके पास एक विशेषज्ञ होता है, तो बस कारक एक के बराबर होता है, अर्थात, परियोजना के सभी जोखिम एक व्यक्ति के हाथों में होते हैं, और यह खराब है।

इतिहास से एक उदाहरण: स्मोलेंस्क के पास 2010 में एक विमान दुर्घटना हुई थी जिसमें पोलैंड के शीर्ष नेतृत्व सहित 96 लोगों की मौत हो गई थी। इस घटना के बाद, पोलैंड में एक नियम को मंजूरी दी गई - राज्य के चार शीर्ष नेताओं (राष्ट्रपति, प्रधानमंत्री, सीनेट के स्पीकर, सेजम के स्पीकर) को किसी भी परिस्थिति में एक साथ नहीं उड़ना चाहिए। यह बस कारक के खिलाफ एक सुरक्षा कारक है।

जैसा कि आप जानते हैं, टीमों 1 और 2 में, विशेषज्ञ विनिमेय नहीं थे, और इससे संभावित समस्याएं पैदा हुईं। बस फैक्टर को बढ़ाने के लिए, और जेडी विशेषज्ञों की दक्षताओं का विस्तार करने के लिए कुछ करना आवश्यक था। हमने निम्नलिखित कदम उठाए हैं।

चरण 1. बस कारक बढ़ाएँ

जेडी अकेला नहीं होना चाहिए। इसलिए, जेडी को प्रशिक्षित करने और प्रशिक्षित करने के लिए आवश्यक है, ताकि उनमें से अधिक हो।



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

जब हम तय करते हैं कि जेडी कौन बनता है, तो हम पडावों पर सहमत होते हैं, भूमिकाएं वितरित करते हैं और प्रबंधन तालिका में उनकी कल्पना करते हैं:



यहां क्षैतिज उत्पाद, क्षेत्र या मॉड्यूल हैं। उदाहरण के लिए, यदि उत्पाद 1C है, तो यह "वेतन और कार्मिक" या "लेखा" या अन्य मॉड्यूल हो सकता है। ऊर्ध्वाधर कॉलम कर्मचारियों को इंगित करते हैं। चौराहे पर हम भूमिकाओं में प्रवेश करते हैं - जेडी कौन है, पदवन कौन है। इससे स्पष्ट वितरण होता है।

कुछ नियम हैं जिन्हें हमने वितरण शुरू करने पर सहमति व्यक्त की है।

वितरण नियम, भाग 1:

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

ऐसा लगता है कि सब कुछ तार्किक रूप से वितरित किया गया था, और यह इस तरह निकला:



एक उत्पाद पर काम करने वाली पहली टीम में, एक व्यक्ति ने पुराने उत्पाद (सूर्यास्त) पर काम किया, दूसरे ने नए (सूर्यास्त 2.0) पर। उत्पाद के "अपने" संस्करण में, कर्मचारी को "विदेशी" संस्करण में जेडी माना जाता था - पदावन, एक अन्य कर्मचारी का छात्र।



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

चरण 2. नियंत्रण ज्ञान साझाकरण

लेकिन यह कैसे सत्यापित करें कि Padawan एक जेडी में विकसित होगा, जिसमें सभी ज्ञान की शक्ति होगी?

हम ज्ञान को ठीक करते हैं

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

अपघटन के उदाहरणों के साथ हमारे संघर्ष के कुछ स्क्रीनशॉट।

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



कार्यक्षमता द्वारा। यहां हमने सिस्टम के पृष्ठों और अनुभागों पर ज्ञान की इकाइयों को चित्रित किया।



तकनीकी ज्ञान के लिए। हमने टीम के तकनीकी ज्ञान के अनुसार कुछ उत्पादों को रखा।



आप किसी अन्य तरीके से विघटित कर सकते हैं, मुख्य बात यह है कि आप अपने उत्पाद पर ज्ञान को बड़ी संख्या में परमाणु तत्वों में स्प्रे कर सकते हैं।

प्रलेखन जोड़ें

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

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

रेटिंग जोड़ें

"दस्तावेज़ीकरण" कॉलम के दाईं ओर, हमने प्रत्येक टीम के सदस्य के लिए एक कॉलम जोड़ा और मूल्यांकन किया कि प्रत्येक कर्मचारी को कितना ज्ञान है।



मैं रेटिंगों को समझूंगा:

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

पहले संस्करण में, हमारे पास पाँच ग्रेड थे - स्कूल ने हमें 1 से 5. तक गिनती करना सिखाया था, लेकिन फिर यह पता चला कि चार-बिंदु प्रणाली पर्याप्त थी, हमने इसे रोक दिया।

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

चरण 3. इसे विज़ुअलाइज़ करें

तीसरे चरण में, यह सवाल उठा - मैं, प्रबंधक, तुरंत कैसे और स्पष्ट रूप से देखते हैं कि टीम के भीतर ज्ञान का निर्माण कैसे होता है?

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

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



उसके बाद, हमने अपने नियमों को और परिष्कृत किया।

वितरण नियम, भाग 2:

• जेडी को पहले "हरा जाना" चाहिए। यही है, हम जेडी को पंप करने पर ध्यान केंद्रित करते हैं। मुख्य जिम्मेदार को जल्द से जल्द सक्षम बनना चाहिए। खासकर अगर यह एक नया कर्मचारी है।
• प्रशिक्षण पूरी तरह से पूरा होने पर कम से कम एक पडावन को हरा होना चाहिए। लेकिन वह जेडी के ज्ञान को पकड़ने की जल्दी में नहीं हो सकता है, यहां मुख्य बात यह है कि रोकना नहीं है।
• बाकी के पडावन सीखने की प्रक्रिया में हो सकते हैं। हमारा कार्य "स्मीयर" ज्ञान को भूलना नहीं है, यह सुनिश्चित करने के लिए कि कर्मचारियों के ज्ञान के क्षेत्र में अंतर और कवरेज अधिकतम है।

आवश्यकताओं में अंतर करना

प्रणाली शुरू करने के पहले चरण के लिए, जिस पर ज्ञान का वर्णन और डिजिटलीकरण अभी शुरू हो रहा है, वहाँ अच्छा अभ्यास है: जेडी और पडावन के लिए आवश्यकताओं को अलग करना।

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



यह आरंभ करने के लिए पर्याप्त था। अगले चरण में, आप बार उठा सकते हैं और कह सकते हैं कि अब सभी संख्याएँ समान होनी चाहिए।

और अब हमारी प्लेटें रंग गई हैं और सब कुछ अधिक दिलचस्प और समझ में आता है:



हम डेढ़ साल बाद कुछ हरे चित्रों में गए। हम धीरे-धीरे टीम के नेताओं के साथ इकट्ठा हुए, हर दो हफ्ते या महीने में एक बार, देखते थे कि क्या हो रहा है, लगातार कुछ अद्यतन किया।

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

प्रत्येक नया कर्मचारी हमेशा रेड जोन में होता है, उसे जल्द से जल्द प्रशिक्षित और पंप करने की आवश्यकता होती है। लेकिन कैसे?

चरण 4. ज्ञान और कौशल को पंप करना

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

हमें समझ में आया कि हमें यह सुनिश्चित करने का प्रयास करना चाहिए कि उत्पाद की विघटित तालिका की एक पंक्ति एक ज्ञान (प्रलेखन का एक पृष्ठ) से मेल खाती है।



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

हम दो भरने के तरीकों का उपयोग करते हैं:

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

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

दस्तावेजों के साथ काम करने के अलावा, हम तकनीकी वार्ता करते हैं। लेकिन प्रलेखन बुनियादी है। मेरा मानना ​​है कि सभी प्रक्रियाओं को नियंत्रित करने का यह सबसे अच्छा तरीका है। प्रलेखन में, सब कुछ अलमारियों पर रखा गया है, एक पूरी तस्वीर दिखाई दे रही है और आप ज्ञान के प्रसार और संचय को प्रभावित कर सकते हैं।

इसलिए, हमने अपनी जरूरत की सभी चीजों का दस्तावेजीकरण किया है। अगला चरण अपडेट हो रहा है।

अद्यतन

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

यदि आपके कंफ़्लुएंस स्थान में आपकी टीम इन परिवर्तनों के लिए सदस्यता लेती है, तो यह सूचनाएँ प्राप्त करेगा कि क्या जोड़ा गया है, परिवर्तित किया गया है, बेहतर किया गया है, क्योंकि Atlassian Confluence में हैं:

• पृष्ठ परिवर्तन का इतिहास - आप हमेशा देख सकते हैं कि क्या और कब बदला है।
• पृष्ठ अद्यतन सूचनाओं की सदस्यता लें।
• कचरा के माध्यम से हटाएँ।

आसानी से, टोकरी के माध्यम से एक विलोपन है। यदि कोई गलती से "डिलीट पेज" पर क्लिक कर देता है, तो भी यह खो नहीं जाएगा। आप इसे पुनर्स्थापित कर सकते हैं और यह पता लगा सकते हैं कि किसी ने आपके स्थान से इस ज्ञान को उखाड़ने की कोशिश क्यों की।

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

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

और अगर छुट्टी की योजना बनाने से पहले, "उसके बिना हम क्या करेंगे" पर चर्चा कर रहे हैं, मेरे लिए यह टीम के नेता के साथ एक व्यक्तिगत बैठक में एक अवसर है कि उनकी टीम में ज्ञान के हस्तांतरण के साथ क्या होता है।

आपको यह समझने की आवश्यकता है कि प्रलेखन हमेशा कुछ पढ़ने या सीखने के बारे में नहीं है। अक्सर आपको कुछ करने की आवश्यकता होती है: एक्सेस का अनुरोध करें, प्रोग्राम इंस्टॉल करें, प्रोग्राम में कुछ खोलें। इन क्रियाओं के दौरान, अद्यतन होता रहता है। , , . , , , . .

के उपयोग

?



. . , 4 , . , , - . , , . , , . , .

, . : « , . , ».

, — , . «», , . , : « , . ».



. , , 1, 2, 3, 4 . , , . . , , 1, 2, 3, 4. .

« »

KPI, : « - KPI , - - , ». , , , , . — .

— , , .

Bus factor

: , . , bus- , , , . : , . , . , , . , , . . : «, . - , ».

, , . () . , , . ( ). . , — . .


. , , . , . , . .

निष्कर्ष

, , , .

« ! ». . !

TeamLead Conf 2020 , . , «», . , . , , , telegram- . 10 11 !