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

आर्किटेक्चर और कोड इम्परफेक्ट होंगे

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

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

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

स्वायत्तता एक पर्क है, लेकिन ओवरकमिटिंग नहीं है

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

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

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

कभी-कभी यह तय करना संघर्ष होता है कि कब कदम रखा जाए या पानी के ऊपर रहना चाहिए।

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

तकनीकी चुनौतियाँ एकमात्र समस्या होने से बहुत दूर हैं

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

लेखन कोड और शानदार समाधान बनाना लंबे समय से चल रहे क्रॉस-डिसिप्लिनरी प्रोजेक्ट की सफलता की कहानी का हिस्सा हैं।

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

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

अंतिम विचार

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

विनी हो अलबर्टा मोटर एसोसिएशन में एक वरिष्ठ सॉफ्टवेयर डेवलपर हैं, जिनके पास एडब्ल्यूएस और वेब के बारे में सीखने, पढ़ने और लिखने की अतुलनीय इच्छा है।