प्रबंधन के साथ व्यवहार करना जो उन सुधारों में मूल्य नहीं देखता है जो उपयोगकर्ता को तुरंत दिखाई नहीं देते हैं


90

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

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

मैंने हाल ही में अपने बॉस का उल्लेख किया है कि मैं स्वचालित संदर्भ गणना में स्विच करना चाहता था। उनकी प्रतिक्रिया थी कि वह दृश्य सुधार पर ध्यान केंद्रित करना चाहते थे। यह संभावना है कि यह प्रतिक्रिया बदले में दबाव से प्रेरित थी जो वह उसके ऊपर से प्राप्त कर रहा है - और शायद सीईओ से सही है।

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

मुझे स्थिति को कैसे संभालना चाहिए?

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


2
क्या हम लंबे समय तक रहने वाले, महत्वपूर्ण ऐप्स के बारे में बात कर रहे हैं? शायद बाजार का समय रखरखाव और गुणवत्ता की तुलना में अधिक महत्वपूर्ण है?
एंड्रेस एफ।



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

जवाबों:


141

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

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


2
मैंने कई बार कई नौकरियों में इस मुद्दे से निपटा है। मैं टेरी रयान द्वारा "ड्राइविंग तकनीकी परिवर्तन" पढ़ने की सलाह देता हूं कि आप इन मुद्दों के बारे में अपने प्रबंधकों से बेहतर तरीके से कैसे संपर्क कर सकते हैं। pragprog.com/book/trevan/driving-technical-change
एड्रियन जे। मोरेनो

2
वास्तव में सवाल से मैं अनिश्चित हूं कि वास्तव में कितना कर्ज हो रहा है। यद्यपि स्वचालित संदर्भ गणना एक आवश्यक अपग्रेड की तरह लगती है लेकिन मैं यह जानने के लिए डोमेन के साथ पर्याप्त रूप से परिचित नहीं हूं कि "यादृच्छिक अजीब दुर्घटनाओं की संख्या नीचे जाने की संभावना है" या नहीं। <p> सिर्फ इसलिए कि MVC 3 में नया रेजर सिंटैक्स क्लीनर है, इसका मतलब यह नहीं है कि मेरी कंपनी को आज या अगले महीने वहां जाना चाहिए।
यहोशू ड्रेक

3
@Zenon शब्द "तकनीकी ऋण" शायद ही नया है ...
एंड्रेस एफ।

5
+1: मैं हमेशा "तकनीकी ऋण" के सादृश्य की तरह हूं, जो हमारे पेशे में पूरी तरह से फिट बैठता है। आपको इसे शून्य नहीं करना है, लेकिन आपके पास जो भी बकाया है, उस पर आपको ब्याज देना होगा। हालाँकि, हमें याद रखना चाहिए कि यह सादृश्य आगे भी फैला हुआ है। लगभग हर व्यक्ति / कंपनी / देश पर बकाया ऋण है, इसलिए स्पष्ट रूप से ऋण उतना बुरा नहीं है जितना कि कुछ लोग इसे पूरा करते हैं। मैं एक ऐसा डेवलपर हूं, जो साफ-सुथरी कोडिंग प्रथाओं में बहुत विश्वास करता है, लेकिन मैं यह भी देखना शुरू कर रहा हूं कि प्रबंधन हमेशा गलत नहीं होता है और कभी-कभी सही समाधान एक और ऋण लेना होता है।
DXM

2
राष्ट्रीय ऋण के किसी भी स्तर की तरह, सबसे अच्छा समाधान यह है कि इसे अनदेखा करें और अगली पीढ़ी को गंदगी से निपटने के लिए छोड़ दें
गैरेथ

47

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

