किसी लेट प्रोजेक्ट में और लोगों को शामिल करना बाद में क्यों बनता है?

Question

यह एक काफी सामान्य कहावत है कि देर से प्रोजेक्ट में अधिक प्रोग्रामर जोड़ने से मामले और बदतर हो जाएंगे। ऐसा क्यों है?

Comments

इसके लिए शब्द ब्रूक्स लॉ ( en.wikipedia.org/wiki/Brooks_law ) है।

— मैकनील

सलाह: ब्रूक्स का "द मैथिकल मैन-मंथ" पढ़ें। यह दिखाएगा कि वह कहावत कहाँ से आई है, यह एक बहुत ही पठनीय पुस्तक है, और क्षेत्र में हर किसी को इसे वैसे भी पढ़ना चाहिए।

— डेविड थॉर्नले

वह विकिपीडिया पृष्ठ बहुत अच्छा लिखा गया है।

— हेनरी

टीम के आकार के साथ उत्पादकता कैसे घटती है, इस बात के प्रमाण के लिए (7 टीम के सदस्यों से जो आपको कम रिटर्न में मिलते

— जोएरी सेब्रेट्स

Answer 1

ओवरहेड का परिचय

प्रत्येक नए डेवलपर को कोड आधार और विकास प्रक्रिया से परिचित कराना होता है, जिसमें न केवल नए व्यक्ति का समय लगता है, बल्कि उसे [a] वरिष्ठ डेवलपर [s] से भी सहायता की आवश्यकता होती है (उन्हें निर्माण प्रक्रिया के माध्यम से मार्गदर्शन करना, परीक्षण प्रक्रिया की व्याख्या करना, उनकी सहायता करना कोड आधार में नुकसान के साथ, अधिक विस्तृत कोड समीक्षा, आदि) ।

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

Comments

इसलिए यदि आप 'परिचय' को अनुकूलित करते हैं तो प्रभाव कम होगा?

— हेनरी

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

— बालर्नोर्न

परिचय करने की लागत के बारे में, क्या यह एक बार वीडियो टेप नहीं किया जा सकता है और फिर कई को प्रसारित किया जा सकता है, ताकि यह एक ही बार में बड़ी संख्या में नए प्रोग्रामर को प्रशिक्षित कर सके? (उदाहरण: डेवलपर बैठक या सम्मेलन।)

— rwong

@rwong: यह एक बुरा विचार नहीं है, लेकिन यह आमतौर पर व्यावहारिक नहीं है। आप केवल जानकारी प्रस्तुत नहीं कर सकते, आपको यह सुनिश्चित करना होगा कि नए लोग इसे समझें। इसके अलावा, यदि वे वास्तव में नए हैं (हाल ही में कब्रें), तो आमतौर पर उन सभी को एक साथ प्रस्तुत करने के लिए बहुत अधिक जानकारी होती है। हमने पाया है कि एक विकी अच्छी तरह से काम करता है, क्योंकि सभी जानकारी एक ही स्थान पर होती है, और लोग प्रश्न पोस्ट कर सकते हैं यदि बिट्स हैं जो उन्हें समझ में नहीं आते हैं।

— TMN

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

— डेविड थोरले

Answer 2

अन्य उत्तरों के अलावा: विचार करने के लिए एक अन्य कारक संचार है।

एक टीम पर संचार चैनलों की मात्रा के लिए सबसे खराब स्थिति (जो असामान्य नहीं है), एक पूर्ण ग्राफ है । जैसा कि आप कल्पना कर सकते हैं, सिर्फ 1 डेवलपर में जोड़ने से संचार चैनल बहुत बढ़ सकते हैं। संचार के अधिक सुव्यवस्थित तरीकों के साथ, प्रभाव कम है ... लेकिन यह अभी भी जोड़ता है।

Comments

मैं लगभग उसी समय लिख रहा था! लेकिन मैं नया नहीं था इसका एक नाम (एक पूरा ग्राफ) था और आपका स्पष्टीकरण बेहतर है, इसलिए मेरा वोट जाता है।

— मिगुएल वेलोसो

+1। सहमत, टीम के सदस्यों को जोड़ते समय यह सबसे बड़ी समस्या है।

— मार्टिन विकमैन

किसी प्रोजेक्ट में लोगों को जोड़ने के साथ अधिक दीर्घकालिक समस्या के लिए +1।

— indyK1ng

Answer 3

मूल रूप से इस कानून को प्रख्यापित करने वाली पुस्तक द माइथिकल मैन-मंथ में वर्णित समस्या का संचार है। उन्होंने कहा:

पुरुषों और महीनों में विनिमेय वस्तुएं होती हैं, जब एक कार्य को कई श्रमिकों के बीच विभाजित किया जा सकता है, जिनके बीच कोई संचार नहीं है। यह गेहूं की कटाई या कपास लेने का सच है; यह सिस्टम प्रोग्रामिंग का लगभग सच भी नहीं है।

वह समस्या के भाग के रूप में प्रशिक्षण का उल्लेख करता है:

संचार का अतिरिक्त बोझ दो भागों से बना है: प्रशिक्षण और अंतर-संचार। प्रत्येक कार्यकर्ता को प्रौद्योगिकी, प्रयास के लक्ष्यों, समग्र रणनीति और कार्य योजना में प्रशिक्षित किया जाना चाहिए। इस प्रशिक्षण को विभाजित नहीं किया जा सकता है, इसलिए काम का यह हिस्सा श्रमिकों की संख्या के साथ रैखिक रूप से भिन्न होता है।

... लेकिन ध्यान दें कि अब तक बड़ा कारक है:

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

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

¹ "सार" की परिभाषा के लिए, एक ही लेखक के "नो सिल्वर बुलेट: एस्सेन्स एंड एक्सीडेंट इन सॉफ्टवेयर इंजीनियरिंग" को देखें, जो द मैथिकल मैन-मंथ की 20 ^वीं वर्षगांठ संस्करण में शामिल है ।

Answer 4

यह केवल कहावत नहीं है; यह सत्य है। ब्रूक्स ' पौराणिक मानव-माह की जाँच करें ।

Comments

यह एक कहावत है। यह सत्यापन योग्य हो सकता है या नहीं भी हो सकता है, लेकिन यह एक कहावत होने से नहीं रोकता है।

— पीटर बॉटन

मेरे पास यह पुस्तक (स्पष्ट रूप से) नहीं है। क्या यह हार्ड नंबरों द्वारा समर्थित है या यह वास्तविक है?

— हेनरी

@ हेनरी: जब से मैंने इसे पढ़ा है लेकिन आईआईआरसी को समझने में कुछ समय लगा है, दोनों ही बिंदु को निर्णायक बनाने के लिए पर्याप्त मात्रा में मौजूद हैं।

— स्टीवन एवर्स

@Peter: मेरे उत्तर का संपादन किया।

— जॉन

@PeterBoughton यह एक कहावत है। इसके अलावा, यह केवल एक कहावत नहीं है।

— शांतिबेलर्स

Answer 5

यहां इस मुद्दे पर कुछ विचार हैं ...

• परियोजना के साथ क्या हो रहा है, इस पर गति लाने के लिए नए संसाधनों को लाने के लिए वर्तमान संसाधनों का उपयोग करने की आवश्यकता है।
• नया संसाधन कोड आधार से परिचित नहीं हो सकता है, इस प्रकार कोड को प्राप्त करने के लिए अधिक समय की आवश्यकता होती है।

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

Comments

संसाधनों को परीक्षण में जोड़ने के लिए, विकास नहीं।

— बेलेनॉर्न

Answer 6

क्योंकि प्रोग्रामिंग मूल उत्पादन लाइन का काम नहीं है। एक सॉफ्टवेयर प्रोजेक्ट पर तेजी लाने में समय लगता है। नए लोगों को बहुत सारे सवाल पूछने की ज़रूरत है, जो नकारात्मक उत्पादकता (यानी नया व्यक्ति सीखने, उन्हें पढ़ाने वाले पुराने व्यक्ति -> कोई वास्तविक काम नहीं हो रहा है) की ओर जाता है।

इसे सरल बनाने के लिए, एक अपेक्षाकृत सरल वन-मैन प्रोजेक्ट की कल्पना करें, जो 1 सप्ताह के लिए निर्धारित है: गुरुवार को, आपको पता चलता है कि यह समय पर नहीं होगा, यह एक प्रोग्रामर को 6-7 दिनों के बजाय अधिक समय लगेगा। 5. यदि आप उस बिंदु पर एक और प्रोग्रामर जोड़ते हैं, तो उन्हें कम से कम कुछ घंटे या एक दिन के लिए प्रोग्रामर 1 के साथ काम करने की आवश्यकता होगी, गति बढ़ाने के लिए बहुत सारे प्रश्न पूछें, आदि। सप्ताह के बाकी दिनों के लिए कोई भी शुद्ध सकारात्मक उत्पादकता। नए प्रोग्रामर को कुछ अतिरिक्त बग भी शुरू करने की संभावना है (क्योंकि उन्हें मौजूदा कोड के साथ-साथ प्रोग्रामर 1 भी नहीं पता होगा), ताकि कार्यान्वयन और परीक्षण चक्र को एक और दिन या दो से अधिक बाहर उड़ा देंगे। परियोजना आसानी से मूल एक के बजाय पूरे दो कार्य सप्ताह चलेगी!

Comments

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

— n1ckp

@ n1ck इसका सामान्यीकरण - जैसे "बहुत सारे रसोइये" - मुख्य बात यह है कि परियोजना में केवल मैनपावर फेंकने से जरूरी नहीं कि इसे किसी भी तेजी से हल किया जा सके। 1 व्यक्ति को 2? संभवतया होगा। 2 से 4? बहुत अधिक चर - यह परियोजना के आकार और संरचना पर निर्भर करता है। 4 -> 8? निश्चित रूप से सीमांत हो रहा है (लागत पर वापसी के मामले में बहुत कम से कम)।

— मर्फ़

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

— n1ckp

ठीक है, उदाहरण बेहतर हो सकता है लेकिन सामान्यीकरण अभी भी मान्य है?

— मर्फ़

मैं यह पर्याप्त समय से गुजर पता चला है कि यह उन चीजों में से एक है कि किया गया है हो सकता है बहुत विशेष मामलों में काम करते हैं, लेकिन समय के 99% यह नहीं होगा। कोई फर्क नहीं पड़ता कि यह सिद्धांत में कितना अच्छा लगता है। यह कहा, हाँ, यह एक काले और सफेद निरपेक्ष नहीं है। यह कहना अधिक है, कि खुले रिश्ते कैसे काम नहीं करते हैं। सिद्धांत अच्छा है, और लुभावना है;) .... लेकिन जानवर की प्रकृति ऐसी है कि ज्यादातर मामलों में यह विफल हो जाता है। एक "अपवाद नियम को साबित करता है" की तरह।

