किसी परियोजना पर देखने के लिए आसन्न कयामत के चेतावनी संकेत क्या हैं? [बन्द है]


66

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

ये परियोजनाएं सीखने के महान अनुभव, आत्मा-कुचल आपदा (या दोनों!) हो सकती हैं, और कई कारणों से हो सकती हैं:

  • दिल का ऊपरी प्रबंधन परिवर्तन
  • अंडर-स्किल्ड / अंडर रिसर्स्ड टीम
  • देव चक्र के दौरान बेहतर प्रतियोगी का उदय
  • ओवर / अंडर मैनेजमेंट

एक बार जब आप इस तरह की परियोजनाओं पर काम कर रहे होते हैं, तो क्या किसी प्रोजेक्ट को विफल करने के लिए डूम किया जाता है?

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

आपके सिर में आसन्न कयामत के खतरे की घंटी को सेट करने के लिए आपको जो चेतावनी संकेत दिखते हैं, वे क्या हैं?


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

दो लेख - प्रोजेक्ट पैथोलॉजी और (अति सम्मोहित) कैओस रिपोर्टडेथ मार्च को एक अच्छी रीडिंग दें यदि आप किताब के बाद हैं।

जवाबों:


70

हीरोइक कोडिंग

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


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

5
खैर, दूसरा बहाना यह एक छात्र होने के नाते। तब कोर्स के लिए खराब प्रोजेक्ट प्लानिंग बराबर है। :)
14

20
ओह, क्राइस्ट। कॉलेज। मैं अपने टर्मिनल के सामने बैठे याद के रूप में सूरज गुलाब, धकेल कर *के और &के अधिक या यादृच्छिक पर कम उम्मीद है कि लानत बात काम शुरू होगा में मेरी सी ++ कोड में चर के सामने। कॉलेज का एक हिस्सा मुझे याद नहीं है।
ब्लेयरहिपो

2
इस साल की शुरुआत में हमारे पास इस तरह की एक परियोजना थी - एक आदमी नियमित रूप से 2 बजे तक काम कर रहा था और मैं 4am शुरू कर रहा था। हमें काम मिल गया, हालांकि, हमारे ऊपर लगाए गए हास्यास्पद समय-तराजू के बावजूद (हम एक विधायी समय सीमा तक पूरा होने के लिए प्रतिबद्ध थे)। हम अभी भी परेशान कर रहे हैं और अब refactoring कर रहे हैं!
क्रिस बकेट

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

44

जब प्रोग्रामर तर्क जीतना शुरू करते हैं "कोड भयानक है, तो हमें खरोंच से शुरू करना होगा।" किसी भी परिपक्व आवेदन पर।

आपको लगता है कि आप इसे बेहतर बना सकते हैं, या समस्या को पूरी तरह से समझ सकते हैं, लेकिन आप वास्तव में ऐसा नहीं करते हैं। ओह, और उन सभी बदसूरत पैच? वे वास्तविक दुनिया के मुद्दों के लिए फिक्स हैं जिन्हें आप फिर से लिखना शुरू करने जा रहे हैं।

इसके अलावा, एक दिन आपको प्रोजेक्ट मैनेजर को यह समझाना होगा कि 6 महीने के काम के बाद आप लगभग 85% क्षमता तक और 150% बग्स के लिए आवेदन जब आपने शुरू किया था।


9
क्या यह सिर्फ कुख्यात नेटस्केप पुनर्लेखन का सारांश नहीं है?
जसरीन


4
मैं असहमत हूं। फिर से लिखने के लिए कुछ खतरे हैं (उदाहरण के लिए दूसरा सिस्टम सिंड्रोम), लेकिन अगर आप इन के बारे में जानते हैं, तो एक फिर से लिखना किसी भी अन्य ग्रीन-फील्ड प्रोजेक्ट की तुलना में अधिक खतरनाक नहीं है।
निक्की

4
कभी-कभी आपको विवाद करने और कुछ ऐसा करने की ज़रूरत होती है जो ऐप को मजबूत, बेहतर, स्मार्ट बना दे। लेकिन मुख्य शब्द विवादित है, न कि हत्या और पुनरुत्थान।
एरिक रेपेने

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

41

