एक बड़ी प्रोग्रामिंग टीम में काम करना क्या पसंद है?

Question

मैंने हमेशा एक छोटी प्रोग्रामिंग टीम में काम करने के लिए भाग्यशाली महसूस किया है। मुझे लगता है कि मैंने सबसे अधिक 11 प्रोग्रामर के साथ काम किया है। यह सैकड़ों डेवलपर्स के साथ एक परियोजना पर काम करने जैसा क्या है? हजारों? क्या पैमाने और क्या नहीं करता है?

संपादित करें: सभी प्रतिक्रियाओं के लिए धन्यवाद! लगता है बहुत कम सकारात्मक:

• मेगा-बड़े कोडबेस पर काम करना संभव है
• बेहतर आंतरिक कैरियर विकास
• अपमानजनक प्रबंधन के खिलाफ कर्मचारी सुरक्षा (यह बड़े पर छोटे से + ve पर अधिक है)

क्या बड़ी टीमों को कोई अन्य लाभ है?

Comments

यह बेकार है। इससे किसी भी कीमत पर बचो।

— पॉल टॉम्बलिन

मुझे लगता है कि 11 एक बड़ी टीम होगी ... मैंने जो सबसे बड़ा काम किया है वह 3 था! :-)

— ब्रायन नोब्लुच