— बॉबी टेबल्स

Answer 7

फ्रेड ब्रूक्स ने इस सवाल का जवाब देते हुए एक पूरी किताब "द मैथिकल मैन-मंथ" लिखी।

यहाँ त्वरित- n- गंदा संस्करण है:

1) अधिक प्रोग्रामर को असाइन करने के लिए आप किसी प्रोजेक्ट को अलग-अलग टुकड़ों में तोड़ सकते हैं।

2) अधिक लोगों के लिए एक परियोजना को विभाजित करने से आवेदन के सभी भागों के समन्वय के लिए आवश्यक संचार की मात्रा बढ़ जाती है। अधिक संचार = अधिक काम।

3) हर उस व्यक्ति के लिए जिसे आप प्रोजेक्ट में जोड़ते हैं, आप एक से अधिक संचार चैनल जोड़ते हैं जिन्हें टीम में नेविगेट किया जाना चाहिए। यह संख्या ज्यामितीय रूप से बढ़ती है और संचार की मात्रा को बढ़ाती है जो होनी चाहिए। अधिक संचार = अधिक काम।

4) जब आप टीम के प्रत्येक सदस्य को जोड़ते हैं तो एक "जे-कर्व" होता है। यही है, मौजूदा उत्पादक संसाधनों को नए लोगों को गति देने के लिए समय बिताना होगा ताकि वे परियोजना पर काम कर सकें। अंततः आप क्षमता बढ़ा सकते हैं, लेकिन यह अस्थायी रूप से परियोजना को धीमा कर देता है। इस परियोजना में बाद में जितना अधिक सीखा जाना चाहिए, इस प्रकार प्रभाव उतना ही अधिक होगा।

