🎢 📢 👩🏼‍🤝‍👨🏿 डेवलपर से लेकर प्रबंधक और इसके विपरीत 🤶🏾 ✌🏻 ♂️

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

आइए आपको बताते हैं कि यह दूसरी तरफ कैसे था, क्यों मैं 30+ (स्पॉइलर) की उम्र में डेवलपर्स के पास लौट आया और इसे पछतावा नहीं था।

Android डेवलपर्स के लिए रास्ता

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

हमारे मनी कीपर में एक आदिम डिजाइन था, लेकिन एक अच्छी तरह से सोचा UX: आय या व्यय एक क्लिक में दर्ज किया गया था - श्रेणी आइकन पर टैप करें तुरंत राशि दर्ज करने के लिए एक विंडो खोली।

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

छोटे से छोटे, प्रति दिन कई दर्जन डाउनलोड, दर्शक बढ़े, रेटिंग बढ़ी, पहली सकारात्मक समीक्षा दिखाई दी। यह कहना कि यह प्रेरित करने वाला था। मैंने बाजार में समीक्षाओं का जवाब दिया, उपयोगकर्ताओं की इच्छाओं के आधार पर आगे के विकास की योजना बनाई, बस इसलिए कि मेरे आवेदन को उपयोगकर्ताओं द्वारा आवश्यक है, वे धन्यवाद देते हैं और पत्नियां डालते हैं। और हमारे सभी विज्ञापन w3bsit3-dns.com पर एक ही पोस्ट में थे।

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

मैं एक टीम लीडर कैसे बन गया, "क्योंकि_तो_सो_सोमोन_समर्थन_किसी कारण_"

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

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

मैं मुश्किल कामों से डरने वाला नहीं था)

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

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

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

एक टायलिडा के रूप में मेरे सिद्धांत

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

जो हैं, उनके साथ काम करने की जरूरत है

जलती हुई आँखों वाला छात्र, जिसे कुछ समय के बाद सही रास्ते पर भेजा जा रहा है, परियोजना के लिए "सुपर स्टार" की तुलना में अधिक लाभ लाना शुरू कर सकता है।

एक परियोजना में, मैंने फैसला किया कि यह परिचित MVP + डैगर + RxJava बंडल से दूर जाने का समय था, और उन उपकरणों का उत्पादन करने का प्रयास करें जिन्हें Google आधुनिक मोबाइल एप्लिकेशन बनाने के लिए उपयोग करने की अनुशंसा करता है। हमने केवल कोरपेकिन के साथ जेटपैक और कोटलिन का उपयोग करके अनुशंसित वास्तुकला को लागू करने की योजना बनाई ।

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

हां, निश्चित रूप से, हमने शुरुआत में पुस्तकालयों के अल्फा संस्करणों के बचपन के रोगों का एक गुच्छा पकड़ा ...

लेकिन दोस्तों ने कड़ी मेहनत की, स्रोत में चढ़ गए और गितुब पर मुद्दों का अध्ययन किया, रात में profiled, और अंत में हमें मिला:

साफ, स्थिर और आसान कोड बनाए रखने के लिए,
उत्पादन में सफल उत्पाद,
और अमूल्य अनुभव का एक गुच्छा।

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

आपको "रॉक सितारों" के साथ काम करना होगा, चाहे वह कभी-कभी कितना मुश्किल हो।

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

मैं अधीनस्थों के साथ नहीं, बल्कि लोगों के साथ काम करता हूं

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

काम की घंटों के दौरान छुट्टियों से पहले कौन अन्य साइटों पर नहीं बैठा, पहले मुझ पर निगरानी रखने दें)

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

एक कठिन परिस्थिति में, जब तक मैं आगे नहीं बढ़ूंगा, कोई भी आगे नहीं बढ़ेगा

मेरे लिए एक नई DevOps टीम में, मैं सीआई की तैनाती के साथ कुछ महीनों के लिए "गतिशील" रहा, और डेवलपर्स ने खुले तौर पर इसके कार्यान्वयन के लिए तोड़फोड़ की, इसकी उपयोगिता के तर्कों से सहमत नहीं। ऐसा नहीं है कि वे आलसी प्रतिगामी थे, यह सिर्फ मुझे लग रहा था कि वे उस वातावरण में काम नहीं करते जहां सीआई को सही तरीके से तैयार किया गया था।

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

क्या मैं व्यक्तिगत हस्तक्षेप और सूक्ष्म प्रबंधन के साथ प्रक्रियाओं के संगठन में छेद बंद कर देता हूं? शायद। लेकिन, ऐसा लगता है कि इस तरह की गतिरोध की स्थिति में, दो चरम सीमाएं हैं: "शिकंजा कसना", अधिक से अधिक टीम से दूर जाना और "बॉस" बनना, या किसी व्यक्ति की मदद करने की कोशिश करना जब उसके लिए मुश्किल हो, यहां तक कि उसके काम को पूरा करना, "उसका" बनना। लेकिन वे मुसीबत में "अपने ही" को नहीं छोड़ते।