इसका क्लासिक आइसबर्ग सीक्रेट सब पर फिर से। रहस्य का इस तथ्य के साथ क्या करना है कि जिस तरह एक हिमखंड 90% पानी के भीतर है, उसी तरह किसी भी विकास परियोजना का बहुमत है : 90% काम पूरी तरह से अंतिम उपयोगकर्ता के लिए अदृश्य होने जा रहा है। उस कोड का अंत उपयोगकर्ता पर प्रभाव पड़ेगा , लेकिन प्रबंधन को उनके दिमाग को लपेटने में परेशानी होती है कि आपने छह घंटे क्यों बनाए रखे / जारी किए और स्वत: संदर्भित कॉल को फिर से भरने में बिताए जब वे कोई अंतर नहीं देख सकते हैं और सब कुछ ठीक काम कर रहा है।

इस मुद्दे पर कुछ तथ्य आप अपने साथ ले जा सकते हैं।

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

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


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

समस्या अज्ञानता जरूरी नहीं है। कभी-कभी किसी उत्पाद को बाज़ार में लाने, ग्राहक की ज़रूरतों को पूरा करने और भारी-भरकम बजट को पूरा करने का दबाव, उन मुद्दों से निपटने की ज़रूरत को पछाड़ देता है, जो अंततः तकनीकी ऋण में परिणत होंगे। अल्पावधि की जरूरत है कि बिलों का भुगतान हमेशा दूरदर्शी दीर्घकालिक आवश्यकताओं पर प्राथमिकता दी जाएगी जो निवेश पर तत्काल रिटर्न नहीं देगा। हम केवल इतना ही कर सकते हैं कि नश्वरता को धीरे-धीरे फैलाना है, और जब भी हम कर सकते हैं, समझदार रिफ्लेक्टरिंग को इंजेक्ट करने का प्रयास करते हैं, तो इस उम्मीद में कि हम तकनीकी ऋण के बोझ को कम कर सकते हैं, जिस तरह से बहुत अधिक योगदान किए बिना।
S.Robins

36

तुम नहीं।

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

मैं कहता हूं कि अपने अगले तकनीकी अनुमानों में अपने वांछित बदलावों को बेक करें। जैसे हो, अरे, हमें "इस नए ढांचे को अपग्रेड करना होगा जिसे Apple ने पेश किया था। एआरसी का उपयोग अपने रोडमैप पर न करें। कोई विकल्प नहीं हैं; एआरसी की ओर पलायन ही एकमात्र रास्ता है।


10
यह x100। यह हमेशा यह है कि यह कैसे काम करता है। अगर उन्हें समझ में नहीं आता है कि आप एक काम कर रहे कोडबेस को बकवास पर नहीं रख सकते हैं, तो वे कभी नहीं समझ पाएंगे। बस आगे बढ़ने और देखभाल करने के लिए पर्याप्त जगह खोजने के लिए सबसे अच्छा है।
वेन मोलिना

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

1
आप एक सोए हुए व्यक्ति को जगा सकते हैं, लेकिन आप एक ऐसे व्यक्ति को नहीं जगा सकते जो सोने का नाटक कर रहा है
ViSu

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

1
आप उन लोगों को बातें नहीं समझा सकते हैं जो सुन नहीं रहे हैं। आप सही कह रहे हैं कि संचार कौशल महत्वपूर्ण है, लेकिन यह दो तरह से सड़क है। संचार "कौशल" की कोई भी मात्रा रोग प्रबंधन से दूर नहीं होगी।
मार्क कैलास

28

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

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

मैं "अंकल" बॉब मार्टिन द्वारा क्लीन कोडर को पढ़ने का सुझाव दूंगा । अच्छा कोड लिखना आपकी नौकरी का हिस्सा है। आप अपना काम करने की अनुमति नहीं माँगते, आप बस करते हैं।


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

7

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

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

सौभाग्य!


6
मैं यह जोड़ना चाहूंगा कि न केवल एंड-यूज़र को क्रैश दिखाई दे रहे हैं , बल्कि वे उपयोगकर्ताओं को दूर भी चला रहे हैं । यह अच्छी तरह से विपणन उद्योग है कि में जाना जाता है जिस तरह से कठिन पिछले एक ग्राहक वापस जीतने के लिए की तुलना में यह मौजूदा रखने के लिए है। आप मौजूदा लोगों को कैसे बनाए रखेंगे? सुनिश्चित करें कि वे काम का उपयोग करें!
cdeszaq

