टीम में एक नया डेवलपर कैसे जोड़ें


24

मैं केवल 2 डेवलपर्स से बना एक छोटी सी कंपनी चलाता हूं। हम अपने ग्राहकों में से एक के लिए एक बहुत बड़ा एप्लिकेशन बना रहे हैं। इस परियोजना पर विकास 1.5 वर्षों के लिए चला गया है।

अब इस ग्राहक ने एक महत्वपूर्ण प्रायोजन प्राप्त किया है, और वे इस परियोजना से संबंधित कार्यक्रम आयोजित कर रहे हैं। तो अब हमारे पास 2 महीने की समय सीमा है और हम इसे याद नहीं कर सकते हैं।

हम टीम में एक नए डेवलपर को शामिल करने के बारे में सोच रहे हैं, और मैं सोच रहा हूं कि उनके एकीकरण में मदद के लिए हम क्या कर सकते हैं।

यह स्थिति है:

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

क्या अब किसी व्यक्ति को जोड़ना एक अच्छा विचार है? यदि हां, तो नए डेवलपर को टीम में एकीकृत करने में मदद करने के लिए हम क्या कर सकते हैं?

संपादित करें:

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

क्या हम डेवलपर्स (मैं दो में से एक हूं) को करने की आवश्यकता है:

  • मौजूदा एप्लिकेशन (कार्य करने का लगभग 25%) पूरा करना।

  • एक नया मॉड्यूल बनाना, इस घटना के संगठन के लिए आवश्यक है (लगभग 75% काम करने के लिए)। मुख्य प्रोग्राम के एपीआई को समझे बिना इस नए मॉड्यूल को विकसित नहीं किया जा सकता है।

मैं सटीक समय का अनुमान नहीं लगा सकता, लेकिन हम एक जोखिम भरी स्थिति में हैं।


11
आप ब्रुक के कानून की दहलीज पर नहीं हैं, जिसे एक साल पहले पारित किया गया था।
रयथल १12

3
आपने एक शब्द नहीं लिखा कि उस समय सीमा के लिए आपका क्या लक्ष्य है। उस प्रायोजक के लिए विशिष्ट कुछ सुविधाएँ जोड़ें? घटनाओं के लिए एक उत्पाद प्रस्तुति करें? एक स्थापना पैकेज बनाएं? कुछ सबसे महत्वपूर्ण मुद्दों को ठीक करें? आपके पास अपनी वर्तमान टीम के साथ क्या समस्याएं नहीं हैं?
डॉक ब्राउन

2 डेवलपर्स को कितना समय लगता है कि उन्हें अपने दम पर आवश्यकता होगी? 3 महीने (गणना 2 देव * 3 महीने के बराबर 3 देव * 2 महीने)?
स्कारफ्रिज

@DocBrown मैंने प्रश्न में अधिक विवरण जोड़े। मुझे उम्मीद है कि अब यह स्पष्ट है।
lortabac

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

जवाबों:


24

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


पुराने कोड के लिए Unittests को जोड़ना और बग को ठीक करना कुछ विचार हैं जो नया डेवलपर कर सकता है - बेशक दूसरों द्वारा समर्थन और कोड समीक्षा के साथ। शायद स्वचालित यूआई परीक्षण की आवश्यकता है? यह भी कुछ नया देवता कर सकता है और आवेदन के बारे में बहुत कुछ सीख सकता है।
हंस-पीटर स्टॉर

18

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

यहां तक ​​कि अगर आपको लगता है कि कार्यभार में वृद्धि अस्थायी नहीं है, तो अब अपनी टीम को व्यवस्थित रूप से विकसित करने का सबसे अच्छा समय नहीं है: तीसरे डेवलपर को जोड़ना एक टीम के लिए एक तनावपूर्ण बात है, यहां तक ​​कि परियोजना की समय सीमा के दबाव के बिना भी; तंग समय सीमा ही संक्रमण को बदतर बनाती है।

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


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

1
@ निक मैं सहमत हूँ, उच्च लागत निश्चित रूप से एक व्यापार है; इसलिए ज्ञान परियोजना से दूर है। निकट-शून्य-स्टार्ट-अप व्यक्ति प्राप्त करना कठिन है, विशेष रूप से एक छोटी सूचना पर, लेकिन मैंने इसे कई समय-महत्वपूर्ण परियोजनाओं पर देखा है। हालांकि उन्हें काम पर रखने की लागत काफी अधिक थी।
dasblinkenlight

मैं कुछ शोध करूंगा, लेकिन मेरे क्षेत्र में एक अनुभवी सलाहकार को ढूंढना मुश्किल हो सकता है। क्या आपको लगता है कि किसी दूसरे शहर के व्यक्ति के साथ काम करना संभव होगा? या आगे की प्रक्रिया को धीमा कर देगा?
lortabac

3
मुझे लगता है कि ब्रुक का कानून एक अनुभवी सलाहकार के लिए भी लागू होता है, इसलिए मुझे नहीं लगता कि यह समस्या का वास्तविक समाधान होगा।
डॉक ब्राउन

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

14

क्या अब किसी व्यक्ति को जोड़ना एक अच्छा विचार है?

यदि संभव हो तो, ग्राहक को इसके बजाय गुंजाइश कम करने पर सहमत होने का प्रयास करें।

किसी व्यक्ति को इस देर से जोड़ना महत्वपूर्ण जोखिम को बढ़ाएगा, और समय सीमा को धक्का नहीं दिया जा सकता है (जहां तक ​​मैंने समझा है)।


4
+1। सभी सुविचारित, उच्च मतदान वाले अन्य सुझावों के बावजूद, मुझे लगता है कि यह शायद सबसे अधिक एकमात्र ऐसी चीज है जो वास्तव में ऐसी स्थिति में काम करेगी।
डॉक ब्राउन

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

