यह संभव है कि आप कहें: “योग्यता का मैट्रिक्स? वास्तव में? ” सबसे अधिक संभावना है कि आपने पहले ही इस उपकरण के बारे में कुछ सुना है, और यहां तक ​​कि कोई निष्कर्ष भी निकाला है कि आप इसका उपयोग क्यों नहीं करना चाहते हैं। शायद यह पहले नहीं था, या कैसे जानलेवा तर्क "ऐसा ऐतिहासिक रूप से हुआ ..."।

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

और इसके साथ क्या करने के लिए ड्रेगन है, हम कट के तहत समझाएंगे।



यह लेख हमारी टीम कॉन्स्टेंटिन काफ्तान के साथ टीमलाइड कॉन्फ पर आधारित है । Konstantin Timlid, IPONWEB तकनीकी सहायता विभाग, और मैं IPONWEB में विकास टीम का तकनीकी लेखक हूं, जो ज्ञान प्रबंधन में लगा हुआ है।

कहानी IPONWEB व्यावहारिक मामलों पर बनी है, इसलिए पहले कंपनी को थोड़ा जान लें ताकि आप समझ सकें कि क्या यह सामग्री आपके करीब है।

हमारे एचआर ने एक शांत विपणन तस्वीर के लिए एक अनुरोध पर, जो हमारे क्षेत्र के बारे में बताएगा, यह दिया:


दरअसल, IPONWEB उन ग्राहकों के लिए प्लेटफॉर्म विकसित कर रहा है जो ऑनलाइन विज्ञापन में संलग्न हैं। हम सॉफ्टवेयर के मॉडल पर सेवा के रूप में काम कर रहे हैं (या सेवा के रूप में प्लेटफ़ॉर्म)। हमारे पास कई घटक हैं: HTTP सर्वर, एल्गोरिथ्म की भविष्यवाणी, यूआई, रिपोर्टिंग। लुआ में लिखी गई लगभग 50 परियोजनाओं के लिए व्यावसायिक तर्क।

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

हमने "ड्रेगन लाइव हियर" नाम क्यों चुना, इसका क्या मतलब है? तो पहले मध्ययुगीन मानचित्र निर्दिष्ट स्थानों पर जहां यह ज्ञात नहीं है कि क्या हो रहा है - ऐसे टेरा इंकोगनिता। इस बारे में दो कहानियां हैं। पहला कौशल और कौशल की संरचना के बारे में है जो टीम के पास है, और टीम जितनी बड़ी होगी, उतने अधिक टेरा इंकोगनिता हैं; और दूसरे के बारे में थोड़ी देर बाद बात करते हैं।

हम यहां कैसे पहुंचे?

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

टीम प्रोफाइल

कोंस्टेंटिन की तकनीकी सहायता टीम:

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

मेरी लुआ विकास टीम:

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

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

लक्ष्य और ट्रिगर

तकनीकी सहायता टीम में:

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

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

देव टीम में यह आवश्यक था:

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

एक पक्ष लक्ष्य भी था - एक एकल समन्वय प्रणाली में लक्ष्यों को तैयार करने के लिए प्रदर्शन की समीक्षा प्रक्रिया को अधिक पारदर्शी, समझने योग्य बनाने के लिए ।

प्रदर्शन की समीक्षा

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

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

आपको एक योग्यता मैट्रिक्स की आवश्यकता क्यों है

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

आपको यह सब क्यों चाहिए? आप हमारे व्यावहारिक मामलों के बारे में जानेंगे, लेकिन आपके पास एक उचित सवाल हो सकता है - कैसे समझें कि मुझे इसकी आवश्यकता है?

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

कहां से शुरू करें

कहां से शुरू करें हम अपने उदाहरण से बताएंगे।

तकनीकी सहायता टीम में, हम: उन कार्यों की पहचान करते हैं जो हम में लगे हुए हैं; अलग-अलग जोड़तोड़ में विघटित कार्य; पता चला कि किसी विशेष क्षेत्र में काम करने के लिए एक कर्मचारी को कौन से उपकरण होने चाहिए।

नीचे थोड़ा सरल उदाहरण दिया गया है।


टीम में कर्मचारी बैटमैन, जोकर, फ्लैश और इवानोव और मानक कार्य हैं:

• सामान्य यातायात निदान;
• सौदा यातायात के निदान;
• तैनाती की निगरानी;
• नए भागीदारों, दोनों डीएसपी और एसएसपी, दोनों खरीदारों और विक्रेताओं के एकीकरण का परीक्षण।

हमारे पास जो उपकरण हैं:

• uSIicer आपको बहुत विस्तृत ट्रेडिंग नंबर प्राप्त करने की अनुमति देता है;
• ग्रेफाइट वास्तविक समय सिस्टम स्थिति डेटा प्रदान करता है;
• Google BigQuery (BQ) - हमारे लॉग वहां रहते हैं;
• ग्राफाना, जो आपको ग्रेफाइट से मैट्रिक्स को एकत्र करने की अनुमति देता है, यदि आवश्यक हो तो उस पर अलर्ट डालना सुविधाजनक है;
• व्यवस्थापक इंटरफ़ेस में उल-समायोजन, जो आपको किसी विशेष भागीदार, ट्रेडिंग जोड़ी, डेटा सेंटर, आदि के लिए ट्रैफ़िक मापदंडों को बदलने की अनुमति देता है।

तब हमें पता चला कि कौन क्या और किस हद तक जानता है।


2 - एक विशेषज्ञ जो सिखा सकता है; 1 - इसका मतलब है कि कोई व्यक्ति कम या ज्यादा जानता है; खाली कोशिकाओं के बजाय, ताकि किसी को नाराज न करें।

हम एक तालिका में सारांशित करते हैं:


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

नेझदान्स्की (समर्थन)

