मुझे mcottle का उत्तर पसंद है और उसे उभारना है, लेकिन मैं कुछ अन्य गतिकी और तर्कों को कवर करना चाहता हूं जो अन्य उत्तरों ने नहीं उठाए हैं।
सबसे पहले, mcottle के उत्तर में निहित यह तथ्य है कि एक निश्चित कौशल स्तर से नीचे, कुछ समस्याएं बस असंभव हैं। दुर्भाग्य से, जिस तरह से आपको यह पता चला है वह आपकी टीम की कोशिश और असफलता से है, जो बहुत हैमहंगा। असफल होने के बाद, इससे सीखने के लिए दो संभावित सबक हैं। एक विकल्प यह है कि आप सीखें कि आपको अधिक सक्षम डेवलपर्स की आवश्यकता है और इसलिए आप उन्हें किराए पर लेते हैं और आप इस परियोजना को काफी अधिक बजट और अति-अनुसूची में पूरा करते हैं, लेकिन कम से कम आप भविष्य में तैयार हैं। दूसरा विकल्प यह है कि इस तरह की परियोजना आपकी टीम के लिए "बहुत कठिन है" और भविष्य में ऐसी चीजों का प्रयास नहीं किया जाना चाहिए, अर्थात आप परियोजना को छोड़ देते हैं और प्रभावी रूप से किसी भी समान। बेशक, यह शायद ही कभी "हम ऐसा करने के लिए बहुत मूर्ख हैं" के रूप में चित्रित किया जाएगा, लेकिन इसके बजाय "हमारे सिस्टम बहुत जटिल हैं" या "हमारे पास बहुत से विरासत कोड हैं" या कुछ अन्य हैं। यह बाद वाला दृश्य किसी कंपनी के दृष्टिकोण को महत्वपूर्ण रूप से बता सकता है कि क्या संभव है और कितना लंबा / महंगा विकास होना चाहिए। "
एक सवाल यह है कि आपकी कंपनी की योजना वास्तव में क्या है? ठीक है, वे सस्ते, जूनियर प्रोग्रामर किराए पर लेंगे। तीन साल बीत गए, अब क्या? वे उन तीन वर्षों में उनके साथ रहे डेवलपर के साथ क्या करते हैं? क्या उन्होंने सिर्फ उसे कभी नहीं उठाया? यहाँ विकल्प निम्नलिखित हैं:
- वे कर्मचारियों को बनाए रखने के लिए प्रतिस्पर्धात्मक रूप से वृद्धि करते हैं, ऐसे में उन्हें वरिष्ठ डेवलपर दरों का भुगतान करने में समस्या क्यों होगी? मैं हालांकि इस पर वापस आऊँगा।
- उनके पास स्थिर दर है जिसका अर्थ है कि वे अंततः उन कर्मचारियों को "उबाल" रहे हैं जिनके पास ड्राइव और / या कौशल की कमी है।
- वे अधिक सक्रिय रूप से अधिक वरिष्ठ कर्मचारियों को हटा देते हैं।
दूसरे दो मामलों में बहुत से कर्मचारी टर्न ओवर करते हैं, जिसका मतलब है कि कंपनी के ज्ञान का नुकसान और लगातार कर्मचारियों को रैंप देना। दूसरे मामले में, आप अनिवार्य रूप से खराब डेवलपर्स के लिए चयन कर रहे हैं और इसलिए लागत बढ़ती अनुसूचियों के रूप में बढ़ेगी। जिस तरह से यह बाहर खेलेंगे सब कुछ ठीक है एक्स पर परियोजना एक्स अचानक जीप छोड़ देता है, जो बेहतर डेवलपर्स में से एक था, क्योंकि उसने दो साल में एक वृद्धि नहीं की है, अब परियोजना "समझ में" के रूप में लंबे समय तक ले जाएगी आपको नए जूनियर डेवलपर्स को नियुक्त करने और प्रशिक्षित करने की आवश्यकता है जो (संभवतः) जिम के रूप में अच्छे नहीं होंगे। इस तरह से आप उम्मीदों पर फिर से कायम हैं।
यहां तक कि इस मामले में कि प्रतिस्पर्धात्मक वृद्धि प्रदान की जा रही है, यदि आपके पास सभी जूनियर डेवलपर हैं, तो उन्हें कहां और कैसे सीखना चाहिए? आप मूल रूप से उम्मीद कर रहे हैं कि उनमें से एक अपने काम के माहौल के बावजूद अपने दम पर अच्छी प्रथाओं को सीखेगा , और अंततः दूसरों को सलाह देगा (जैसा कि हरियाली चरागाहों के लिए छोड़ने का विरोध किया गया है)। यह कुछ अच्छे डेवलपर्स के साथ "पंप को प्राइम" करने के लिए बहुत अधिक समझ में आता है। अधिक संभावना है कि आप विशेषज्ञ शुरुआती लोगों की संस्कृति विकसित करेंगे । इसका परिणाम यह है कि आप वरिष्ठ डेवलपर दरों का भुगतान उन लोगों को करेंगे जो केवल जूनियर डेवलपर्स से थोड़ा बेहतर हैं और सांस्कृतिक रूप से विषाक्त हैं।
एक लाभ, विशेष रूप से, बहुत अच्छे डेवलपर्स, कि मुझे आश्चर्य है कि किसी और ने उल्लेख नहीं किया है कि वे आसानी से एक गुणक कारक हो सकते हैं । यह अच्छी तरह से हो सकता है कि एक जूनियर डेवलपर और एक वरिष्ठ डेवलपर टेबल बनाने के लिए समान समय लेते हैं। हालाँकि, एक अच्छा डेवलपर ऐसा नहीं करेगा। वे एक टेबल जेनरेटर बनाएंगे जो सभी के लिए टेबल बनाने के लिए समय कम कर देगा। वैकल्पिक रूप से / इसके अतिरिक्त, वे हर किसी के लिए संभव के सीलिंग बढ़ा देंगे । उदाहरण के लिए, जो डेवलपर्स Google के MapReduce ढांचे को लागू करते थे, वे संभवतः बहुत योग्य थे, लेकिन फिर भी उपयोगकर्ताMapReduce अपने एल्गोरिथ्म के एक बड़े पैमाने पर वितरित संस्करण बनाने में पूरी तरह से असमर्थ हैं, वे अब आसानी से MapReduce के साथ कर सकते हैं। अक्सर यह गतिशील कम धुंधला होता है। उदाहरण के लिए, बेहतर स्रोत नियंत्रण, परीक्षण और परिनियोजन अभ्यास सभी को बेहतर बनाते हैं , लेकिन किसी विशिष्ट व्यक्ति को ट्रेस करना कठिन हो सकता है।
दूसरे पक्ष को थोड़ा बहस करने के लिए, शायद उच्च-अप सही हैं। शायद अधिक अनुभवी डेवलपर्स आवश्यक नहीं हैं। यदि ऐसा है, तो, ऐसा लगता है कि विकास कंपनी का एक महत्वपूर्ण हिस्सा नहीं है। उस स्थिति में, मैं सिर्फ डेवलपर्स को पूरी तरह से समाप्त कर दूंगा और ऑफ-द-शेल्फ सॉफ्टवेयर का उपयोग करूंगा या मांग पर ठेकेदारों को काम पर रखूंगा। यह खोज के लायक हो सकता है कि वे इन-हाउस टीम के बजाय ठेकेदारों का उपयोग क्यों नहीं करते हैं। यदि आप वैसे भी बहुत कर्मचारी मंथन करने जा रहे हैं, तो रैंप-अप ठेकेदारों को कोई समस्या नहीं होनी चाहिए।