समस्या समाधान के रूप में एक नया उपकरण।

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

  • हम शेड्यूल के एक महीने को शेव कर सकते हैं क्योंकि हम एक ऑब्जेक्ट ओरिएंटेड लैंग्वेज (भले ही हमारे पास सी डेवलपर्स हैं) का उपयोग करने की कोशिश करने जा रहे हैं।
  • हम इस नई घोटाले वाली चीज़ को आज़माएँगे- जो हमारी सभी प्रक्रिया समस्याओं को ठीक कर देगी!
  • मुझे पता है कि यह परियोजना के माध्यम से आधा है, लेकिन क्या होगा अगर हमने ओआरएम को कुछ नया में बदल दिया है?

नई प्रौद्योगिकियां और प्रथाएं महान हैं, लेकिन आपको लगभग सभी लाभ गेट से बाहर नहीं मिलते हैं।


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

2
"कमाल! अब जब हमने यूनिट टेस्टिंग फ्रेमवर्क को उबार लिया है, तो हम उस लंबे क्यूए चरण से समय काटना शुरू कर सकते हैं!"
अर्काटितो

हा हा हा। अति उत्कृष्ट। नए टूल के लिए +1 मेरी सभी समस्याओं का समाधान करेगा।
जल्दी_अगले

40

मेरे लिए सबसे बड़ी समस्या, और एक आप तुरंत हाजिर हो सकते हैं, जब व्यवसाय लिखित आवश्यकताओं को समय की बर्बादी मानता है।

तो मूल रूप से; लिखित आवश्यकताएं नहीं

यह मौत का चुम्बन है।


3
या इससे भी बदतर, लिखित आवश्यकताएं जो कोई भी नहीं पढ़ता है। वास्तव में, मैं उन परियोजनाओं पर रहा हूँ जहाँ व्यापक आवश्यकताओं को लिखा गया था और प्रोग्रामरों को कभी नहीं दिखाया गया था।
JohnFx

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

5
मुझे एक बार एक व्यापार विश्लेषक ने बताया था कि आवश्यकताओं की आवश्यकता नहीं थी। बस फिर से एक व्यापार विश्लेषक का काम क्या है? ओह, आवश्यकताओं को लिखने के लिए हाँ! हमें इस तरह के काम करने की आवश्यकता होगी जैसे कि hkjk.com करता है।
HLGEM 14

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

1
@ मिनी - मैं यह नहीं कह रहा हूं कि आवश्यकताओं को स्थिर होना चाहिए, और कभी नहीं बदलना चाहिए। मैं कह रहा हूं कि आपको गलत संचार को रोकने और विचारों को समय के साथ लोगों के सिर में बदलने से रोकने के लिए इसे लिखना चाहिए। यदि आवश्यकताओं को बदलना चाहिए, तो उन्हें बदल दें, लेकिन वर्तमान आवश्यकताओं को नीचे लिखे रखें। क्या इसका कोई मतलब है?
जॉन मैकइंटायर 16

33

प्रबंधन डिस्कनेक्ट

जब वे डेडलाइन, फीचर्स, स्टाफिंग आदि के लिए जिम्मेदार होते हैं, तो प्रोजेक्ट डिलीवर करने के लिए जिम्मेदार लोगों से अलग हो जाते हैं। यह करने के लिए नेतृत्व कर सकते हैं:

  • फ़ीचर रेंगना जब ग्राहक किसी ऐसे व्यक्ति के साथ बात कर रहा है जो फ़ीचर कॉस्ट नहीं समझता है
  • मैन-महीने सिंड्रोम, जहां नए डेवलपर्स को एक परियोजना में देर से फेंक दिया जाता है एक सहायता की तुलना में अधिक बाधा
  • अवास्तविक समय सीमा, उन लोगों द्वारा बनाई गई है जिन्हें समय सीमा के निर्णयों के व्यावसायिक परिणामों से निपटना है, लेकिन कार्यान्वयन परिणाम नहीं हैं।
  • ऐसे उत्पाद जो समस्या का समाधान नहीं करते हैं, जब ग्राहक-संचार को बीच में प्रबंधन द्वारा बाधित किया जाता है।
  • खराब जोखिम प्रबंधन, जहां संभावित समस्याओं का संचार देवों और प्रबंधन के बीच जल्दी से नहीं किया जाता है।

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


अपने पहले आइटम के लिए +1। मैं आपके द्वारा उल्लिखित परिदृश्य में एक ग्राहक रहा हूं और यह सभी के लिए बुरा है (कोई भी एक अप्रत्याशित बिल नहीं चाहता है, और कोई भी इसे भुगतान करने पर तर्क नहीं चाहता है)।
8