Answer 8

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

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

Comments

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

— बॉबी टेबल्स

Answer 9

मेरे लिए हमेशा काम करने वाली कहावत है कि आप एक महीने में एक बच्चा बनाने के लिए नौ महिलाओं को नहीं पा सकते हैं।

Comments

यदि आपको लगता है कि एक सॉफ्टवेयर परियोजना एक बच्चे की तरह है, तो आप वास्तविक दुनिया में नहीं रहते हैं। उद्धरण में कुछ सच्चाई है लेकिन चीजों को संदर्भ से बाहर ले जाने का यह सही उदाहरण है: -1

— n1ckp

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

— रियून

एक अन्य सादृश्य ब्रूक्स एक रेस्तरां में भोजन करना है। एक अच्छी तरह से चलने वाली रसोई समानांतर में बहुत सारे भोजन बना सकती है, लेकिन इसकी सीमाएं हैं कि यह कितनी तेजी से बिना खाना बनाए या जलाए भोजन बना सकता है।

— डेविड थॉर्नले

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

— n1ckp

@ n1ck: मेरी धारणा है कि आप इससे सहमत नहीं हैं क्योंकि आप इसे ईमानदार नहीं समझते हैं। ब्रूक्स सक्षम लोगों के साथ बेकार लोगों को बदलने के बारे में बात नहीं कर रहा था, क्योंकि वह एक ऐसी स्थिति में था जहां हर कोई अभी भी कार्यरत था, सक्षम माना जाता था।

