एक टेक लीड के रूप में मैंने जो आश्चर्यजनक सबक सीखे हैं

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

मैं अपने करियर के इस नए चरण को लेकर बहुत उत्साहित हूँ। मैंने बहुत कुछ सीखा है और इस यात्रा के कुछ अंश समुदाय के साथ साझा करना चाहूँगा। मुझे उम्मीद है कि यहाँ प्रस्तुत जानकारी पाठकों के लिए बहुत उपयोगी होगी।

लोग पहले - सॉफ्ट स्किल्स का महत्व

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

जब मैंने तकनीकी विकास नेता के रूप में अपनी भूमिका संभाली, तो मेरी जिम्मेदारियों में से एक एचआर (हां, वही लोग जिनके साथ चयन प्रक्रिया में भाग लेने का कारण मुझे समझ में नहीं आया) के साथ तकनीकी परीक्षण तैयार करने और बैकएंड क्षेत्र में शुरुआत करने वाले दो उम्मीदवारों के लिए साक्षात्कार प्रारूप को परिभाषित करने में सहयोग करना था। मुझे लगा कि मैं पहले से ही जानता हूं कि बैकएंड क्षेत्र में एक शुरुआती डेवलपर को क्या पेश करना चाहिए और परीक्षण में क्या अंतर माना जाएगा। हालांकि, मुझे उम्मीद नहीं थी कि कोड के महत्व के बावजूद, परियोजना वितरण से परे अन्य मांगें उठीं: संचार के संदर्भ में उम्मीदवारों का मूल्यांकन कैसे करें? स्थिति में उनकी रुचि क्या है? और वे जो संदर्भ प्रस्तुत करते हैं, वह प्रस्तावित स्थिति के लिए उनकी उपयुक्तता को कैसे प्रभावित कर सकता है? ये और अन्य प्रश्न दोनों उम्मीदवारों द्वारा प्रस्तुत कोड की तरह ही प्रासंगिक निकले

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

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

जूनियर और सीनियर के बीच की रेखा (नहीं, मध्य स्तर नहीं)।

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

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

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

किसी परियोजना का नेतृत्व करने का मेरा पहला अनुभव

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

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

निष्कर्ष और अतीत पर एक नज़र - गुरु के प्रति स्नेहपूर्वक

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

लेकिन हां, मैंने एक डेवलपर के रूप में विभिन्न स्तरों पर गहनता से काम किया और अपने पूरे करियर में मुझे विभिन्न प्रकार के वरिष्ठ पेशेवरों से मिलने का अवसर मिला:

1. वह बहुत ही सक्षम और प्रभावी वरिष्ठ व्यक्ति थे, लेकिन उनकी कार्यपद्धति के बारे में स्पष्टीकरण दिए बिना ही उन्होंने समस्याओं का समाधान कर दिया।
2. वरिष्ठ छात्र संचार और शिक्षण में उत्कृष्ट है, लेकिन अक्सर जरूरी कार्यों में व्यस्त रहता है और पढ़ाने के लिए उसके पास समय नहीं होता।
3. वह वरिष्ठ व्यक्ति जो अति-इंजीनियरिंग और प्रौद्योगिकी के केंद्रीकरण के प्रति उत्साही था, लेकिन जो समय-सीमाओं को पूरा करता था और जो वादा करता था उसे पूरा करता था।

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