+1 आमीन। वहाँ किया गया है, कि फिर से उस स्थिति में होने की परवाह नहीं है।
इवान प्लाइस

इस तथ्य के लिए कि मैं इन सभी गोलियों के साथ रह रहा हूं (शायद 4 वें को छोड़कर)।
एशेल्ली

बहुत बढ़िया जवाब। यहां तक ​​कि अगर आप विस्तृत करने की जहमत नहीं उठाते हैं, और आपने केवल 'मैनेजमेंट डिस्कनेक्ट' डाल दिया है, तो आपका जवाब +10 होगा।
जिम जी।

25
  1. जब मुख्य डेवलपर्स निकल जाते हैं और प्रबंधन को परवाह नहीं होती है

  2. जब मुख्य डेवलपर्स निकल जाते हैं और कोई भी अन्य डेवलपर्स देखभाल नहीं करता है

नंबर एक आमतौर पर उन प्रबंधकों का संकेत होता है जो टीम की गतिशीलता (जो "10x सुपर स्टार" हैं, जो सभ्य प्रोग्रामर हैं, और वे एक दूसरे के साथ कैसे बातचीत करते हैं) के साथ गंभीर रूप से बाहर हैं।

नंबर दो आमतौर पर शेष डेवलपर्स की ओर से गंभीर अभाव-ब्याज को इंगित करता है।


24

पहली बार कोई, आमतौर पर प्रबंधन कहता है "हमारे पास समय नहीं है .."

आमतौर पर किसी ऐसी चीज से पहले जो हमारे पास नहीं है, जैसे कि प्रलेखन या कोड समीक्षा (जो सांख्यिकीय रूप से अधिक से अधिक बग्स को ढूंढती है और सही करती है, जिसमें सभी प्रकार के परीक्षण शामिल हैं)


8
उस के लिए एक संदर्भ मिला? यह उपयोग करने के लिए बहुत अच्छा होगा ...
एलेक्स Feinman

1
इसे "Mawg का पहला सॉफ्टवेयर प्रबंधन का नियम"
Mawg

1
@ एलेक्स फेनमैन: IIRC कोड कंप्लीट में इन जैसे आंकड़ों के बहुत सारे संदर्भ हैं।
nikie

21

ग्राहक, विपणन या प्रबंधन को एक तारीख चुनने दें और फिर एक काल्पनिक कार्यक्रम में पीछे की ओर काम करने की कोशिश करें


धन्यवाद। Alwasy याद रखें, आप इसे जल्दी, सस्ता या काम कर सकते हैं ... किसी भी दो को चुनें
Mawg

21

जब प्रबंधन व्यवसाय के लिए "नहीं" कहने के लिए बहुत कमजोर है।

यह उन डेडलाइनों की ओर जाता है जो कभी नहीं मिलेंगे, जो आईटी विभाग में विश्वास की कमी की ओर जाता है जो डेवलपर्स को हैक्स बनाता है (यानी किसी की मशीन पर एक्सेस डीबी चल रहा है ... कहीं) जो आईटी के लिए एक बुरा सपना होता है जब ' क्रिटिकल सिस्टम 'को माइग्रेट करना पड़ता है ...


'रियायत सुविधाओं' की तुलना में कुछ भी गुंजाइश नहीं है, क्योंकि जब वह मील का पत्थर की तारीखों को निर्धारित करता है तो पीएम खराब हो जाता है।
इवान प्लाइस

21

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

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

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

बेशक हर बार समय सीमा को पीछे धकेलने के बिना रेंगना सबसे आम लक्षण है जो चीजें खराब होने वाली हैं। आप मेरी प्लेट में 20 घंटे का काम जोड़ दें, समय सीमा 20 घंटे बढ़ जाती है। यदि यह नहीं होता है तो परियोजना विफल हो जाएगी, गारंटी।


हां, समाचार बेहतर हो जाता है क्योंकि यह यात्रा करता है :)
हंस Westerbeek

18

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


6
मेरे पास एक बार एक प्रबंधक था जो एक प्रोजेक्ट (सही निर्णय) के लिए एक फ्रंट एंड वेब कोडर में लाना चाहता था, लेकिन क्योंकि प्रोजेक्ट पर कोई और व्यक्ति लंबे समय से बीमार था, नए आदमी के अनुबंध में लिखा हिट चाहता था कि उसे अनुमति नहीं थी बीमार होना।
जॉन होपकिंस

