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