कई अप्रत्याशित लोग सामने आए जिन्होंने समझने में मदद की:

• सहकर्मियों में से कौन सा कौशल उन्हें नए कार्यों के लिए आकर्षित करने के लिए निकाला जाना चाहिए? (विकास की दिशा इंगित करें);
• कर्मचारी के नुकसान की स्थिति में समस्याएं कहां से उत्पन्न हो सकती हैं?
• अपने टास्क पूल में कर्मचारी का वेतन कितना पर्याप्त है?
• टीम को कितनी अच्छी तरह से प्रशिक्षित और प्रशिक्षित किया गया है?

हम बाद में प्रत्येक बिंदु पर ध्यान केन्द्रित करेंगे।

चलिए वापस टेबल पर आते हैं।



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

जोकर आमतौर पर अच्छी तरह से किया जाता है - वह लगभग हर जगह प्रेमी होता है, सिवाय शायद निगरानी के, लेकिन यह सिखाया जा सकता है।



यह सर्वविदित है कि जोकर अपने खाली समय को कुछ हद तक सनकी तरीके से बिताता है और किसी भी समय काम से बाहर हो सकता है। तब क्या होगा? फिर सौदा यातायात के निदान से सब कुछ दुखी होगा।

इतना ही नहीं, हमारे पास BQ विशेषज्ञ नहीं है! यही है, किसी को ऊपर खींचने, प्रशिक्षित करने के लिए जरूरी है। उदाहरण के लिए, आप बैटमैन बीक्यू, और इवानोव - ग्रेफाइट सिखा सकते हैं।



इस तरह की सरलीकृत मूल्यांकन प्रणाली के साथ, आप यह समझने के लिए कि वह कितना सक्षम और कुशल है, प्रत्येक कर्मचारी के लिए एक निश्चित राशि प्राप्त कर सकता है। इन अनुमानों ने एक और अप्रत्याशित फेंक दिया।

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

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

देव की टीम

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

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

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

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

हमने इन सभी कौशलों को तुरंत शामिल नहीं किया, क्योंकि हमें समझ नहीं आया कि इनका सही मूल्यांकन कैसे किया जाए।

दूसरे पुनरावृत्ति में, उन्होंने मूल्यांकन प्रणाली में प्रवेश किया:

• कार्यों का विघटन और उससे जुड़ी हर चीज;
• प्रलेखन और स्व-दस्तावेजीकरण कोड
• परियोजना प्रबंधक के साथ संवाद करने की क्षमता, अर्थात यह समझने के लिए कि वह क्या कह रहा है और बदले में आवश्यक प्रश्नों को प्रस्तुत करता है;
• कोड समीक्षाओं, आदि पर टिप्पणियों को सही ढंग से तैयार करने की क्षमता

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

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

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

फिर हमने प्रत्येक कौशल के लिए 1 से 3 के पैमाने पर डेवलपर्स को वर्गीकृत किया।

जिन कौशलों का हम प्रारंभिक सर्वेक्षण की मदद से मूल्यांकन नहीं कर सके, हमने उनका मूल्यांकन साथियों (साथियों) की मदद से किया, यानी उन्होंने सहकर्मियों का मूल्यांकन करने के लिए कहा। उस समय, हमारे पास कोई समूह नेता नहीं था, अन्यथा वे ऐसा कर सकते थे।

यह मैट्रिक्स कुछ इस तरह दिखता है।



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

रंग ग्रेड के अनुरूप हैं। समान मेट्रिक्स का समर्थन टीम में किया गया था - कौशल में कुल और विभिन्न औसत।

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

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

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

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

आपको स्पष्ट रूप से परिभाषित करने और सभी को इसे पास करने की आवश्यकता है, उदाहरण के लिए, कि लूआ ज्ञान में स्कोर है:

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

तो आप प्रत्येक कौशल को विघटित कर सकते हैं, क्योंकि कहीं न कहीं अंतर्ज्ञान के स्तर पर आपके पास पहले से ही है।

स्वयं पर ध्यान दें:

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

कैसे लागू करें?

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

व्यक्तिगत कौशल के मूल्यांकन के अलावा, हमें ग्रेडर डेवलपर्स की आवश्यकता है। हमारे पास ए, बी और सी ग्रेड थे - कनिष्ठ, मध्य, वरिष्ठ जैसे कुछ। आईटी जूनियर, मध्य, वरिष्ठ, यह पहले से ही बहुत अधिक अर्थ से भरा है, जिसमें, अन्य चीजों के अलावा, कार्य अनुभव का निवेश किया जाता है। , . A, B C — . « » .

— .

, . , , , , .

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

, . , , . , . .

performance review . , 1 2, ( ) .

— performance review , .

(Dev Team)

. , , . , , , . . 5-6 2-3. . -, , . ( ) .

, , . . , , , . , , . , , playground, .

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

. , - : « ? ?».

, , , — , , , . .

मामलों

, . - , , .



, CI, . , . , 8.



, , , , , -. .

, — -. .


:

• 4 , .. ;
• 1 , ;
• 0,5 HR-, , , .

और वह सब है! 30 . , , , , , , .

Dev Team

. : ( ) 3-4 . , :

• , — 3-4 ( 4 ) — , .
• , , , , — 6 .
• . . , senior'. 2 knowledge- 2 .
• — ( 3-4 ). , 100 , .
• — 2 . , .

, - , - . .

, .

— , .

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


Support - easy medium, Dev Team — medium.

, , . , . , , , .

.

• , , .

, , . ( ), . performance review, .

, , — . .

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

, HR, , -, , -, , , -, HR - . HR , , .

• , .

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

• Don't try this at home — - , :)

, .

, , KnowledgeConf 2019 26 .

, ( , , , , ) ( ).

. , , , . .