1
@ जॉन - यह दुखद है ... मजाकिया, लेकिन बहुत दुखद!
वाल्टर

16

जब गैर-तकनीकी प्रबंधक तकनीकी निर्णय लेने पर जोर देते हैं कि वे किसी भी तरह से बनाने के योग्य नहीं हैं। बड़ा, बड़ा लाल-झंडा!


16

सबसे स्पष्ट संकेत एक उच्च कर्मचारी कारोबार है। जब हर कोई एक नई नौकरी की तलाश में है, तो आपको भी शायद चाहिए।

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


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


11

आप "90% काम कर रहे हैं", डिलीवरी अगले सप्ताह है, लेकिन यह ठीक है क्योंकि आपके पास जो कुछ बचा है वह "परीक्षण" है।


2
बहुत मजेदार लगता है कि अब आप इसे कहते हैं। हालांकि मेरे पास आया। उस समय मजाकिया नहीं था।

+1000 ऐसा होता है, जहाँ मैं पूरे समय T_T
सोंगो

1
यह मजेदार है कि हर शेड्यूल का अंतिम चरण के रूप में परीक्षण होता है जैसे कि परीक्षण में कोई बग नहीं मिलेगा। यदि नहीं, तो परीक्षण से क्यों परेशान हैं?
जॉनफैक्स

चिंता न करें, "ग्राहक हमारे लिए इसका परीक्षण करेगा" :-(
मग

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

(जिम मैककार्थी के डायनामिक्स ऑफ़ सॉफ्टवेयर डेवलपमेंट से क्रिब )।


+1 के लिए "आप शेष अभिमान हैं जो आपके शिपिंग के बजाय शिपिंग के कार्य में है"। यह इतना सच है (हालांकि मैंने केवल अपने प्रबंधकों में देखा था। हम डेवलपर्स को पता था कि दरवाजे से क्या निकला ... पैर पहले)

10

चरवाहे कोडर, बड़े अहंकार, और प्रबंधन स्वीकृति


एक चरवाहा कोडर क्या है?
क्रिएटिव मैजिक

विकिपीडिया आपका मित्र है en.wikipedia.org/wiki/Cowboy_coding
मग

नहीं पता था कि यह एक शब्द है, धन्यवाद! वेल्ड, मैं अपने रैंचो में वापस जा रहा हूं ...
क्रिएटिव मैजिक

9

यदि परियोजना योजना में डिजाइन, विकास, परीक्षण और तैनाती के एक एकल पुनरावृत्ति के लिए कॉल किया जाता है - क्लासिक झरना - 1 महीने से अधिक समय के लिए, मैं एक मील चलाऊंगा।

आपको पूरी तरह से चुस्त रहने की आवश्यकता नहीं है, लेकिन अल्प विकास चक्र होने से आप सभी को प्रगति (ग्राहक, प्रबंधन और खुद डेवलपर्स) का प्रदर्शन करने और अपरिहार्य होने पर परिवर्तित आवश्यकताओं से निपटने की अनुमति देते हैं।


6
जब सही तरीके से इसका इस्तेमाल किया जाता है तो झरने में कुछ भी गलत नहीं होता है। दुर्भाग्य से यह कभी भी सही ढंग से उपयोग नहीं किया जाता है :)
एडॉल्फ लहसुन

@adolf - मैं झरने के माध्यम से एक एकल पास के बारे में सोच रहा था। कई मिनी झरने शायद ठीक हैं।
ChrisF

imo, Agile झरने की श्रृंखला है। बहुत कम ही सही ढंग से जलप्रपात कर सकते हैं, एर्गो ..
मग

@mawg - मेरी बात एक एकल लंबी यात्रा के खराब होने के बारे में थी जबकि लघु पुनरावृत्ति (हालांकि वे प्रबंधित हैं) की एक श्रृंखला बेहतर है।
ChrisF

1
इलेक्ट्रॉनिक चीजों को विकसित करने वाली एक परियोजना की याद दिलाता है, जहां कोई प्रोटोटाइप नहीं है जहां अनुसूचित ... में आसन्न आपदा का एक निश्चित संकेत।
जल्दी_अगले

9

रेंज पर वाइल्ड रनिंग करते डेवलपर्स

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

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

8

जब किसी प्रोजेक्ट के प्रमुख डेवलपर ने हफ्तों तक किसी भी कोड की जाँच नहीं की है और एक गंभीर मील का पत्थर सामने आ रहा है।

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

