कम्पनीमा ज्ञान आदानप्रदान कसरी स्थापना गर्ने ताकि यसले धेरै चोट नपरोस्

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

ज्ञान =/= दस्तावेज। यो व्याख्या गर्न सकिँदैन, यो सम्झना हुनुपर्छ

यसबाट केहि जान्न चाहनेहरूले कहाँ र कसरी फेला पार्ने भन्ने कुरा बुझ्छन् भन्ने कुरा कसरी सुनिश्चित गर्ने, र व्यक्तिगत चीजहरू र सम्झौताहरू बारे सचेत हुन आवश्यक सबैले ती परिवर्तनहरूको बारेमा तुरुन्त र सही रूपमा पत्ता लगाउन सक्छन्।

"टीम लीड विल कल" पोडकास्टको अन्तिम एपिसोडमा, स्काइङका केटाहरूले इगोरसँग ज्ञान व्यवस्थापनको बारेमा कुरा गरे। may-cat Tsupko KnowledgeConf कार्यक्रम समितिमा एक व्यक्ति र Flant मा "अज्ञात निर्देशक" हुनुहुन्छ।

पूर्ण रेकर्डिङ रूपमा उपलब्ध छ YouTube भिडियो, र तल हामीले केही रोचक सुझावहरू र उपयोगी सामग्रीहरूको लिङ्कहरू सङ्कलन गरेका छौं जुन अडियोमा उल्लेख गरिएको थियो वा यसबाट जानकारी विस्तार गर्नुहोस्। यदि तपाइँ टिप्पणीहरूमा तपाइँको टोलीको ह्याक र चालहरू साझा गर्नुभयो भने यो राम्रो हुनेछ।

पहिलो ह्याक: तपाईलाई अब कुन प्रणालीमा हेर्ने भनेर जान्न आवश्यक छैन

"मैले हाम्रा ज्ञान स्रोतहरू लिएँ र तिनीहरूको लागि सामान्य खोज गरें: खोज क्षेत्र कम गर्न फिल्टरिङ प्रणाली भएको एकल विन्डो। हो, एकै समयमा, तपाईंले अझै पनि यसको गुणस्तर अनुगमन गर्न आवश्यक छ, ज्ञानको आधार भर्न, र लडाई नक्कल र गलत जानकारी।

त्यो सबै फेला पार्न कागजको एक टुक्रा

तर पहिले नै, लगभग 60% फ्ल्यान्ट इन्जिनियरहरूले यो खोज दिनको कम्तिमा 1-2 पटक प्रयोग गर्छन् - र सामान्यतया पहिलो वा दोस्रो स्थानमा जवाफहरू फेला पार्छन्। र अवधारणाको प्रमाणको रूपमा गुगल कागजातहरूको अनुक्रमणिका हो: सबै डक्सहरू, फोल्डरहरू, भ्यान ड्राइभहरू, र यस्तै अन्य - यो सबै सजिलैसँग आन्तरिक खोजमा पनि चलाइन्छ।"

दोस्रो ह्याक: च्याटको गुच्छामा कसरी महत्वपूर्ण कुराहरू नछुटाउने

"यदि तपाइँ एक वितरित टोलीमा काम गर्नुहुन्छ भने, त्यसपछि तपाइँको दिनको एक महत्वपूर्ण भाग Slack मा बित्छ - र जसमा तपाइँ यस्तो केहि गर्न को लागी बानी छ: "@myteam, मद्दत/हेर्नुहोस् / सही एक प्रविष्ट गर्नुहोस् ... "।" तर त्यहाँ जानकारीको प्रचुरता संग एक समस्या छ - र एक अलग उल्लेख अन्य सन्देशहरु बीच छुटाउन सकिन्छ।

Skyeng मा हामीलाई एउटा बोटद्वारा मद्दत गरिन्छ जसको माध्यमबाट तपाईंले सन्देश लेख्न सक्नुहुन्छ र कुनै पनि व्यक्ति वा समूहहरूलाई ट्याग गर्न सक्नुहुन्छ। मानिसहरूले पढ्नु वा प्रतिक्रिया दिनु साँच्चै महत्त्वपूर्ण भएको अवस्थामा हामी यसलाई प्रयोग गर्छौं: तपाईंले "मैले पढें" बटन थिच्नुभएसम्म यो अनन्त रूपमा पोक हुनेछ - तपाईंले यसलाई छोड्न वा बेवास्ता गर्न सक्नुहुन्न।"

जवाफ दिन प्रश्न: कागजात संग के गर्ने?

"धेरै ज्ञान प्राविधिकहरूबाट आउँछ, तर सबैलाई यो कसरी राम्रोसँग वर्णन गर्ने थाहा हुँदैन।
आखिर, तपाइँसँग कुनै कम्पाइलर वा लिन्टर छैन जसले तपाइँलाई यो सही गरिरहनुभएको छ वा छैन भनेर बताउनेछ - र प्रायः हामीसँग भएको आउटपुट बुझ्न नसकिने, खराब ढाँचा र अपूर्ण पाठ हो। निस्सन्देह, तपाईले यसलाई सामान्य रूपमा गर्न आवश्यक छ, किनकि कसैले आएर "यो आवश्यक छ" भन्यो - तपाईले यसलाई राम्रोसँग गर्नुहुन्छ: एक वा दुई महिनामा तपाईले यसलाई पढ्नुहुनेछ र बुझ्नुहुनेछ। र अर्को व्यक्ति, कागजात खोल्दै, तुरुन्तै यसलाई सदाको लागि बन्द गर्दैन, यो बेकार छ भनेर महसुस गर्दै।