एक ठोस प्रस्तुति के लिए आपकी खोज में, यहां कुछ संदर्भ सामग्रियां हैं: en.wikipedia.org/wiki/Software_entropy , pragprog.com/the-pragmatic-programmer/extracts/software-entyy , codinghorror.com/blog/2009/02/02/ …
मैसी एबे

7

एक व्यावसायिक मामला प्रस्तुत करें

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

  • अग्रिम लागत क्या है?
  • चल रही लागत क्या है?
  • अनुमानित पैसे / समय की बचत क्या है और वे कहाँ से आते हैं?
  • ROI देखने से पहले हमें कितना समय लगेगा?

व्यवसाय का मामला करते समय आपको हमेशा डेटा के साथ अपना तर्क देना चाहिए।

  • वर्तमान में विकास में कितना समय लग रहा है और इसे कम या कम करने वाली समस्याओं से निपटना होगा?
  • आपको उन समस्याओं से संबंधित कितनी उपयोगकर्ता शिकायतें मिलेंगी जो इसे दूर या कम करेंगी?
  • इसके और क्या फायदे होंगे?

संख्याओं को पंक्तिबद्ध करें और इसे एक मोटा, लेकिन सरल समीकरण बनाएं। इसे करने में X का खर्च आएगा और इससे कंपनी Y को फायदा होगा।

नोट: अगर यह अकादमिक रूप से अच्छे विचार को लागू करने के लिए निषेधात्मक रूप से महंगा है तो आश्चर्यचकित न हों।


6

इस तरह का बदलाव रिफैक्टिंग श्रेणी में आता है। फुर्तीली दृष्टिकोण यह होगा कि आपको अनुमान लगाने वाली प्रत्येक कहानी में एएमपीईएल रिफैक्टरिंग समय को शामिल करना चाहिए और यही कारण है। इंजीनियरों के अलावा, कोई भी यह समझने वाला नहीं है कि आप ऐसा क्यों करना चाहते हैं और यह ठीक है, यह निर्धारित करना सही काम नहीं है कि यह कैसे सही तरीके से कोड किया जाए, यह आपका है।

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

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

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


5

आप उल्लेख करते हैं कि आप सौभाग्यशाली हैं कि आपके प्रबंधक और सीईओ दोनों प्रोग्रामर हैं। तो वे शायद है समझते हैं कि तकनीकी कर्ज है।

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

आपका काम यह सुनिश्चित करना है कि वे आपके द्वारा लिए गए किसी विशेष तकनीकी ऋण का भुगतान करने की लागत और लाभों को समझें। उनका काम यह तय करना है कि संसाधनों का सबसे अच्छा उपयोग इसे भुगतान करने में है या कुछ और करने में।

जिस तरह "छिपे" सामान को सुधारने के लाभों को देखने के लिए कोड के साथ शामिल नहीं होने वाले लोगों के लिए यह कठिन हो सकता है, प्रोग्रामर के लिए दृश्य कोड परिवर्तनों के लाभों को देखने के लिए कठिन हो सकता है जब लाभ कुछ क्षेत्रों के क्षेत्रों के लिए अर्जित होते हैं " डेवलपर्स से छिपा हुआ "।

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

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


2

शायद यह कोई जवाब नहीं है, लेकिन मैंने जो गलतियाँ की हैं, उसके आधार पर प्रतिक्रिया। इसके अलावा मैं यहाँ पढ़े जाने वाले कुछ दर्शनशास्त्रों से असहमत हूँ।

  • विश्वास है कि प्रोग्रामर सबसे अच्छा जानता है के बारे में बात मत करो।
  • ईमानदार हो। फिर से कारक के रूप में आप साथ जाते हैं, लेकिन झूठ और अपने स्वयं के प्रयोजनों के लिए पैड का अनुमान नहीं लगाते हैं।
  • आप कोड के स्वामी नहीं हैं। ऐसे कार्य न करें जो लीड द्वारा अनुमोदित न हों।
  • आप किसी चीज़ के बारे में सही हो सकते हैं; आप गलत हो सकते हैं ... लेकिन आपको वह करना चाहिए जो आप करने के लिए भुगतान कर रहे हैं।