यह कहने के लिए पर्याप्त है कि, बाकी परियोजना एक मर्दवादी मृत्यु मार्च थी, कल्पना में देरी हुई, ग्राहक को रियायत सुविधाओं का एक गुच्छा दिया गया, जिससे पीएम ने परियोजना को छोड़ दिया, और परियोजना की गुणवत्ता को नुकसान पहुंचा। इसके कारण चारों ओर।

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

मैं यहां पाए गए अन्य उत्तरों में से कम से कम 5 के साथ आसानी से पहचान सकता हूं जो उस परियोजना को प्रभावित करते हैं। संक्षेप में, मैंने अपने पहले गंभीर कोडिंग प्रोजेक्ट पर कई कठिन सबक सीखे।


8

एक पर मेरा पहला संकेत तब था जब उन्होंने पूछा था कि अगले दस हफ्तों के लिए हम कितने घंटे ओवरटाइम करेंगे और वेतनभोगी श्रमिकों को परियोजना की सफलता के आधार पर ओवरटाइम कहा और काम की समय सीमा को पूरा करने के लिए बोनस की पेशकश की।

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

जब क्रिटिकल पाथ पर आइटम ऑर्डर के बजाय एक साथ किए जा रहे हैं। (यदि मुझे उपकरण X का उपयोग करना आवश्यक है और प्रोग्रामर A इसे बनाना शुरू कर रहा है, तो यह मेरे कार्य में देरी करने वाला है।)

जब प्रबंधक धन्यवाद पर कोड कर रहे हैं।

जब आपको ऐसे ईमेल मिलने शुरू हो जाते हैं, जिनमें रात 11 बजे से पहले और सुबह 6 बजे से पहले का डेटाइम स्टैम्प होता है।

जब कुछ जटिलता को संभालने के बारे में हर सवाल एक ही जवाब के साथ मिलता है, "अभी तक इसके बारे में चिंता न करें।"

जब वे अभी भी आवश्यकताओं को बदल रहे हैं, तो दिन के दांव को आप क्यूए पर जाएं या लाइव जाएं।

जब आप दैनिक बैठकें शुरू करते हैं जो आपकी प्रगति की कमी पर चर्चा करने में कई घंटे लेती हैं। ओह, ऐसा इसलिए होगा क्योंकि मैं पूरे दिन बैठकों में हूं। दैनिक 5 मिनट की बैठक ठीक है, दैनिक बैठक जो एक घंटे से अधिक होती है, ठीक नहीं।

जब डेटाबेस टीम और एप्लायंस टीम एक दूसरे से बात नहीं करते हैं।

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

जब आप कुछ प्रबंधक के कार्यालय के बाहर स्टॉप लाइट लगाने पर विचार करते हैं, तो आपको बताएंगे कि क्या उस दिन उनसे संपर्क करना सुरक्षित है।


2
आपके पहले पैराग्राफ पर किकर है, यदि प्रबंधन ऐसा कर रहा है, तो समय सीमा संभवतः पहले से ही बर्बाद हो गई है और बोनस अप्राप्य है।
डेविड थॉर्नले

1
@ डेविड थॉर्नले, हां बिल्कुल ऐसा है।
एचएलजीईएम

6

मुझे लगता है कि समय-सीमा समाप्त होने पर असफल परियोजना को देखना आम तौर पर आसान होता है। जैसा कि आपने कहा, सेट-इन-स्टोन डेडलाइन के साथ संयुक्त रेंगना एक परियोजना को मारने का एक निश्चित तरीका है।

हालांकि कुंजी पहले से ही असफल परियोजना का रास्ता तय करना है। मुझे लगता है कि इस मामले में एकमात्र वास्तविक 'कयामत का संकेत' 'जब हम समाप्त होंगे' की परिभाषा का पूर्ण अभाव होगा। जब तक हम यह नहीं जानते हैं कि हम IMO विफलता के लिए बर्बाद हो चुके हैं।


1
उर्फ "किया की परिभाषा", जैसा कि आईटी और व्यापार दोनों से सहमत है
एडॉल्फ लहसुन

6

मैं पिछले पांच वर्षों में तीन मृत्यु मार्च में रहा हूं। यहाँ कुछ चीजें हैं जो आसन्न कयामत के मेरे पेट महसूस करने में योगदान करती हैं।

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

मैं तुम्हें उस अंतिम बिंदु के लिए एक लाख दे दूँगा।
HLGEM

5

