एक विकास दल की संरचना कैसे करें

Question

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

एक एकल प्रबंधक वाली पूरी टीम बहुत अच्छी तरह से पैमाने पर नहीं साबित होने लगी है। मैं बहुत ही बारीकी से फैलाना शुरू कर रहा हूं इसलिए अपनी प्रत्यक्ष रिपोर्ट की संख्या कम करना चाहता हूं। सभी तरीकों से मैं ऐसा करने के लिए सोच सकता हूँ महत्वपूर्ण चढ़ाव हैं:

• वरिष्ठों को जूनियर डेवलपर्स की रिपोर्ट दें। यह सर्वश्रेष्ठ तकनीशियनों द्वारा विकास पर खर्च किए गए समय को कम करता है।
• सॉफ्टवेयर उत्पाद द्वारा टीम को विभाजित करें, जैसे डेवलपर्स इंट्रानेट पर 1-6 काम करते हैं और बाहरी साइटों पर 7-11 काम करते हैं, प्रत्येक अनुभाग में नई टीम लीड होती है (संभवतः वर्तमान वरिष्ठ डेवलपर्स की तुलना में अधिक प्रबंधन / सलाह / कोचिंग जिम्मेदारी के साथ एक नया नौकरी विवरण) )। यह कृत्रिम सिलोस जोड़ता है और अगर मैं उन्हें चाहता हूं तो एक बाहरी वेबसाइट पर काम करने के लिए "इंट्रानेट डेवलपर" प्राप्त करना मुश्किल हो सकता है।
• दबाव को दूर करने के लिए संरचना को सपाट रखें और प्रोजेक्ट प्रबंधकों / टीम प्रशासकों के आकार में प्रबंधकीय समर्थन जोड़ें। यह समस्या को हल नहीं करता है क्योंकि टीम हमेशा के लिए इस तरह से आगे नहीं बढ़ सकती है।

क्या इस समस्या को हल करने का एक मानक तरीका है जो मुझे याद आ रहा है?

यदि नहीं, तो आप में से अन्य लोगों ने इस समस्या को कैसे हल किया है?

Comments

अब आप अपनी रिपोर्ट के साथ कैसे बातचीत करते हैं? क्या यह तकनीकी, प्रशासनिक, या एक मिश्रण है? यदि एक मिश्रण, आपके समय का कितना प्रतिशत प्रत्येक पर खर्च किया जाता है?

— तेलेस्टिन

प्रशासनिक और तकनीकी का 50/50 मिश्रण।

— निक

क्या यह प्रोग्रामिंग के लिए विशिष्ट है? मुझे आश्चर्य है कि अगर इस सवाल को वर्कप्लेस पर बेहतर जवाब मिल सकता है।

— डेन्थ

Answer 1

कुछ त्वरित विचार:

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

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

Comments

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

— HLGEM

@HLGEM - बिल्कुल, लेकिन उस के कारण है कि आप के आसपास चक्र लोगों की जरूरत है .... है लोग हर तरह से अपने स्वयं के उत्पादों पर लाइव समर्थन करते हैं, लेकिन नहीं एक ही समय में वे संस्करण 3.0 विकसित कर रहे हैं के रूप में। इसके अलावा, आपके पास संभवतः एक या दो ऑप्स हैं जो डेवलपर्स और विभिन्न कार्यों को करने के लिए नहीं हैं, इसलिए यह ऑप्स के लिए एक अलग टीम संरचना / काम करने के मॉडल के लिए समझ में आ सकता है। YMMV बेशक।

— मिकेरा

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

— HLGEM

Answer 2

वह संरचना मुख्य रूप से होगी depend on project specifications

आदर्श रूप से, एक टीम में वरिष्ठ डेवलपर प्रति 3 जूनियर्स होना चाहिए। नतीजतन, एक शिक्षण नेतृत्व प्रति 2-3 वरिष्ठ डेवलपर्स हैं।

इस प्रकार, केवल टेक लीड परियोजना की प्रगति की स्थिति पर पीएम को रिपोर्ट करेंगे। वर्णित संरचना अभी भी मानती है कि एक गैर-तकनीकी मुद्दों (छुट्टी, समय-बंद, संघर्ष, आदि) के लिए सभी को पीएम तक पहुंच हो सकती है।

में से एक अपेक्षाकृत सफल सॉफ्टवेयर विकास टीमों मैं कुछ इस तरह, एक प्रति परियोजना के आधार पर चला गया का एक हिस्सा था:

एक सॉफ्टवेयर डेवलपमेंट मैनेजर / सीनियर डेवलपर / मेंटर, जिसे बाकी सभी ने सीधे रिपोर्ट किया हो।

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

यह पूरी तरह से ठीक काम किया, और मुझे वह संगठन बहुत पसंद आया। दूसरी ओर, मैं सॉफ्टवेयर डेवलपमेंट मैनेजर था, और टीम का संगठन ढांचा विकसित हो रहा था।

Answer 3

कार्यात्मक कर्मचारी संगठन पैटर्न पर विचार करें । यह सॉफ्टवेयर उत्पाद द्वारा टीम को विभाजित करने के आपके दूसरे विकल्प की ओर इशारा करेगा।

आपके संदर्भ में लेख को उद्धृत करने के लिए:

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

वास्तविक प्रबंधन / मानव संसाधन संरचना अप्रासंगिक है।

Answer 4

क्या इस समस्या को हल करने का एक मानक तरीका है जो मुझे याद आ रहा है?

ज़रुरी नहीं। यह आपकी टीम पर निर्भर करेगा, आप, आपको क्या करने की आवश्यकता है, और कंपनी आपको कौन से संसाधन उपलब्ध कराएगी।

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

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

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

एक और काम मैंने देखा है कि इंजीनियरिंग मैनेजर प्रशासनिक व्यक्ति होना चाहिए, और फिर टीम लीड (एस) तकनीकी व्यक्ति के रूप में कार्य करता है। यह पेचीदा मामला है, और सही लोगों के लिए (ज्यादातर) साथियों के रूप में कार्य करने की आवश्यकता होती है, भले ही रिपोर्टिंग पदानुक्रमित हो।

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