कुछ परिप्रेक्ष्य हासिल करने के लिए 'पौराणिक पुरुष महीने' पढ़ें ... यह मेरे लिए अपील नहीं है (हालांकि मैंने कभी 4 अन्य डेवलपर्स, प्लस 3 परीक्षकों और एक दोपहर के साथ काम किया है)। बड़ी टीमों को लगता है कि यह बैठक के बाद मिलने के बाद ही मिल रही है :(

— workmad3

मैं सहमत हूँ। 11 एक बड़ी टीम है। IMHO 3 सर्वश्रेष्ठ है।

— यहोशू भागयोगी

Answer 1

मुझे लगता है कि नौकरशाही के पैमाने बहुत अच्छे हैं।

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

सबसे बड़ी परियोजना जिस पर मैंने काम किया था, उसमें 5 अलग-अलग साइटों पर 70 या तो डेवेलपर्स थे। यहां तक ​​कि एक लाइन परिवर्तन में भी एक दिन कम से कम लिया गया था, हालांकि यह इस तथ्य के कारण था कि बिल्ड ने ज्यूरिख से लंदन तक एक नेटवर्क लिंक पर 45+ मिनट का समय लिया और ऐप शुरू करने में और 45 मिनट लगे। चेक-इन में प्रति फ़ाइल लगभग 5 मिनट का समय लगा। मैं मजाक नहीं कर रहा हु। लंदन के डेवलपर्स समय के एक अंश में ऐसा कर सकते थे।

वैसे भी, आप जो खोजते हैं, वह यह है कि बड़ी परियोजनाओं पर आपके पास टीम के सदस्यों का एक समूह होगा, जो आप के साथ ज्यादा बातचीत नहीं करते हैं। यह मिनी परियोजनाओं के एक बहुत ही संबद्ध संग्रह की तरह है। मैंने एक बार पढ़ा कि Microsoft विकास ने 5-7 डेवलपर्स की टीमों में परियोजनाओं को तोड़ने का प्रयास किया, यहां तक ​​कि माइक्रोसॉफ्ट ऑफिस जैसी बड़ी परियोजनाओं के लिए भी।

अंतर का एक हिस्सा छोटी और बड़ी कंपनियों के बीच का अंतर भी है: बड़े लोग अधिक प्रक्रिया, अधिक नियम, कम लचीलापन और इतने पर होते हैं। लेकिन इसकी कोई गारंटी नहीं है।

यह करियर के विकास के लिए अच्छा हो सकता है। एक छोटी सी कंपनी में किसी को प्रमोशन मिलने से पहले ही आपको छोड़ना या मरना पड़ता है (या कंपनी को ऐसे बढ़ना पड़ता है कि टीम का विस्तार होता है और आप ऊपर की ओर बढ़ते हैं) जबकि बड़े देव विभागों में आप टीमों और इतने पर आगे बढ़ सकते हैं।

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

Comments

मैंने अपने समय में उनमें से कुछ स्ट्रैंजी को देखा है

— बाइनरी

कभी-कभी मुझे चिंता होती है कि मैं उनमें से एक हो सकता हूं

— Yisroel

"मुझे नौकरशाही के पैमाने बहुत अच्छे लगते हैं।" उस कथन को प्यार करो!

— HLGEM

Answer 2

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

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

Answer 3

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

1. कॉन्फ़िगरेशन प्रबंधन - रात का निर्माण प्रक्रिया - एक बहुत बड़ी बात थी। उन दिनों यह दुनिया में हर रात को फिर से इकट्ठा करने के लिए एक बड़ा वितरित कंप्यूटिंग क्लस्टर लेता था।

2. कार्य प्राधिकरण - और मास्टर समग्र परियोजना अनुसूची पर सही लाइन आइटम के लिए अपना समय चार्ज करना - गर्दन में एक बड़ा दर्द था। नीचे 0.1 घंटे। वेतन वृद्धि।

लेकिन सबसे बड़ी डील थी नोटिफिकेशन। विशेष रूप से इंटरफ़ेस बदलता है।

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

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

इतने लोगों के समानांतर काम करने के साथ, एक कॉन्फ़िगरेशन नियंत्रण बोर्ड था। सभी विभिन्न टीम मैनेजर, प्लस ग्रुप ऑफ पीपल्स जो नौकरी बदलने के लिए बस समन्वय करने के लिए थे।

Answer 4

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

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

Answer 5

मैंने कम से कम सैकड़ों डेवलपर्स वाले संगठन में (संक्षेप में) काम किया है। लेकिन निश्चित रूप से (?), संगठन को आंतरिक रूप से विभाजित किया गया है ताकि आप एक एकल कर्मचारी के रूप में अन्य सभी के साथ सीधे संपर्क न करें, जो कि साथ रखना बहुत कठिन होगा।

उस स्थान पर, सॉफ़्टवेयर को घटकों में विभाजित किया गया था, जिसमें घटकों के आसपास टीमों का गठन किया गया था। कुछ टीमें केवल एक (बड़े) घटक के साथ काम करेंगी, जबकि कई टीमों के पास छोटे (छोटे) घटकों के एक समूह की जिम्मेदारी थी।

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

Answer 6

मैंने प्रोग्रामर की एक बड़ी टीम के लिए कभी काम नहीं किया है , लेकिन एक संगठन का आकार बढ़ने का परिणाम आमतौर पर अधिक नियम हैं। यह हमेशा एक बुरी बात नहीं है! नियमों के अलावा जो सभी के जीवन को कठिन बनाते हैं, कर्मचारियों की सुरक्षा और अच्छी प्रक्रिया सुनिश्चित करने के लिए और भी नियम हैं।

मैंने देखा है कि छोटे संगठनों में प्रबंधक उन चीजों से दूर हो जाते हैं, जो उन्हें एक उद्यम एचआर विभाग द्वारा तुरंत समाप्त कर दिया जाता है।

Answer 7

एक अंतर जो मैंने बड़ी परियोजनाओं के साथ देखा है, वह कार्यालय की राजनीति है। जितनी बड़ी परियोजनाएँ राजनीति में उतनी ही अधिक प्रभावशाली होती हैं।

मेरा पहला प्रोजेक्ट स्कूल के बाहर सौ डेवलपर्स का था। स्कूल से एक अहंकारी और भोली डेवलपर के रूप में मैं वास्तव में उसके लिए तैयार नहीं था । केवल एक चीज जिसने मेरी हाइनी को बचाया (और यह एकमात्र ऐसी चीज है जो कभी भी आपकी रक्षा करेगी ) मेरे द्वारा बनाए गए दोस्तों की राशि थी।

यही सबसे बड़ा सबक मैंने उससे सीखा। हर किसी से दोस्ती करने की कोशिश करें । झटके भी। विशेष रूप से, यदि आपके पास एक मिनट के लिए काम रोकने का मौका है और किसी ऐसे व्यक्ति के साथ वार्तालाप करना है, जिसके साथ आपने पहले कभी बात नहीं की है, तो करें।

Answer 8

मैंने एक बार एक वर्ष में 500 से अधिक लोगों के साथ एक टीम पर काम किया, जिनमें से लगभग 200 डेवलपर थे। हम कई अलग-अलग SOA समाधानों को एकीकृत करते हुए एक EOA वितरित कर रहे थे।

व्यावहारिक रूप से 30 और 50 टीमों के बीच कहीं न कहीं, प्रत्येक प्रोग्रामर की अलग-अलग संख्या (हमारी टीम पर 3) थी, जिनमें से प्रत्येक में समग्र वितरण के एक अलग पहलू की जिम्मेदारी थी।

मैंने जिस सबसे बड़ी टीम पर काम किया, वह लगभग 15 लोगों की थी (यह केवल 3 या 4 महीने के लिए था, एक अलग कंपनी में)। मैं टीम में तकनीकी नेतृत्व कर रहा था, और सुबह 7 बजे काम में लग गया, मुझे 2 घंटे मिलेंगे इससे पहले कि हर कोई अंदर आए, यह एकमात्र तरीका था जिससे मैं अपना कोई भी कार्य कर सकता था।

मैं 8 या 10 से अधिक डेवलपर्स वाली टीम पर काम नहीं करना चाहूंगा, 15 एक टीम के लिए बहुत दूर था (टीम आसानी से दो में विभाजित हो सकती थी, दुर्भाग्य से मेरी कॉल नहीं), 3 या 4 देवता एक है अच्छा आरामदायक आकार IMHO