10

यह मत करो।

फिर भी।

पारंपरिक दृश्य

अपने प्रश्न में, आप पौराणिक मानव-मासिक से ब्रुक्स के नियम का उल्लेख करते हैं ।

देर से सॉफ्टवेयर प्रोजेक्ट में मैनपावर जोड़ना बाद में बनता है।

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

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

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

एजाइल, न्यू मिलेनियम व्यू

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

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

नए कर्मचारियों के लिए एजाइल टीम तकनीकी और सामाजिक एकीकरण का उपयोग कर सकती है:

  • रोजाना स्क्रब
  • जोड़ा प्रोग्राम तैयार करना
  • रिफैक्टरिंग
  • लापता इकाई परीक्षण जोड़ना
  • दुबला प्रलेखन को मेद
  • कोड समीक्षाएँ

बलि का मेम्ना

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

यह एक रणनीति है जिसे आप लागू करने पर विचार कर सकते हैं।

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

वर्तमान में मेंटरिंग एक व्यक्ति द्वारा किया जाता है, मुख्यतः हमारे सुबह के घोटाले के दौरान और तुरंत बाद (सुबह 8:30 से सुबह 9:15 बजे तक, संयुक्त), और दोपहर में 12 से 3:30 के बीच (वह सुबह 7 - 3:30 बजे तक काम करता है। बजे)।


वह पुस्तक थोड़ी मूल्यपूर्ण है, लेकिन मैं इसकी जाँच करने जा रहा हूँ।
ग्रीन

आप शायद उन पुस्तकों के अंश पा सकते हैं, जिनका मैंने ऑनलाइन उल्लेख किया था, शायद Google पुस्तकों के माध्यम से। मैंने अपने स्थानीय विश्वविद्यालय के पुस्तकालय के माध्यम से ब्रूक्स और कोपलिन दोनों पुस्तकों को उधार लिया।
डेवलपर

6

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

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

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

@StevenV जो एक उत्कृष्ट, उत्कृष्ट विचार है। जिन घटकों को आप नहीं जानते उनके लिए परीक्षण लिखना आपको उनसे बहुत तेजी से परिचित कराएगा। और आपके द्वारा किए जाने पर सिस्टम अधिक परीक्षण योग्य है। :)
ग्रीन

5

यदि आप ब्रुक के नियम का कड़ाई से पालन करते हैं, तो आप संभवतः अपनी टीम को कभी नहीं बढ़ाएंगे।

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

आपके मामले में? मेरा सुझाव होगा कि नया व्यक्ति उन सभी लापता इकाई परीक्षणों को लिखें।

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

इसके अलावा, आइए इसका सामना करें: आपको किसी नए व्यक्ति को लाने या न लाने की परवाह किए बिना गुंजाइश और ग्राहक अपेक्षाओं का प्रबंधन करना होगा। भुगतान अगले चक्र में आता है।

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


3

यदि आपके पास अन्य परियोजनाओं पर काम है जो आप उसे दे सकते हैं जो 2 वर्तमान डेवलपर्स के लिए बड़ी समय सीमा डिलिवरेबल्स पर ध्यान केंद्रित करने के लिए समय खाली कर देगा जो मदद कर सकता है।


3

आप कहते हैं कि आपको मूल काम का 25% पूरा करना होगा, साथ ही नया काम भी करना होगा। एएनडी आपको दो महीनों में ऐसा करने की आवश्यकता है - जब आपको 75% काम करने में 18 महीने लग गए। बहुत कुंद होने के लिए, यह मुझे इंगित करता है कि आपकी अनुमान क्षमता एक कोड-केंद्रित प्रोग्रामर के लिए औसत के बारे में है - यानी, आपको लगता है कि चीजें आपको लगभग आधे से एक तिहाई तक ले जाएगी जब तक वे वास्तव में करते हैं।

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

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

मेरी सिफारिश:

अपने ग्राहक के साथ बैठें, समझाएं कि आप अपने सिर के ऊपर हैं और नंगे न्यूनतम होने की गुंजाइश कम करने के लिए उसके साथ काम करें।

संपादित करें बस यहाँ तारीख देखी। तो यह कैसे समाप्त हुआ? (तीन महीने पुराने प्रश्न को पोस्ट करने के लिए धन्यवाद अर्स टेक्निका;)


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

2

कुछ अलग-अलग तरीके हैं जिनकी मैं जाँच करूँगा:

  1. नए डेवलपर को काम पर रखने की समय सीमा समाप्त होने के बाद तक रोकें ताकि नए व्यक्ति को डोमेन ज्ञान पास करने पर ध्यान केंद्रित करना आसान हो। यह मेरी प्राथमिकता होगी क्योंकि यह कुछ मायनों में थोड़ा चुनौतीपूर्ण हो सकता है।

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


2

तारीख पहले ही चली गई है, लेकिन बाद में इसे पढ़ने वाले किसी के लिए भी।

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

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

यदि वे नीचे गुंजाइश की बातचीत करने के लिए तैयार नहीं हैं, तो आप असफल होने के लिए तैयार हैं।

इस परियोजना को पूरी तरह से समय सीमा में वितरित करने का कोई मौका नहीं है। यदि आपको लगता है कि आपके पास एक परियोजना पर 25% बचा है जिसे अभी तक वितरित करने में 18 महीने लगे हैं, तो आपके पास कम से कम 6 महीने बचे हैं (~ 2 डेवलपर्स में से)। किसी अन्य व्यक्ति को जोड़ने से यह महत्वपूर्ण रूप से नहीं बदलेगा।

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

मुझे आशा है कि इसने आपके लिए काम किया।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.