नए कोड के साथ नई टीम को प्रबंधित करने के लिए टिप्स / ट्रिक्स [बंद]

Question

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

प्रबंधन पूरी टीम की उच्च उत्पादकता पर जोर देता है, और वरिष्ठ डेवलपर के रूप में आप जिम्मेदार हैं।

इस तरह की स्थिति में ट्रम्प बाहर आने के लिए कोई सुझाव? जाहिर है, पूरी टीम को सीखने के लिए समय चाहिए और टीम के नए को नहीं भूलना चाहिए। हालांकि, समय सीमा भी आगे बढ़ रही है ...

Comments

Pm.stackexchange.com पर होना चाहिए

— JBRWilkinson

@JBRWilkinson मैं असहमत हूं। यह एक तंग समय सीमा के साथ जूनियर डेवलपर्स का एक तकनीकी नेतृत्व होने के बारे में है। मैं इस बात से सहमत हूँ कि यह कनिष्ठ डेवलपर्स की परियोजना का प्रबंधन करने के तरीके के बारे में है, हालांकि एक तकनीकी नेतृत्व पीएम होने की तुलना में अलग है।

— maple_shaft

Answer 1

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

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

Comments

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

— दाऊद इब्न करीम

@ डेविड - आपने 5 घंटे कैसे काम किया (यह वास्तव में उपयोग करने के लिए एक बुरा आंकड़ा नहीं है, लेकिन हम इसे कैसे जानते हैं)? बस इस तरह की परियोजना का अनुमान लगाना एक बकवास शूट है और प्रबंधन को बताएं।

— मटनज़

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

— दाऊद इब्न करीम

यह खरीदने में मदद करता है यदि आप योजनाबद्ध समय को देखने से पहले टीम के सदस्यों को अपना अनुमान विकसित करने में मदद करते हैं और वे योजना से अधिक नहीं हैं। अन्य अनुमानों को देखने से पहले उनका अनुमान लगाने से भी अनुमान लगाने से बचना होगा।

— बिलथोर

@BillThor: निश्चित रूप से आप इसे अनुमान लगाने के लिए काम करने वाले आदमी को प्राप्त करते हैं, और शुरुआती बिंदु के रूप में उसके आंकड़े का उपयोग करते हैं। मैंने सिर्फ एक नौकरी का अनुमान लगाया है और कहा है "हमें हालांकि यह 1/3 होगा।" वे मुझे पूछने से भी क्यों कतराते थे अगर पता होता कि इसमें कितना समय लगेगा?

— मटनज़

Answer 2

पहली चीजें पहले, कोड की पहली पंक्ति से एक स्रोत कोड नियंत्रण प्रणाली का उपयोग करना शुरू करें । कोड को जल्दी और अक्सर चेक करने की आदत डालें।

दूसरा, परीक्षण रणनीति पर निर्णय लें । बेशक इसका मतलब इकाई परीक्षण होना चाहिए, लेकिन आपको यह भी विचार करना चाहिए कि स्वीकृति परीक्षणों को कैसे स्वचालित किया जाए।

तीसरा, एक निरंतर एकीकरण सर्वर स्थापित करें ताकि आपका कोड नियमित रूप से बनाया और नियमित रूप से परीक्षण किया जाए।

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

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

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

Comments

संस्करण नियंत्रण और कोड की समीक्षा के लिए +1 जल्दी और अक्सर।

— jmq

मेरी राय है कि स्रोत नियंत्रण इतनी आवश्यक प्रक्रिया है कि इसे टीम मेकअप की परवाह किए बिना किया जाना चाहिए।

— maple_shaft

Answer 3

@Chrisaycock द्वारा इसके अतिरिक्त उत्तर के अलावा ... उस समय को कम न समझें जब आपको सलाह / प्रशिक्षण आदि के लिए आवंटित करने की आवश्यकता होगी। प्रमुख के रूप में, आपको विस्तार से जाने और अपनी टीम पर विश्वास करने की आवश्यकता होगी। आपका काम प्रबोधक, रोड ब्लॉक रिमूवर बनना है, और व्यवधान चलाएं जब प्रबंधन वहां आ जाता है। एक "सामान्य" टीम में, लगभग 7 या 8 पर, लीड नहीं रह गया कार्यक्रम, आपकी स्थिति में, यह 3 या हो जाता है। 4 (शायद कम भी), आप परियोजना के लिए एक प्रोग्रामिंग संसाधन नहीं हैं।

Comments

सलाह और प्रशिक्षण के लिए समय आवंटित करने पर +1। एक प्रभावी टेक लीड जूनियर डेवलपर्स को उत्पादक बनाता है।

— maple_shaft

"आप प्रोजेक्ट के लिए प्रोग्रामिंग संसाधन नहीं हैं"। मुझे आश्चर्य है कि अगर उनके प्रबंधन को उसी तरह लगता है, हेह। मुझे उम्मीद है कि आप इस परियोजना के लिए "हीरो" प्रोग्रामर के रूप में समाप्त नहीं होंगे।

— jmq

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

— TMN

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

— मटनज़

Answer 4

दो क्षेत्रों में संचार पर ध्यान दें।

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

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

Answer 5

मैंने जो कुछ किया है वह सक्षम लोगों की पहचान करें और विभाजित करें और जीतें। मैं शीर्ष 2 या 3 लेता हूं और उन्हें कप्तान बनाता हूं। दूसरों को तो अपनी छोटी टीमों के कप्तानों के बाद समान रूप से टीमों में विभाजित किया जाता है।

मैं एक कार्यक्रम करने के लिए कप्तानों को विखंडू या मॉड्यूल देता हूं।

कप्तान खुद को समझाते हुए न्यूबीट्स को छोटे प्रोग्रामिंग या अनुसंधान कार्यों को देते हैं जो वे ऐसा कर रहे होते हैं।

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

यह अब तक लगभग 10-20 प्रोग्रामर के लिए अच्छा काम करता है। छोटे समूह सिर्फ एक समूह में बेहतर होते हैं और मैंने अभी तक कुछ भी बड़ा काम नहीं किया है।

Comments

फूट डालो और जीतो के अपने नुकसान हैं। मैंने इस छोर को हर उपसमूह के रूप में देखा है, जो पूरी टीम का सामना करने वाली समान समस्याओं के लिए पहिया (बुरी तरह से) का आविष्कार कर रहा है।

— NWS

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

— जेसन सेब्रिंग