जॉन ओलस्पॉ के इस बेहतरीन लेख का शीर्षक है "बीइंग ए लीड इंजीनियर । " पहली बार मैंने इसे लगभग चार साल पहले पढ़ा था, जब मैंने बस अपनी वर्तमान नौकरी पर स्विच किया था, और इसने मेरे करियर के इस क्षेत्र के बारे में विचारों को प्रभावित किया।

अब इसे फिर से तैयार करने के बाद, एक बात वास्तव में दिलचस्प लगती है, कि सहानुभूति और टीम की मदद करना वरिष्ठों के काम का एक महत्वपूर्ण हिस्सा है। कौन सा सच है!

लेकिन अब मैं देख रहा हूं कि मुझे पता है कि अधिकांश या सभी प्रमुख इंजीनियर अपने निजी प्रोग्रामिंग कार्य के अलावा अन्य कर्मचारियों की महत्वपूर्ण मदद करते हैं। अब यह मुझे लगता है कि मेरे सहयोगियों और मुझे इस समस्या का सामना नहीं करना पड़ रहा है “क्या ?? लोगों के साथ बात करने की जरूरत है ?? INCREDIBLE ”, एक और समस्या के साथ कितना:“ अपने व्यक्तिगत इनपुट / प्रोग्रामिंग के साथ इस सभी नेतृत्व के काम को कैसे संतुलित करें? मुझे कितना और किस तरह का काम करना चाहिए? ” इसलिए, ओलस्पॉ लेख से (जहां मैं पूरी तरह से सहमत हूं) से सीग्नॉरिटी के संकेतों के बारे में बात करने के बजाय, हम उस काम के बारे में बात करना चाहते हैं जो हम कर रहे हैं।

यह लेख किस बारे में है

"एक प्रमुख इंजीनियर क्या करता है" एक बहुत बड़ा विषय है, लेकिन यहाँ सिर्फ एक छोटा सा लेख है, इसलिए आपको ध्यान रखना चाहिए:

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

जिम्मेदारियां क्या हैं

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

इस काम के लगभग सभी अनिवार्य रूप से तकनीकी हैं : किसी को एक जटिल परियोजना से निपटने में मदद करना स्पष्ट रूप से मानवीय संपर्क है, लेकिन हम जिन समस्याओं के साथ मिलकर काम करेंगे, वे आमतौर पर तकनीकी होंगे! ("हो सकता है, यदि हम डिजाइन को सरल बनाते हैं, तो हम तेजी से सामना कर सकते हैं!")।

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

मैंने "लेखन कोड" पहले स्थान पर रखा है, क्योंकि वास्तव में यह कार्य आसानी से प्राथमिकताओं की सूची को नीचे गिरा देता है। :)

सूची में कोई आइटम "अनुमान / पूर्वानुमान न करें" है। मैं अभी तक यहाँ बहुत अच्छा नहीं हूँ, लेकिन मुझे लगता है कि किसी दिन इस पर अधिक समय बिताने के लायक है।

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

क्या कर्तव्य नहीं है

यह थोड़ा और जटिल है। मैं यह नहीं कह रहा हूं कि आप ऐसी चीजों से स्पष्ट रूप से नहीं निपट सकते। अधिकांश प्रमुख इंजीनियरों को पता है कि मैं इन समस्याओं के बारे में सोचने में बहुत समय बिताता हूं, और इस दिशा में थोड़ा काम करता हूं।

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

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

• यह सुनिश्चित करने के लिए कि प्रत्येक कर्मचारी को उसके काम के लिए उसकी योग्यता के अनुसार पुरस्कृत किया जाता है।
• सुनिश्चित करें कि काम काफी वितरित किया गया है।
• सुनिश्चित करें कि लोग एक साथ अच्छी तरह से काम करते हैं।
• टीम सामंजस्य सुनिश्चित करें।
• प्रत्येक कर्मचारी के साथ निजी तौर पर बात करें।
• नए प्रबंधकों को प्रशिक्षित करें, उन्हें यह समझने में मदद करें कि उनसे क्या उम्मीद की जाती है (हालांकि मुझे लगता है कि अग्रणी प्रोग्रामर अक्सर ऐसी गतिविधि में आते हैं)।
• तृतीय-पक्ष परियोजनाएं प्रबंधित करें (मेरे काम में यह उस परियोजना का नेतृत्व करने वाले किसी भी इंजीनियर का काम है)।
• एक उत्पाद प्रबंधक बनें।
• स्प्रिंट प्रबंधन स्प्रिंट प्रत्येक साप्ताहिक / साप्ताहिक बैठकों के लिए काम के चरणों का निर्धारण / निर्धारण करता है।

यह स्पष्ट रूप से सीमाओं को निर्धारित करने के लिए उपयोगी है।

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

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

• मैं मेरे लिए लंबे समय तक फिट रह सकता हूं।
• मैं ऐसा करना चाहता हूं / जो आम तौर पर सुखद और मेरे व्यक्तिगत लक्ष्यों के अनुरूप हो।
• टीम / संगठन के लिए।

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

आप जो काम नहीं कर सकते / नहीं करना चाहते, उसके लिए समझौता न करें

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

इसलिए, मैं छोटे-छोटे काम करूंगा, जिन्हें बस करने की जरूरत है, लेकिन यह कहना महत्वपूर्ण नहीं है: "ओह, बेशक, मैं अपना ज्यादातर समय इस बात पर खर्च करूंगा कि मैं क्या करता हूं और मुझे क्या पसंद है, कोई समस्या नहीं है" :)। और अगर "किसी को" ऐसा करने की आवश्यकता है, तो शायद इसका मतलब है कि हमें अंतराल को भरने के लिए किसी को किराए पर लेने / प्रशिक्षित करने की आवश्यकता है। :)

मुझे अभी भी बहुत कुछ सीखना है!

हालांकि मुझे लगता है कि मैं समझने लगा हूं कि एक "लीड इंजीनियर" क्या है (मेरे करियर में पहले से ही 7 साल), लेकिन मुझे अभी भी लगता है कि मुझे इस बारे में बहुत कुछ सीखने की जरूरत है, और मुझे यह सुनने में दिलचस्पी होगी कि अन्य लोग सीमाओं को कैसे परिभाषित करते हैं। आपका काम!