नमस्ते! मुझे लगता है कि प्रत्येक डेवलपर जो टीम लीडर की भूमिका में बदलाव करता है, शुरू में टीम के साथ कोडिंग और कार्यों को हल करने का प्रयास करता है। बाद में, हम अधिक व्यावसायिक कार्यों और मुद्दों को शामिल करना शुरू करते हैं, व्यवसाय से संबंधित चुनौतियों, विभागों या ग्राहकों के बीच संचार और वास्तुकला में गोता लगाते हैं। इस बिंदु से, हमारे पास कुछ और करने का न तो समय है और न ही इच्छा। एक सामान्य टीम लीड का कैलेंडर इस प्रकार प्रारंभ होता है: मैं विकास की ओर कैसे लौटूँ और फिर से कोडिंग कैसे शुरू करूँ? मुझे कहाँ से शुरू करना चाहिए? यह आकलन करना भी महत्वपूर्ण है कि आप वास्तव में कितने व्यस्त हैं और आपका सामान्य कार्यदिवस कैसा दिखता है। क्या आप काम के बाद आत्म-सुधार में संलग्न होते हैं या नहीं? ये सभी महत्वपूर्ण कारक हैं. अपने अनुभव के आधार पर, मैं "काम से पहले या बाद में कोई समय नहीं, कोई इच्छा या अवसर नहीं" से "मैं हमेशा कंप्यूटर पर रहता हूं, और यह मेरा जुनून है" की राह पर कदम उठाने का सुझाव देता हूं। अपना समय रोकें! एक प्रभावी प्रारंभिक बिंदु विकास के लिए समर्पित समय निर्धारित करना है। बस अपने कैलेंडर में 'कोडिंग समय' को एक घंटे या उससे अधिक के लिए ब्लॉक कर दें। यदि संभव हो, तो विशेष रूप से तकनीकी कार्यों से निपटने के लिए प्रत्येक सप्ताह आधा दिन या एक पूरा दिन आरक्षित करने पर विचार करें। हाँ, इसमें बैठकों को इधर-उधर ले जाना, अनावश्यक बैठकों को ख़त्म करना, या उनमें से कुछ में भाग लेने की आवश्यकता पर चर्चा करना शामिल हो सकता है। हालाँकि, इस बात का पुनर्मूल्यांकन करने पर विचार करें कि क्या कुछ ग्रूमिंग सत्र अभी भी आपके लिए प्रासंगिक हैं। शायद आप बिना किसी विशेष प्रभाव के वहां एक घंटा बिता रहे हैं? उस समय को कोडिंग की ओर पुनर्निर्देशित करें! अपनी टीम के साथ कोड की समीक्षा करें! अपने आस-पास की कुछ प्रक्रियाओं को अनुकूलित करने के लिए दूसरा और सबसे महत्वपूर्ण पहलू अपने सहकर्मियों को परियोजना के मूल्यों या दृष्टिकोणों के बारे में बताना है। प्रत्येक डेवलपर समस्या-समाधान के लिए एक ही दृष्टिकोण नहीं देखता है, इसलिए कोडिंग शैलियों, परीक्षण कवरेज, और प्लेटफ़ॉर्म या सेवाओं के मूलभूत तरीकों और यांत्रिकी को अलग से पूर्वनिर्धारित करना आवश्यक है। हमेशा कोड की समीक्षा करें, और यदि ऐसा लगे कि कोई प्रश्न लंबा खिंच रहा है, तो पुल अनुरोधों (पीआर) में समस्याओं का तेजी से समाधान करने के लिए टीम को इकट्ठा करें। जैसा कि अभ्यास से पता चलता है, यह दृष्टिकोण समस्या समाधान समय को तेज करता है, जिसके परिणामस्वरूप सुविधाओं के विपणन के समय में सुधार होता है। समय के साथ, आपकी टीम उन विकास दृष्टिकोणों को पूरी तरह से समझेगी और लागू करेगी जिन पर कम ध्यान देने की आवश्यकता है। आपका ध्यान केवल मौजूदा कार्य और उसके तर्क को हल करने पर होगा, जिससे शुरुआत में कुछ मिनट और लंबे समय में विकास के संभावित घंटों की बचत होगी। आप किसके लिए जिम्मेदार हैं? यह शायद सबसे स्पष्ट कार्य न लगे, लेकिन अपने आप से पूछें कि आप किसके लिए ज़िम्मेदार हैं? आपको क्या करने की ज़रुरत है? इन सभी बिंदुओं को एक कागज़ पर लिख लें और देखें कि कहीं आपने कोई अनावश्यक चीज़ तो नहीं ले ली है। शायद आप किसी और का काम सिर्फ इसलिए कर रहे हैं क्योंकि यह उसकी आदत बन गई है। हो सकता है कि आप किसी पड़ोसी टीम को उनकी प्रक्रियाओं में मदद कर रहे हों, और आप अभी भी इसमें शामिल हों। अपनी स्थिति और प्रोजेक्ट या कंपनी में आप क्या योगदान देते हैं, इसे स्पष्ट रूप से परिभाषित करें। यदि आप एक बड़ी टीम का नेतृत्व करते हैं, तो नोट्स का उपयोग करें जहां आप कार्यों और मुद्दों की एक कतार बना सकते हैं। उदाहरण के लिए, हमेशा समीक्षाएं करें और सुनिश्चित करें कि यदि आप DevOps लीड हैं, तो आप अनजाने में मोबाइल ऐप डेवलपर्स के लिए निर्धारित कार्यों को नहीं संभाल रहे हैं। यदि आप अपने आप को कार्यों और निर्भरताओं से भरा हुआ पाते हैं, तो अपने वरिष्ठों से बात करना और यह पता लगाना उचित है कि आपके विभाग में ऐसा क्यों हो रहा है। उदाहरण के लिए, यदि आप डेटा इंजीनियरों के लिए ज़िम्मेदार DevOps टीम हैं, और उनके पास अपना स्वयं का नेतृत्व है, तो आपके विभाग के बजाय ज़िम्मेदारियों को वापस उनके नेतृत्व में सौंपना समझदारी हो सकती है। समझौतों को औपचारिक रूप देने या सेटअप या रखरखाव के बारे में किसी छिपे हुए विवरण के लिए विनिर्देश और आवश्यक दस्तावेज़ बनाएं और लोगों को उनकी संबंधित टीमों में लौटाएं। यह ध्यान रखना आवश्यक है कि यह केवल एक उदाहरण है, और हर किसी की अपनी टीमें और उनके गठन के सिद्धांत हैं। प्राथमिकता और प्रत्यायोजन यह संभव है कि आप काम नहीं कर पा रहे हों क्योंकि प्राथमिकताएँ बदलती रहती हैं। पूरी कंपनी दो-सप्ताह के स्प्रिंट पर काम करती है, लेकिन यह सेटअप अब आपके लिए उपयुक्त नहीं है, और आपको इसमें कोई मूल्य नहीं दिखता है। कमजोर प्राथमिकताओं के कारण सुविधाएँ इसे स्प्रिंट के भीतर पूरा नहीं कर पा रही हैं। यह सेवा-उन्मुख टीमों के लिए प्रासंगिक है। कानबन या जलप्रवाह दृष्टिकोण की खोज पर विचार करें। हमारी टीमें अलग-अलग द्वीपों की तरह हैं जहां हमें बेहतरी के लिए प्रक्रियाओं को बदलने का प्रयास करने का अधिकार है। एक महीने के लिए नए दृष्टिकोण में बदलाव का परीक्षण करें और अपने मेट्रिक्स का निरीक्षण करें। मेरे अनुभव में, कुछ हफ़्ते यह नोटिस करने के लिए पर्याप्त थे कि स्क्रम हमारे लिए उपयुक्त नहीं था, और हमने कानबन पर स्विच किया। बाज़ार में जाने का हमारा समय बहुत कम हो गया क्योंकि प्राथमिकताएँ अब सप्ताह में दो बार बदल सकती हैं, जिससे हम मुद्दों को अधिक तत्परता से संबोधित कर सकते हैं। इसके बाद, टीम को डोमेन ज़ोन में विभाजित करने का प्रयास करें, लेकिन बहुत अधिक विस्तृत रूप से नहीं। 70/30 नियम का पालन करते हुए प्रत्येक टीम के सदस्य को विसर्जित करें: 70% अपने मुख्य स्टैक, प्रोजेक्ट या उत्पाद के लिए समर्पित हैं बाकी सभी चीज़ों के लिए 30% यदि आपकी टीम में 5 से अधिक लोग हैं, तो आप सभी सेवाओं और कार्यों को कवर करेंगे, जिससे व्यक्तियों को विषय क्षेत्र में तेजी से गोता लगाने की अनुमति मिलेगी। इससे क्या हासिल होता है? यदि आप देखते हैं कि डेवलपर के पास पहले से ही अच्छी समझ और तल्लीनता है तो यह आपको स्वयं सब कुछ करने के बजाय टीम को कुछ कार्य सौंपने की अनुमति देता है। आपको संपूर्ण एल्गोरिदम और एकीकरणों का वर्णन करने की आवश्यकता नहीं है! वे यह सब पहले से ही जानते हैं! समय प्रबंधन और उत्पादकता टीम अपने कार्य समय की योजना कैसे बना रही है? आइए कुछ सरल से शुरुआत करें: आप एक टीम के रूप में कैसे काम करते हैं? अपने अनुमानों और आप कार्यों का आकलन कैसे करते हैं, इस पर एक नज़र डालें। क्या सब कुछ क्रम में है? शायद इसमें सुधार या कार्यभार गुणांक लागू करने की गुंजाइश है? कार्यभार गुणांक यह समझने में मदद करता है कि समर्थन के लिए संभावित विकर्षणों को ध्यान में रखते हुए, प्रत्येक टीम के सदस्य को स्प्रिंट या सप्ताह के दौरान कैसे लोड किया जाता है। उदाहरण के लिए, यदि आप एक सेवा दल हैं जिसके पास रखरखाव के लिए अपना स्वयं का उत्पाद है, तो अन्य टीमें आपकी सहायता ले सकती हैं या संवर्द्धन का अनुरोध कर सकती हैं, जिससे स्प्रिंट के भीतर संचार पर समय व्यतीत हो सकता है। यही बात बग से निपटने के लिए भी लागू होती है; उत्पादन परिवेश में जरूरी मुद्दों को सुलझाने में आपको बार-बार भटकना पड़ सकता है। लेकिन यह एक अलग विषय है, और मैं इस क्षेत्र में क्रमिक सुधार कैसे करें, इस पर अपने पिछले लेख को देखने की सलाह दूंगा। https://hackernoon.com/just-go-ahead-and-test-your-project-part-1?embedable=true अब, गुणांक पर वापस जाएँ। यदि हम स्वीकार करते हैं कि हममें से प्रत्येक को किसी मुद्दे को हल करने के लिए 5 में से कम से कम 1 दिन चैट या मीटिंग में बुलाया जाता है, तो योजना बनाते समय इसे ध्यान में रखें। इस तरह, आप वास्तविक रूप से उन कार्यों को पूरा करने में सक्षम होंगे जो वास्तव में टीम को लाभान्वित करते हैं, संभावित रूप से कोड लिखने के लिए समय बचाते हैं। पोमोडोरो तकनीक आज़माएँ। कुछ भी अभूतपूर्व नहीं; बस अपने फ़ोन पर एक ऐप का उपयोग करें जो आपको 45 मिनट जैसे एक निर्धारित समय अंतराल के लिए किसी कार्य पर ध्यान केंद्रित करने की अनुमति देता है। मुझे लगता है, कुछ खास नहीं। ट्रैकर्स का उपयोग करें. इस बात की जाँच करें कि आप अपने 8 कामकाजी घंटे किस चीज़ पर बिताते हैं - सप्ताह या महीने के दौरान अपनी गतिविधियों के प्रत्येक घंटे और मिनट को रिकॉर्ड करें। आप ऐसे कारकों की खोज कर सकते हैं जो आपका ध्यान भटकाते हैं, या आप देख सकते हैं कि दोपहर के भोजन के बाद 15 मिनट की सैर आपको अधिक कुशलता से काम करने में मदद करती है - शायद यही सफलता की कुंजी है? या, यदि आपकी लगातार तीन बैठकें होती हैं, तो क्या आप उसके बाद एक घंटे तक कुछ नहीं करते, केवल विनिर्देश पढ़ते हुए पाते हैं? शायद यह आपके लिए चुनौतीपूर्ण है? मुद्दा यह है कि आप जो कर रहे हैं उसकी जांच करें और मेरा मानना है कि आप सुधार के क्षेत्रों की पहचान करेंगे। तकनीकी रूप से चुनौतीपूर्ण परियोजनाओं में भागीदारी यदि आप स्वयं को सिस्टम डिज़ाइन या वास्तुशिल्प समाधानों के लिए समर्पित बैठकों में भाग लेने में असमर्थ पाते हैं, तो अनुवर्ती कार्रवाई या दस्तावेज़ पढ़ें। यह समझने का प्रयास करें कि समस्या कैसे और क्या हल करती है। बेहतर होगा कि ऐसी बैठकों को न छोड़ा जाए और जितना संभव हो सके तकनीकी पहलुओं में खुद को डुबोने का प्रयास किया जाए। उन परियोजनाओं या परियोजना पहलुओं का चयन करें जिनके लिए कोड में गहराई से गोता लगाने की आवश्यकता है। इससे आपको नई प्रौद्योगिकियों और विकास पद्धतियों से अवगत रहने में मदद मिलेगी। आपके लिए आरएनडी यदि आप प्रोजेक्ट में ऐसे क्षेत्रों को देखते हैं जिनमें समस्याएं हैं या जहां कार्यक्षमता में सुधार किया जा सकता है, तो बेझिझक प्रोटोटाइप बनाएं। यह न केवल आपको प्रस्तावित परिवर्तनों की कल्पना करने की अनुमति देगा बल्कि टीम को चर्चा और निर्णय लेने के लिए ठोस सामग्री भी प्रदान करेगा। मुख्य लक्ष्य केवल विचारों को प्रदर्शित करना नहीं है बल्कि यदि वे वास्तव में महत्वपूर्ण या लाभकारी साबित होते हैं तो उन्हें परियोजना में लागू करना है। उदाहरण के लिए, यदि आपने हमेशा पुरानी सेवाओं को जावा 1.8 से संस्करण 21 में स्थानांतरित करने का सपना देखा है, तो इसे आज़माएं क्यों नहीं? एक प्रोटोटाइप बनाएं, इसे टीम को दिखाएं, अपना समाधान विकसित करें और भविष्य में संदर्भ के लिए पूरी प्रक्रिया का अच्छी तरह से दस्तावेजीकरण करें। यह दृष्टिकोण न केवल तकनीकी सुधारों को लागू करने में मदद करता है बल्कि संभावित परिवर्तनों के संबंध में टीम के भीतर एक साझा समझ बनाने में भी मदद करता है। इस प्रकार, आप परियोजना में रचनात्मक योगदान दे सकते हैं, इसके प्रभावी विकास को सुनिश्चित कर सकते हैं और नवाचार को बढ़ावा दे सकते हैं। समीक्षा बिंदु! , आपके पास कोड लिखने, समाधान प्रस्तावित करने के लिए कुछ घंटे होंगे और फिर आप राहत की सांस ले सकते हैं। बेशक, नेतृत्व की स्थिति आपको दोनों करने की अनुमति नहीं देगी, और यदि आपका ध्यान अभी भी विकास पर है, तो वापसी पर विचार करना उचित हो सकता है। इस स्तर पर इसमें कुछ भी गलत नहीं है - यह महसूस करना कि प्रबंधन आपके लिए सुस्त होता जा रहा है, भले ही आप इसमें उत्कृष्टता प्राप्त करें, ठीक है। बात बस इतनी है कि, इस समय, इसने आपके लिए अपना आकर्षण खो दिया है। यदि आपके पास अभी भी कुछ खाली समय है सीखना और आत्म-विकास तकनीकी साहित्य पढ़कर, शैक्षिक पाठ्यक्रमों की खोज करके और तकनीकी सम्मेलनों में भाग लेकर स्वयं को लगातार शिक्षित करें। इससे आपको सॉफ़्टवेयर विकास में नवीनतम रुझानों और सर्वोत्तम प्रथाओं से अवगत रहने में मदद मिलेगी। तकनीकी साहित्य पढ़ने से नई प्रौद्योगिकियों, पद्धतियों और सर्वोत्तम प्रथाओं की गहराई में जाने का एक अनूठा अवसर मिलता है। इसमें सॉफ्टवेयर विकास के विभिन्न पहलुओं को कवर करने वाली किताबें, लेख, ब्लॉग और अन्य सामग्रियां शामिल हो सकती हैं। शैक्षिक पाठ्यक्रम लेना नए विषयों और प्रौद्योगिकियों पर ज्ञान प्राप्त करने का एक संरचित और व्यवस्थित तरीका है। ऑनलाइन पाठ्यक्रम प्लेटफ़ॉर्म विभिन्न प्रोग्रामिंग भाषाओं, रूपरेखाओं और अवधारणाओं पर पाठ्यक्रमों की एक विस्तृत श्रृंखला पेश करते हैं। तकनीकी सम्मेलनों में भाग लेने से न केवल नवीनतम रुझानों और नवाचारों के बारे में जानने का बल्कि उद्योग के पेशेवरों के साथ जुड़ने का भी अवसर मिलता है। सम्मेलन अनुभवों को साझा करने, चुनौतीपूर्ण मुद्दों पर चर्चा करने और तकनीकी समुदाय के भीतर संबंध बनाने के लिए एक मंच प्रदान करते हैं। संक्षेप में, पढ़ने, पाठ्यक्रम लेने और सम्मेलनों में भाग लेने के माध्यम से निरंतर सीखने से सॉफ्टवेयर डेवलपर्स को न केवल नवीनतम रुझानों के साथ बने रहने की अनुमति मिलती है, बल्कि अपने दैनिक कार्य में नए ज्ञान और कौशल को सक्रिय रूप से एकीकृत करने की भी अनुमति मिलती है। उदाहरण: लीटकोड, उडेमी, या यूट्यूब (कभी-कभी, हम वहां वास्तव में अच्छी मुफ़्त सामग्री पा सकते हैं!)। व्यक्तिगत परियोजनाओं पर काम करना यदि संभव हो तो अपने खाली समय में निजी परियोजनाओं पर काम करें। यह न केवल आपके प्रोग्रामिंग कौशल को बढ़ाएगा बल्कि आपके प्राथमिक कार्य के लिए नए विचारों के स्रोत के रूप में भी काम करेगा। इसके अतिरिक्त, इस गतिविधि को लेख के आरएनडी बिंदु के साथ जोड़ना रचनात्मकता और नवीनता के लिए एक अतिरिक्त प्रोत्साहन हो सकता है। व्यक्तिगत परियोजनाओं पर काम करने से आप अपने कौशल को व्यावहारिक परिदृश्यों में लागू कर सकते हैं, नई तकनीकों के साथ प्रयोग कर सकते हैं और वास्तविक दुनिया की समस्याओं को हल कर सकते हैं। इन परियोजनाओं में आपके स्वयं के वेब एप्लिकेशन विकसित करना, ओपन-सोर्स प्रोजेक्ट बनाना, या दिलचस्प साइड प्रोजेक्ट्स में भाग लेना शामिल हो सकता है। इस गतिविधि को पहले उल्लिखित अनुसंधान और विकास (आरएनडी) कार्य के साथ एकीकृत करने से आप प्रोटोटाइप बनाने और उन्हें अपने कार्यस्थल पर प्रदर्शित करने में सक्षम हो सकते हैं। अपने प्रोजेक्ट को जनता के लिए खोलना, जैसे कि ओपन-सोर्स डेवलपमेंट में भाग लेना, न केवल आपके कौशल में सुधार करता है बल्कि मूल्यवान पेशेवर कनेक्शन बनाने और आपकी रचनात्मकता के लिए मान्यता प्राप्त करने में भी योगदान देता है। हालाँकि, यह याद रखना महत्वपूर्ण है कि आपके मुख्य कार्य की गोपनीयता नीति (एनडीए) का पालन करना एक प्राथमिकता है। व्यक्तिगत परियोजनाओं को शुरू करने से पहले, कानूनी पेशेवरों और प्रबंधन से परामर्श करने की सलाह दी जाती है ताकि यह सुनिश्चित किया जा सके कि आपकी रचनात्मक प्रक्रिया स्थापित नियमों का उल्लंघन नहीं करती है और संवेदनशील डेटा की गोपनीयता को बनाए रखते हुए आपकी रचनात्मक ऊर्जा के मुक्त विकास की सुविधा प्रदान करती है। निष्कर्ष एक टीम लीडर के रूप में कोडिंग के लिए समय निकालने के लिए सचेत प्रयास और प्रभावी प्राथमिकता प्रबंधन की आवश्यकता होती है। याद रखें कि आपकी भूमिका में न केवल सीधे टीम का नेतृत्व करना शामिल है बल्कि अपने तकनीकी कौशल को संतोषजनक स्तर पर बनाए रखना भी शामिल है। यह चुनौतीपूर्ण होगा, और मैं आपको शुभकामनाएँ देता हूँ! मैंने समस्या बहुत समय पहले देखी थी। यदि आप पेशेवर किताबें पढ़ना चाहते हैं, तो मैं आपको किताबें पढ़ने की सलाह दूंगा: और लिंक लिंक
