अस्वीकरण: यदि इस पाठ को पढ़ने के बाद आप प्रोग्रामर के लिए KPI लागू करना चाहते हैं - तो इसे भी पढ़ें ।



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



तो, प्रमाणन के लक्ष्य क्या हैं।

लक्ष्यों

• वर्तमान डेवलपर स्तर देखें।
• पता करें कि एक व्यक्ति किन क्षेत्रों को विकसित करने में रुचि रखता है।
• उसी तकनीकी वेक्टर में विकास के लिए एक अवसर प्रदान करने के लिए जिसमें सिबिरिक जाता है, या वैकल्पिक दिशा में (सामान्य विकास के लिए)।
• डेवलपर को प्रतिक्रिया दें: सकारात्मक या नकारात्मक।
• सिफारिशें दें: पंप करने के लिए क्या बेहतर है, क्या खींचने की जरूरत है, क्या पढ़ा जा सकता है।

निर्णय

पूरी योजना को काम करने के लिए, हमने निम्नलिखित प्रमाणन मॉडल को विकसित और कार्यान्वित किया:



चरण 1. सक्षमता कार्ड भरें। प्रमाणन से पहले, प्रत्येक डेवलपर इसे भरता है। यदि आप इसे लागू करते हैं, तो सक्षमता कार्ड को नियमित रूप से भरने के लिए एक अनिवार्य आवश्यकता है।



चरण 2. प्रमाणीकरण ही। डेवलपर के साथ एक पर हमेशा होता है।



हम बात करते हैं और योग्यता कार्ड की तुलना करते हैं: वर्तमान और पिछले। तो आप किसी विशेष व्यक्ति के अभिविन्यास की प्रगति और परिवर्तन को ट्रैक कर सकते हैं।



अगला - डेवलपर की जरूरतों (तकनीकी "विशलिस्ट") का विश्लेषण किया जाता है। किसी प्रकार की तकनीक को पंप करने में मदद के लिए, स्टूडियो तीन विकल्प प्रदान कर सकता है:

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

उत्तरार्द्ध के संबंध में, संदर्भ की सूची को अब सक्षमता के नक्शे में जोड़ा गया है: किताबें, जिनके बिना अपने आप को "शांत" मानना ​​मुश्किल है। ठीक है, या कम से कम वे बढ़ती स्थिरता की प्रक्रिया को बहुत तेज करते हैं।



चरण 3. कोडरेव्यू। मैं प्रोग्रामर के कोड को देखता हूं - वास्तविक परियोजनाएं जिस पर उन्होंने पिछले छह महीनों में काम किया था।



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

---

“बात सस्ती है। मुझे कोड दिखाओ। ”

लिनुस के धड़

---

चरण 4. समेटना। नतीजतन, डेवलपर को तीन मूल्यवान निर्देश प्राप्त होते हैं: क्या पढ़ना है, क्या खींचना है, नए से क्या प्रयास करना है।



उदाहरण के लिए, प्रमाणपत्रों में से एक के दौरान, डेवलपर और मैंने फैसला किया कि उसे लिनक्स में पंप करने की आवश्यकता है। नतीजतन, विंडोज को उसकी कार्यशील मशीन पर ध्वस्त कर दिया गया।

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

हमारे प्रमाणन प्रणाली में जो नहीं है वह बिंदु प्रणाली और अन्य औपचारिकताएं हैं।

कुल। कार्यान्वयन कठिनाइयों

यदि आप ऐसा कुछ परिचय देना चाहते हैं, तो कम से कम तीन कठिनाइयों के लिए तैयार रहें:

• यह बहुत समय लेने वाला है।
• प्रत्येक नेता ऐसा नहीं करना चाहता है: बात करें, पता करें और स्पष्ट करें ताकि कोई गलतफहमी और चूक न हो।
• प्रमाणीकरण के परिणामस्वरूप आपको जो सलाह दी जाती है, वह केवल एक व्यक्तिगत योजना में प्रवेश और कार्यान्वयन की निगरानी के साथ सिफारिशें और लंबवत निर्देश हैं।

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



प्रमाणन का उद्देश्य: डेवलपर को जज करना नहीं, बल्कि उसे बढ़ने में मदद करना। सफल प्रमाणपत्रों के एक जोड़े के परिणामों के अनुसार, एक डेवलपर को वेतन उन्नयन का अनुभव हो सकता है। एक अच्छे तरीके से, प्रमाणीकरण को नियमित रूप से किया जाना चाहिए (वर्ष में कई बार)।



मैं नीचे दिए गए विचारों और टिप्पणियों को साहसपूर्वक व्यक्त करने का सुझाव देता हूं, मैं खुशी के साथ सुनूंगा और जवाब दूंगा!