लेकिन निश्चित रूप से चीजों को बेहतर बनाने पर दी गई उत्कृष्ट सलाह का पालन करें।


हाँ, यदि आप एक कोड-बंदर बनना चाहते हैं, तो आगे बढ़ें और वह करें जो आप सोचते हैं कि आपको "भुगतान" करना है। प्रोग्रामिंग क्या है के बारे में मिथकों को बनाए रखने के लिए धन्यवाद।
ज़ोरान पावलोविक

2

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

CEO (जिसके पास व्यावहारिक रूप से एक मोहक है) PHB को पसंद करता है क्योंकि PHB सुविधाएँ प्रदान करता है । हर स्प्रिंट वह गर्व से एक नया टिक-बॉक्स (थोड़ा अस्पष्ट रूप से, अस्पष्ट लेबल के साथ) प्रदर्शित करता है, एक स्पार्कली आइकन (अभी तक किसी भी वातावरण में काम नहीं कर रहा है, लेकिन Citrix पर 8-बिट रंग) और एक फॉर्म (जिसमें दौड़ की स्थिति के कारण यादृच्छिक क्रैश होता है) Bespoke xml वैरिएंट आधारित C ​​ने स्थानीय डेटाबेस को लागू किया है कि देव टीम पर किसी ने भी स्पर्श करने की हिम्मत नहीं की क्योंकि यह 10 साल पहले पुराने गार्ड देव किंवदंतियों में से एक द्वारा लिखा गया था और 5 अक्षरों के नामों के साथ मैक्रोज़ के साथ हर कार्य करता है, चाहे उसे 5 पत्रों की आवश्यकता हो या नहीं)।

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

PHB जानती है कि 6 महीने में, हुक द्वारा या बदमाश द्वारा, वह आवेदन में तीस या चालीस नई सुविधाएँ प्राप्त कर सकता है कि salespeople (जो जादूगर वे वास्तव में बेच रहे हैं दिया जाना चाहिए) का उपयोग नई खरीद और उन्नयन के लिए किया जा सकता है ।

हालांकि PHB को उसकी बकाया राशि देने के लिए: उन टिक-बॉक्स और फॉर्म की बिक्री के बिना अच्छी तरह से स्थिर या गिरावट हो सकती है, एक प्रतियोगी बाजार में हिस्सेदारी हासिल कर सकता है, और यह विकल्प से भी बदतर हो सकता है।