पोडकास्टको भाग "राम्रो कागजात लेख्न वा सामान्य डेमो बनाउन कति मानिसहरू लाग्छ" भन्ने प्रश्नमा समर्पित।

तर प्रश्न रहन्छ: यसका लागि कति समय छुट्याउने र कसरी कुशलतापूर्वक गर्ने?
र यदि यहाँ इमानदार जवाफ छ भने: जबसम्म व्यवसायीहरू संलग्न हुँदैनन्, र उनीहरूले राम्रो कागजातको प्रभाव अनुभव नगरेसम्म, प्रयासले थोरै प्रतिफल दिने जोखिम हुन्छ। यो संस्कृति परिवर्तनको बारेमा थप कथा हो।

बाँकीको लागि, अनुभव र सल्लाहले तपाईंलाई बचाउनेछ। जोडी प्रोग्रामिङ, प्रगति ट्र्याकिङ र कोड समीक्षाहरूको एनालगहरू यहाँ उपयुक्त हुन सक्छन् - उत्कृष्ट अभ्यासहरू देखाउँदै, त्रुटिहरूमा पोक गर्दै र अन्तमा बोरिङ।

बोनस: "ठीक छ, म तिनीहरूलाई यसरी भन्छु, तिनीहरूले बुझ्नेछन्"

प्रश्न "यसमा कति समय खर्च गर्ने र कुन स्तरमा यो गर्ने" कागजातको ढाँचा भित्र मात्र होइन, तर सामान्य रूपमा कुनै पनि ज्ञानको स्थानान्तरणको लागि महत्त्वपूर्ण छ। डेमो पनि जानकारी साझा गर्ने उत्कृष्ट उदाहरण हो। तर त्यहाँ सूक्ष्मताहरू छन्: उदाहरणका लागि, कसरी सुनिश्चित गर्ने कि तिनीहरूले न्यूनतम समय लिन्छन्।

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

आंशिक रूपमा, यी समस्याहरू आन्तरिक रिपोर्टहरूको अभ्यास द्वारा हल गर्न सकिन्छ। हप्तामा एक पटक, कम व्यस्त समयमा 40-60 मिनेट लिइन्छ - र केटाहरूले विभिन्न परियोजनाहरूका सहकर्मीहरूको लागि भिडियो रिपोर्ट बनाउँछन्। मुख्य उत्पादनको फ्रन्टएन्ड टोली - Vimbox - भन्नुभयो तपाईंको UI किटको बारेमा, जुन कुनै पनि अन्य परियोजनाको लागि थीम हुन सक्छ। मार्केटिङ विकास टोलीले ट्रेसिङ र लगिङ अनुरोधहरूको लागि पुस्तकालयको बारेमा कुरा गर्यो, जसले तुरुन्तै धेरै अन्य परियोजनाहरूको चासो आकर्षित गर्यो। गणित परियोजना टोलीले REST API बाट GraphQL मा स्विच गर्ने आफ्नो अनुभव साझा गर्यो। समूह पाठ टोलीले PHP 7.4 मा स्विच गर्ने पहिलो व्यक्ति कसरी भयो साझा गर्ने बारे सोचिरहेको छ। र यस्तै।

सूची मे 2018 देखि कायम राखिएको छ र 120 भन्दा बढी प्रविष्टिहरू छन्

सबै बैठकहरू कर्पोरेट Google Meet मार्फत सुरु हुन्छन्, रेकर्ड गरिन्छ र 1.5 घण्टा भित्र साझा Google ड्राइभको फोल्डरमा देखा पर्दछ, र रेकर्डिङका लिङ्कहरू उही Slack मा नक्कल हुन्छन्। अर्थात्, कुनै आपतकालिन अवस्थामा आउनु पर्दैन, तर पछि यसलाई १.५ गतिमा हेर्नुहोस् - सामान्यतया रिपोर्ट आफैं २० मिनेटसम्म रहन्छ, र छलफल - यो कसरी हुन्छ। तर हामी घण्टा भन्दा बाहिर जाँदैनौं)

PS तपाईंको लागि के काम गर्यो र काम गरेन?

उपयोगी लिंकहरू:

• कास्परस्की ल्याबबाट रोडियन नागोर्नोभ बारे ज्ञान व्यवस्थापन के हो र किन यो कागजात होइन (लिङ्कको लागि इगोरको च्यानललाई धन्यवाद "आरामदार आईटी नरक", त्यहाँ यस्तै धेरै छ)।

• फ्ल्यान्टबाट इगोर त्सुप्को यसको बारेमा ज्ञान व्यवस्थापन कसरी कार्यान्वयन गर्ने मेरो कम्पनीमा

• Skyeng बाट Alexey Kataev बास कारक कसरी निगरानी र स्तर गर्ने बारे (प्रविधि र विशिष्ट क्षेत्रहरूमा ज्ञान अन्तर) एक वितरित टोलीमा।

• फ्ल्यान्टबाट सर्गेई गोन्चारुक जानकारी पठाउने बारे - कहिले र कसलाई सोध्ने भनेर कसरी थाहा पाउने, यदि तपाईंले वितरित टोलीमा समस्या सामना गर्नुभयो भने।

स्रोत: www.habr.com