— डेविड थॉर्नले

Answer 10

मैं DeMarco और Lister द्वारा "Peopleware" का सुझाव भी दूंगा।

और डेमार्को द्वारा "द डेडलाइन" इसे प्रस्तुत करता है, और कई अन्य सॉफ्टवेयर परियोजना प्रबंधन रोग और एक प्रकाशयुक्त और बहुत पठनीय फैशन में गिरावट।

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

ये पुस्तकें काफी सस्ती हैं, मेरा सुझाव है कि आप उन्हें (अमेज़ॅन या द बुक डिपॉजिटरी उनके पास) प्राप्त करें और पढ़ें। यहाँ संक्षिप्त उत्तर वास्तव में पूछे गए प्रश्न के साथ न्याय नहीं कर सकता है।

Answer 11

चूँकि किसी के पास एक अच्छी तरह से सोची गई, नियोजित, परीक्षण प्रक्रिया के लिए समय नहीं है: काम पर रखने, प्रशिक्षण, विकास और पर्यवेक्षण करने वाले प्रोग्रामर अकेले उन्हें किसी विशेष परियोजना में तेजी लाने के लिए तैयार करते हैं।

यदि आप डेवलपर्स की एक टीम का प्रबंधन कर रहे हैं, तो आपके पास ऐसे कई संपर्क होने चाहिए, जो आपके पास एक उद्घाटन होने पर आप किराए पर लेना चाहते हैं। डेवलपर समूह में शामिल हों।

कितनी तेजी से आप एक नया विकास मशीन सेटअप प्राप्त कर सकते हैं और जाने के लिए तैयार हैं?

क्या आपने कभी किसी प्रोजेक्ट के डॉक्यूमेंटेशन और स्पेक्स को किसी दूसरे प्रोजेक्ट के डेवलपर को दिखा कर टेस्ट किया है? क्या उन्होंने इसे देखा और निर्धारित किया कि यदि आवश्यक हो तो वे परियोजना पर काम करना शुरू कर सकते हैं?

किसी भी परियोजना के कार्यक्रम की तिथि कितनी है?

एक बरसात के दिन के लिए बचाएं क्योंकि जब कोई परियोजना पीछे पड़ती है तो वह एक हुरियारे की तरह होती है।

Answer 12

संचार मुद्दे के अलावा (जो मुझे लगता है कि सभी अन्य उत्तर के बारे में बात कर रहे हैं), यह किसी व्यक्ति के लिए बग बनाने के लिए एक परियोजना में जोड़ा जाना भी बहुत संभव है, क्योंकि वे कोड को अभी तक अच्छी तरह से नहीं जानते हैं।

जब भी मैं किसी प्रोजेक्ट में शामिल होता हूं, तो मैं हमेशा कोशिश करता हूं कि चीजों को न तोड़ूं। इसका मतलब है कि मैं पहली बार में चीजों को ठीक करने में बहुत धीमा हूं।

Answer 13

मैं अन्य उत्तरों द्वारा अब तक की अनदेखी की गई कुछ बातों को इंगित करना चाहूंगा।

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

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

ऊपर के लोगों ने स्पष्ट रूप से आप पर विश्वास खो दिया है। उन्होंने बड़े लड़कों को बुलाया कि तुमने क्या गड़बड़ की है।

क्या आप इसे सफल बनाने के लिए अभी भी प्रेरित होंगे? या ... क्या आप कभी अधिक निराश होंगे और क्या आप पूरी चीज को दुर्घटनाग्रस्त देखेंगे?

पर्याप्त समय लो :-)।