जो निष्कर्ष मैं आया हूं, वह यह है कि दलदल से बाहर निकलने का एकमात्र तरीका एक नए स्टार्ट-अप में काम करना है, कुछ लोगों के साथ जो आपके विज़न को साझा करते हैं कि सॉफ्टवेयर को कैसे किया जाना चाहिए और फिर उस दर्शन से चिपक जाता है (I अभी भी वहाँ काम कर रहा हूँ!


1

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


1

आप दोनों सही और गलत दोनों हैं, इसीलिए वे मुद्दे लंबे समय तक टिके रहते हैं और कठोर भावनाएँ पैदा करते हैं।

उपरोक्त कारणों को स्पष्ट रूप से क्यों कहा गया है: प्रबंधन पैसे में सोचता है; या इससे भी अधिक विशेष रूप से: राजस्व। उनके लिए कुछ ऐसा है, जिसकी लागत तो है, लेकिन ग्राहक के लिए कोई दृश्यता सीधे राजस्व को नहीं जोड़ती है, इसलिए यह एक बुरी योजना है।

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

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

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

आप इस मुद्दे को कैसे हल करेंगे? आप कई मुद्दों पर एक-दूसरे को अच्छी तरह से संवाद करते हैं और समझते हैं। यह ग्राहक की व्यस्तता और संतुष्टि पर सबसे अधिक ध्यान केंद्रित करेगा।

इस मुद्दे को एक स्थिर और भविष्य के सबूत के तरीके में हल करने के लिए किसी बात पर सहमत हों: पुराने कोड में बगफिक्सिंग की लागत को मापें। पुराने सॉफ्टवेयर के साथ काम करने में समय लगता है और नए कोडबेस के साथ यह कैसा होगा, इसका आकलन करें।

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

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

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


0

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

उसे मनाओ। उसे उसी तरह के तकनीकी सुधारों के कुछ छोटे उदाहरण बताएं जो आपने किए थे और परियोजनाओं को इसके लाभ।


0

आपको उन परिवर्तनों को एकमात्र तरीके से बेचना होगा जो प्रबंधन खरीदने के लिए तैयार है:

एक उपयोगकर्ता-सुविधा का पता लगाएं, ताकि प्रबंधन के पास बस उसे करने के लिए मजबूर हो, लेकिन कोड में कुछ निम्न-स्तरीय सुधारों के बिना करना असंभव होगा।


0

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

  1. क्लाइंट अनुरोध पर वितरित करने में कितना समय लगता है?
  2. जब आप कहते हैं कि क्या आप वितरित करेंगे?

अधिकांश के बजाय आप कहेंगे कि इसमें 6 सप्ताह लगेंगे और 5 से डिलीवर होगा कहना कि आप 3 में वितरित करेंगे लेकिन 4 लेंगे।

एक वर्तमान कोड आधार होना जो प्रबंधित करने और बढ़ाने में आसान है, आपको तेज़ी से वितरित करने और पूर्वानुमान बढ़ाने की अनुमति देता है। यदि आप बग फिक्स पर बहुत अधिक समय बिता रहे हैं, तो आपके पास नई सुविधाएँ जोड़ने के लिए कम संसाधन उपलब्ध हैं। कोड को ठीक करने में खर्च किए गए संसाधनों की मात्रा का मूल्यांकन करें और फीचर प्रोमिस पर आप कितने सही हैं। यह निर्धारित करने का एक तरीका है कि आपका वर्तमान कोड (आपके बॉस के दर्शन के तहत) बहुत महंगा है।


वास्तव में एक इंजीनियरिंग प्रबंधक को कोड और डिज़ाइन की सुदृढ़ता और व्यवसाय / ग्राहकों की ओर से एक उत्पाद प्रबंधक की लॉबी से संबंधित होना चाहिए। इस मामले में ऐसा लगता है कि उत्पाद पक्ष के लिए एक मजबूत पूर्वाग्रह के साथ दोनों प्रबंधक कर रहे हैं।
केविन

0

मैं आपको $ 2 बिलियन के अवसर के बारे में बताता हूं जो प्रबंधन की जड़ता के कारण हमारे हाथ से फिसल गया है।

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

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

उसी समय, यह महत्वपूर्ण है कि डेवलपर्स अपने क्षेत्रों में वर्तमान रखें, क्योंकि ऐसी प्रतियोगिता होगी जो आपको नहीं हराएगी।

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

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

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

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

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


0

सभी क्षेत्रों और उद्योगों में व्यापार की आम भाषा पैसा है। आप जिस समस्या का वर्णन कर रहे हैं वह प्रोग्रामिंग समस्या नहीं है: यह एक व्यावसायिक समस्या है। यदि आप एक व्यवसाय प्रस्ताव को उचित प्रतिक्रिया प्राप्त करना चाहते हैं तो आपको इसे व्यवसाय की भाषा में फ्रेम करना होगा। इसका मतलब यह है कि आपको सभी लागतों और लाभों सहित वैकल्पिक परियोजना की योजना पेश करने में सक्षम होना चाहिए।

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


0

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

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

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

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

सौभाग्य!


-1

यहां बताया गया है कि स्वचालित संदर्भ गणना के लिए आपका अनुरोध अस्वीकार क्यों किया जा रहा है:

  1. यह कोई सुधार नहीं है । एक बार आपके पास हैलो दुनिया से बड़ा कुछ भी हो, कोई भी बदलाव गलत दिशा में जा रहा है। कोई भी रिफैक्टिंग की मात्रा इस तथ्य को बदलने वाली नहीं है कि यदि आपको बदलाव करने की आवश्यकता है, तो यह हमेशा गलत दिशा में जा रहा है। चाल यह जानना है कि आपके परिवर्तन कब पर्याप्त हैं कि यह अभी भी नए मुद्दों को पैदा करने के जोखिम के लायक है। आपके प्रबंधन ने स्पष्ट रूप से कहा है कि यदि अंतिम उपयोगकर्ता इसे नहीं देख सकते हैं, तो यह जोखिम के लायक नहीं है।
  2. संदर्भ गिनती पूरी तरह से पागल विशेषता है। आपने कुछ मौजूदा बड़ी प्रसिद्ध कंपनी को कुछ सुविधा को लागू करते हुए देखा, और तुरंत सोचा कि आपको उसी सुविधा की आवश्यकता है। खैर, यह बहुत संभावना है कि आपका कोडबेस सेब के उपयोग से पूरी तरह से अलग है। संभवतः संदर्भ गणना काम नहीं कर रही है, या यह सिर्फ समय की बर्बादी है। आपको एक अलग तरीका खोजना चाहिए जिससे आपके कोड में हर जगह संदर्भ गणना प्राइमिटिव्स को फैलाने की आवश्यकता न हो। संभवत: आपकी रिफ़काउंटिंग योजना को कोडबेस में हजारों संशोधनों की आवश्यकता होती है, उन परिवर्तनों में से अधिकांश आवश्यक नहीं हैं। बस समय और पैसे की बर्बादी।
  3. आप गलत समस्या हल कर रहे हैं। प्रबंधन आमतौर पर जानता है कि सिस्टम में किस तरह की समस्याएं हैं। कुछ अप्रासंगिक स्मृति रिसाव समस्या जो समाधान को हल कर रही है, उनमें से एक नहीं है। वास्तविक समस्याओं पर ध्यान दें और कुछ काल्पनिक समस्याओं के साथ नहीं जो कंप्यूटर स्मृति को संभालती हैं।
  4. इसे लागू करने में बहुत लंबा समय लगता है Apple कुछ प्रोग्रामर और कुछ प्रबंधकों के साथ आपकी तुच्छ टीम की तुलना में थोड़ी बड़ी कंपनी है। वे सिर्फ कीमत चुकाकर बड़े बदलाव कर सकते हैं। अगर कुछ को लागू करने में कुछ लाखों लगते हैं, तो यह मूंगफली है। अगर छोटी कंपनियां भी ऐसा ही करने की कोशिश करती हैं, तो वे तेजी से पैसा निकाल सकते हैं। सॉफ्टवेयर विकास पहले से ही बहुत महंगा है; अनावश्यक लागतों को जोड़ने से कोई मदद नहीं मिलेगी। स्मृति प्रबंधन जैसी एक अप्रासंगिक विशेषता फ्लडगेट को खोलने जा रही है: जब वे इसे मंजूरी देते हैं, तो आपके आधे प्रोग्रामर चाहते हैं कि उनका "सुधार" लागू हो। यह कभी भी कहानी नहीं है और कंपनी इसके बजाय कुछ उपयोगी कर सकती है।

यहाँ कुछ कदम आप समस्या को संभालने के लिए उपयोग कर सकते हैं:

  1. सुविधा को गिरा दो
  2. पता करें कि वास्तविक समस्या क्या है
  3. कुछ उपयोगी करना शुरू करें
  4. ध्यान से योजना बनाएं कि आप अपने समय का उपयोग कैसे करते हैं
  5. पता करें कि आपके सुधार पैसे में कैसे ला रहे हैं
  6. केवल उन सुविधाओं को चुनें जो सबसे अधिक धन लाती हैं
  7. यह महसूस करें कि सॉफ्टवेयर विकास का प्रोग्रामिंग पहलू पूरे सिस्टम का केवल एक छोटा सा हिस्सा है - इसमें सुधार कभी भी समय के लायक नहीं होगा
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.