आपको टीम में खुद को विकसित करने और सभी को विकसित करने की आवश्यकता है

एक नेता का विशिष्ट कार्यस्थल।

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

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

और व्यवसाय के लिए एक ऐसे व्यक्ति के लिए वेतन वृद्धि को सही ठहराना आसान है जो पूरी कंपनी के लिए कुछ नया और उपयोगी पेश कर रहा है।

कोई विकास की समस्याओं से दूर नहीं जा सकता

जैसे ही आप अब तकनीकी ऋण, प्लेटफ़ॉर्म सुविधाओं और सिस्टम के विभिन्न हिस्सों के बीच बातचीत के साथ डेवलपर्स की समस्याओं को नहीं समझते हैं, स्प्रिंट का प्रतिशत नीचे उड़ रहा है।

ऐसे मामले थे जब प्रबंधक वास्तव में आश्चर्यचकित थे कि नए साल की पूर्व संध्या पर एक iOS एप्लिकेशन को प्रकाशित करना असंभव था क्योंकि Apple के समीक्षक कुछ छुट्टियों पर गए थे। डिजाइनर कभी-कभी विभिन्न स्क्रीन पर टाइपसेटिंग के साथ एंड्रॉइड डेवलपर्स की समस्याओं को नहीं समझते हैं। वे बैकेंड जिन्होंने मोबाइल क्लाइंट के साथ काम नहीं किया है, उन्हें स्पष्ट करना चाहिए कि उन्हें JSON के बजाय HTML पेज की त्रुटि देने की आवश्यकता नहीं है।

और अगर सिस्टम या उसके हिस्से के विकास के दौरान आप ऐसे क्षणों के माध्यम से "देखो", समय सीमा के लिए परिणाम बहुत ही निराशाजनक हो सकता है।

ओह, तकनीकी समाधानों को अपनाकर ही कितना अच्छा मुकाम हासिल किया जा सकता है। और यहां तक कि अगर वे वितरित करने के लिए कार्य देते हैं - तो आप पहाड़ों को रोल कर सकते हैं!

क्या मैंने नेतृत्व करने का प्रबंधन किया?

मैं यह नहीं कहना चाहता कि ये सही सिद्धांत हैं। मुझे यह भी पता नहीं है कि क्या वे कार्मिक प्रबंधन पर पुस्तकों में लिखते हैं, क्योंकि मैं उनमें से किसी को भी नहीं पढ़ता हूं। मैं कई तथ्यों से न्याय करता हूं:

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

ठीक है, नेतृत्व के पतन के बारे में क्या?

मेरे लिए वे हैं:

जितना अधिक आप एक प्रबंधक हैं, उतना ही कम डेवलपर। कोई फर्क नहीं पड़ता कि आप परियोजना के तकनीकी हिस्से की पेचीदगियों पर नज़र रखने की कोशिश कैसे करते हैं, वे आपको हर दिन आगे और आगे बढ़ाते हैं। और टीम जितनी बड़ी होगी और विकास उतना ही अधिक सक्रिय होगा। धीरे-धीरे, एंड्रॉइड और आईओएस के बारे में प्राप्त नई जानकारी की मात्रा ऑपरेटिंग सिस्टम के नए संस्करणों के रिलीज नोट्स और हर महीने हैबे पर लेखों के एक जोड़े को पढ़ने के लिए कम हो गई थी।
. — , . , “” . .
. . , . - - , .
. , . , 2-3 . - — 70-80% !

!

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

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

यह कुछ इस तरह देखा गया:

— ?

— .

— ?

— , . , .

— ?

— …

— , scrum kanban?

— .

— ?

— …

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

दूरदराज के कार्यकर्ताओं के लिए यह मेरी वर्तमान टीम है। इसमें कम से कम एक और व्यक्ति उसी तरह से गया: टीम के नेताओं के पास गया और जानबूझकर डेवलपर्स के पास लौट आया।

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

दूसरा तरीका- यदि संभव हो तो प्रबंधन के वर्षों में पकड़ में आने पर खुद को विकास में डुबोएं।

ठीक है, तीसरा, समझौता, विकल्प सिद्धांत को "खींचना" और "बीच में" बने रहने की कोशिश करना है, कुछ और वर्षों के लिए "एमेच्योर में लटका"।

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

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

इसलिए, मुझे काम करने के लिए एक सुखद स्थान मिला, मैं कोड लिखता हूं और अब तक मुझे कोई पछतावा नहीं है।
क्या 32 में डेवलपर्स में जीवन है? वहाँ है!

PS

मुझे एक नेतृत्व के अनुभव के रूप में डेवलपर ने क्या दिया है?

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

डेवलपर से लेकर प्रबंधक और इसके विपरीत