मेरे लिए, यह तब होता है जब वे जो सुविधा सेट (उर्फ प्रबंधकों, उत्पाद मालिकों, ग्राहकों ...) के लिए ज़िम्मेदार होते हैं, देखभाल करना बंद कर देते हैं या लगता है कि उनके उत्तरों के बारे में एक निराशाजनक हवा है। सुविधाओं के बारे में सवाल उदासीनता और हतोत्साह के साथ मिलते हैं। यह स्पष्ट है कि उन्होंने परियोजना में निवेश या विश्वास खो दिया है।

मेरे लिए यह तब हुआ जब मैं जिस प्रोजेक्ट पर था, उसमें "दिल का ऊपरी प्रबंधन परिवर्तन" था। मैं इस बारे में सवाल पूछ रहा था कि इसे कैसे काम करना चाहिए और अचानक किसी ने भी वास्तविक राय नहीं दी।

थोड़ी देर बाद परियोजना को रद्द कर दिया गया था और मेरे द्वारा लिखे गए सभी सुंदर कोड को हटा दिया गया था।


5

ब्लैक विक परियोजनाओं के बारे में कई साल पहले पॉल विक ने एक उत्कृष्ट पोस्ट लिखा था । मुझे लगता है कि सभी सलाह प्रासंगिक हैं। (मैंने लंबाई के लिए आइटम और सारांश संपादित किए हैं।)

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

4

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

मैंने अभी तक एक प्रबंधक को इन पंक्तियों के साथ कुछ कहते सुना है और क्या यह झूठ नहीं निकला है।


Lolx! सच है; "आपने रमो (यू) आरएस ..." बैठक सुनी होगी।
मग

4

एक मृत परियोजना से कुछ बिंदुओं का हिस्सा मैं था:

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

3

जब प्रबंधन परियोजना को अलग-अलग दिशाओं में एक साथ खींचता है और गाड़ी अभी भी बनी हुई है।

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


LOL, मैंने इस तरह एक जनशक्ति अध्ययन का काम किया, हालांकि इससे भी बदतर दोनों नेतृत्व एक ही महिला के साथ संबंध बनाने की कोशिश कर रहे थे। यदि बिल ने हां कहा, तो बॉब ने कहा नहीं और इसके विपरीत, सबसे खराब परियोजना जो मैंने कभी काम की थी। मैं आश्वस्त होने के लिए भीख माँगता हूँ।
HLGEM

3

इस संक्षिप्त लेख देखें: जब आईटी परियोजनाओं सही जाओ

लेख में बताए गए किसी भी तत्व की अनुपस्थिति में खतरे की घंटी बजनी चाहिए:

इसलिए सुनिश्चित करें कि आपकी परियोजना में निम्नलिखित सभी हैं, यदि नहीं तो आपको चिंतित होना चाहिए:

(उपरोक्त लेख :) उद्धृत करने के लिए

  1. "पहला यह है कि वे स्पष्ट दृष्टि पर आधारित हैं कि क्या हासिल किया जाना है।"

  2. "दूसरी विशेषता व्यवसाय में शामिल विभिन्न दलों के समर्थन और प्रतिबद्धता की चिंता करती है, विशेष रूप से वरिष्ठ प्रबंधन।"

  3. "तीसरे से निपटने के लिए समस्याओं की समझ है।"

  4. "अंतिम आम विशेषता यह है कि पर्याप्त संसाधन और कौशल उपलब्ध कराए गए हैं।"


बढ़िया लेख! मुझे "जब चीजें सही हो जाती हैं" दृष्टिकोण पसंद है।
user8865

3

सांख्यिकीय रूप से एक सॉफ्टवेयर परियोजना शुरू करना एक उचित संकेत है कि यह विफल हो जाएगा, क्योंकि उनमें से अधिकांश भारी हो जाएगा ...


1
मुझे लगता है कि यह एक स्टार्ट-अप स्टैटिस्टिक है, जरूरी नहीं कि एक सामान्य सॉफ्टवेयर प्रोजेक्ट स्टैटिस्टिस्टिक हो।
एरिक रेपेने

2
यहां एक संदर्भ बेतरतीब ढंग से गूगलेड है जो लगता है कि यह स्टार्ट-अप तक सीमित नहीं है। विषय पर आगे के रत्नों के लिए श्री मैककॉनेल का उत्कृष्ट रैपिड डेवलपमेंट भी देखें ।
निट्सन वकार्ट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.