रिफैक्टरिंग के संभावित मूल्य को कैसे मापें

Question

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

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

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

एक बिक्री व्यक्ति 'एक महान नई सुविधा' जोड़ने का सुझाव देता है। कंपनी एक सूत्र का उपयोग करके अपने सुझाव के मूल्य को मापती है। अर्थात। यह एक्स देव-दिनों के काम की लागत पर टी वर्षों में कंपनी एफ मिलियन पाउंड कमाएगी

कंपनी एक सार्थक तरीके से रिफैक्टिंग प्रस्ताव की लागत कैसे ले सकती है? और किन परिस्थितियों में यह कंपनी के लिए सबसे लाभदायक विकल्प होने की संभावना है?

Comments

शिल्प कौशल का भुगतान

— gnat

ज़रुरी नहीं? यह डेवलपर के करियर के संदर्भ में भुगतान करने के बारे में है। मैं गैर-फ़ीचर कार्यों के व्यावसायिक मूल्य को मापने के बारे में पूछ रहा हूं

— इवान

नहीं। मेरे प्रश्न के बारे में आपको क्या लगता है कि इनमें से कोई एक डुप्लिकेट है?

— इवान

@ मुझे लगता है कि gnat "संभव डुप्लिकेट" चीज़ का उपयोग "लिंक करने के लिए करता है" आप भी "सवालों में दिलचस्पी ले सकते हैं

— बेन आरोनसन

"मज़बूती"? सॉफ्टवेयर का अनुमान लगाना बेहद मुश्किल है। : यह एक पढ़ा दें blog.hut8labs.com/coding-fast-and-slow.html । एक अनुवर्ती (नीचे से जुड़ा हुआ) पढ़ें, भी। आप जोखिम के दृष्टिकोण से इसे प्राप्त करने से बेहतर हैं । किसी अन्य तकनीकी ऋण को फिर से भरने या संभालने का जोखिम क्या है ; क्या जोखिम की नहीं तकनीकी कर्ज से निपटने? (ध्यान दें कि दूसरा हमेशा रखरखाव या शायद बग से संबंधित जोखिम होने वाला है।) इस तरह, आप व्यापार की वास्तविकताओं और विकल्पों को देते हैं; क्या वे कंपनी को जोखिम स्वीकार करना चाहते हैं।

— jpmc26

Answer 1

यह एक्स देव-दिनों के काम की लागत पर टी वर्षों में कंपनी एफ मिलियन पाउंड कमाएगी

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

जो कुछ भी लेकिन; आपका प्रश्न स्पष्ट है कि आप क्या देख रहे हैं:

मैं रीफैक्टरिंग के लिए एक व्यावसायिक मामला कैसे बना सकता हूं?

महसूस करने के लिए मुख्य बात यह है कि समय पैसे के बराबर है। आप सीधे "5 डेवलपर्स 2 सप्ताह = 80 घंटे * 5 डेवलपर्स * $ 50 / घंटा -> $ 20,000" पर जा सकते हैं और इससे व्यापारिक लोगों को समझ में आता है। स्मार्ट व्यवसाय के लोग ध्यान देंगे कि उन 5 डेवलपर्स को या तो भुगतान किया जा रहा है, जिसके साथ आप काउंटर करते हैं कि यह $ 20,000 का खर्च / बचत नहीं कर रहा है - यह सबसे अधिक लाभदायक तरीके से $ 20,000 का उपयोग कर रहा है। वैसे भी, सूची के साथ।

• दक्षता - संभवतः, आप VB6 की तुलना में C # के साथ अधिक सामान प्राप्त कर सकते हैं। बेहतर टूलींग, बेहतर पुस्तकालय, जो भी हो। नई तकनीकें पुरानी चीजों की तुलना में बेहतर होती हैं। यदि आप कम समय में सामान कर सकते हैं, तो इसका मतलब है कि आप कंपनी के पैसे बचा रहे हैं।
• ओवरहेड - कोडिंग केवल सॉफ्टवेयर की लागत नहीं है। विचार करें कि जब विंडोज 2020 सामने आता है तो क्या होता है। उस VB6 ऐप को प्राप्त करने में आप कितना समय और प्रयास लगा रहे हैं? C # ऐप की तुलना में कितना अधिक समय और प्रयास है? जो आपकी कंपनी के पैसे बचा रहा है।
• गुणवत्ता - संभवतः, आप VB6 की तुलना में C # में उच्च गुणवत्ता के साथ सामान प्राप्त कर सकते हैं (या एक क्लीनर आर्किटेक्चर के साथ, या जो कुछ भी आपका लक्ष्यीकरण लक्ष्य है)। उच्च गुणवत्ता का मतलब है कम कीड़े। कम बगों का मतलब उन बगों को ठीक करने में कम लागत है, उन मुद्दों को रखने के लिए कम ग्राहक समर्थन लागत, गुणवत्ता के मुद्दों के कारण कम ग्राहक हानि, गुणवत्ता के लिए प्रतिष्ठा में वृद्धि हुई बिक्री ... आपकी कंपनी के लिए सभी डॉलर।
• एचआर बचत - आइए तथ्यों का सामना करें: कोई भी उस चमकदार वीबी 6 ऐप के साथ काम नहीं करना चाहता है। इसका मतलब है कि अधिक लोगों को समय और पैसे के लिए अग्रणी कंपनी छोड़ देंगे उन्हें बदलने के लिए खर्च किया। इसका मतलब है कि नए कर्मचारियों को काम पर रखने में अधिक समय और पैसा लगता है। सबसे बुरी बात, इसका मतलब है कि आपके पास ऐसे डेवलपर होंगे जो उस वीबी 6 ऐप के साथ काम करने से पूरी तरह से ठीक करियर आत्महत्या कर रहे हैं। बदले में उन डेवलपर्स ने गुणवत्ता के मुद्दों की मृत्यु सर्पिल को तेज कर दिया। टर्नओवर काटने और काम पर रखने से आपकी कंपनी का पैसा बचता है। जटिल, भद्दा डेवलपर्स दूर रखने से आपकी कंपनी बच जाती है।
• मनोबल - इसी तरह, प्रोग्रामर जो पहले से ही वहां हैं उन्हें VB6 में काम करने से नफरत है। वे इसे करेंगे, और वे इसे अच्छी तरह से भी कर सकते हैं। लेकिन यह बेकार है। शायद सभी के लिए नहीं, लेकिन निश्चित रूप से कुछ के लिए। इसका मतलब है कि प्रेरणा को पुनः प्राप्त करने के लिए अधिक समय वेब ब्राउज़ करना। इसका मतलब है अब लंच। इसका मतलब यह है कि सामान कम हो रहा है जबकि आपके प्रोग्रामर को चूसने के काम से उबरने में अधिक समय लगता है।
• क्षमता - यह प्रौद्योगिकी संचालित रिफ्लेक्टर के साथ कम लागू होता है, लेकिन रिफ्लेक्टर के आर्किटेक्चर प्रकार पर लागू होता है। कुछ कोड समस्याएं सक्रिय रूप से आपको टन के पैसे बनाने के लिए शांत सुविधा एक्स प्रदान करने से रोकती हैं। शायद आप पैमाने नहीं कर सकते। हो सकता है कि आप डेटा को कूल इंफॉर्मेटिक्स करने के लिए प्राप्त न कर सकें। हो सकता है कि कोड एक ऐसे चूहे का घोंसला है जो वास्तव में काम करना निषिद्ध है। जो कुछ। कभी-कभी आप उस बिंदु पर होते हैं, कभी-कभी आप सीधे उस बिंदु की ओर बढ़ रहे होते हैं। व्यवसाय-बोलने में अनुवाद करना कठिन है, लेकिन यदि आप "यह समस्या हमें अवसरों का लाभ लेने से रोक रही है तो X, Y और Z" शक्तिशाली हो सकते हैं।

सब के सब, यह "यह सामान हमारे कामों को बेहतर ढंग से करने में हमारी मदद करेगा; यदि हम अपने कामों को बेहतर तरीके से करते हैं, तो हम आपको और अधिक पैसा कमा सकते हैं / बचा सकते हैं"।

Comments

"किन परिस्थितियों में सबसे अधिक लाभदायक होने की संभावना है" पर कोई विचार? ऐसा लगता है कि यदि आप पूरी तरह से कम लागत के संदर्भ में लाभ को परिभाषित करते हैं तो आप देव टीम की कुल लागत पर अधिकतम लाभ प्राप्त करेंगे। नए फीचर X के कारण 'बड़े पैमाने पर बिक्री में गिरावट' के कारण '10% बिक्री बढ़ने की संभावना है '

— इवान

@ ईवन - '10% बिक्री में वृद्धि 'बहुत अच्छी नहीं है अगर यह लागत में बराबर वृद्धि के साथ है। '10% बिक्री में वृद्धि' मदद नहीं करता है अगर यह 6 महीने है जब आपका प्रतियोगी बाजार में जाता है और आप पर हावी हो जाता है (ताकि आपको बिक्री में -10% वृद्धि हो जाए)। कभी कभी सुविधाओं कर रहे हैं और अधिक महत्वपूर्ण है, लेकिन बिक्री में '% अधिक बार '10 नहीं की तुलना में वृद्धि सिर्फ गंदगी अप कर रही है।

— तेलस्टिन

VB6 को रखने के लिए एक व्यावसायिक जोखिम भी है: Microsoft ने VB6 का पूर्ण समर्थन वर्षों पहले छोड़ दिया था और तब से "इट जस्ट वर्क्स" सपोर्ट पर सिमट रहा है। बिल्ड वातावरण XP की तुलना में कुछ भी नया नहीं चलेगा, और रनटाइम विंडोज के किसी भी भविष्य के संस्करण में काम करना बंद कर सकता है। उदाहरण के लिए, अभी तक एक औपचारिक घोषणा नहीं हुई है कि VB6 विंडोज 10. पर समर्थित है

— Dan Lyons

सभी उदाहरण काल्पनिक हैं, वास्तविक कंपनियों के लिए कोई समानता विशुद्ध रूप से संयोग है ....

— इवान

Answer 2

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

मेरे अनुभव के अनुसार, सेल्सपर्सन आमतौर पर अनुमान नहीं लगाते हैं, लेकिन प्रबंधन या ग्राहक के लिए कितना अधिक है , इसके बारे में अनुमान लगाता है : यदि प्रबंधन 50 मानव-सप्ताह के काम का भुगतान करने के लिए तैयार है, लेकिन 75 मानव-सप्ताह को पूरी तरह से अस्वीकार कर देगा, आइए बताते हैं उस सुविधा 70 मानव सप्ताह का समय लग जाएगा, जबकि तैयार किया जा रहा है फिर से बातचीत (कुछ है जो एक वास्तविक आकलन के लिए सवाल से बाहर है) 55 मानव सप्ताह के लिए नीचे।

• एक तरफ, आपके पास आईटी विशेषज्ञों द्वारा किए गए अनुमान हैं जो कुछ बता रहे हैं:

  इस विशिष्ट ऑडिट के अनुसार, हम समान आकार की समान परियोजनाओं की तुलना में एक पुरानी तकनीक का उपयोग करके प्रति दिन $ 8 000 बर्बाद कर रहे हैं जो नई तकनीकों का उपयोग करते हैं। यह भी प्रतीत होता है कि पूरे कोड आधार को स्थानांतरित करने में 50 से 80 मानव-सप्ताह लगेंगे; इस समय के दौरान, कोई नई सुविधाएँ जारी नहीं की जाएंगी। 10% जोखिम यह भी है कि एक विशिष्ट घटक को स्थानांतरित करने के परिणामस्वरूप 20-30 अतिरिक्त मानव-सप्ताह का काम हो सकता है।

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

यह सब आपकी कंपनी में कितना प्रभावशाली है, इसके बारे में है। संचार यहाँ महत्वपूर्ण है, और यह वह जगह है जहाँ सेल्समैन आमतौर पर आईटी पेशेवरों को जीतते हैं जब यह एक सुविधा के लाभों को प्रबंधन (या एक ग्राहक) को समझाने के लिए आता है।

ध्यान दें कि यदि अतीत में, आपके अनुमान काफी सटीक थे, तो आप प्रतिष्ठा और प्रभाव प्राप्त करते हैं। यदि आपके अनुमान हमेशा गलत थे, तो प्रबंधन शायद आपके प्रस्तावों की अनदेखी करेगा।

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

• क्या आप वास्तव में जानते हैं कि V # 6 की तुलना में C # में आपकी टीम कितनी निपुण है? क्या यह वास्तविक माप पर आधारित है या सिर्फ अनुमान है?

• क्या इस टीम ने C # में बड़े प्रोजेक्ट विकसित किए हैं? क्या वे उन उपकरणों को जानते हैं जो उन्हें (आईडीई, डीबगर्स, प्रोफाइलर, आदि) का उपयोग करना चाहिए। क्या आपको अतिरिक्त लाइसेंस की आवश्यकता है (जो, माइक्रोसॉफ्ट की दुनिया में, प्रति मशीन हजारों डॉलर का मतलब है)?

• क्या वर्तमान परियोजना पूरी तरह से स्पष्ट है और आप गारंटी दे सकते हैं कि पलायन करते समय कोई आश्चर्य नहीं होगा? क्या सब कुछ , हर सुविधा को फिर से लिखना सरल है , या आश्चर्य होगा?

• क्या आपके पास बुनियादी ढांचा है जो C # का समर्थन करता है? निरंतर एकीकरण के बारे में क्या? अपने बिल्ड सर्वर के बारे में क्या? शैली गाइड? स्टेटिक चेकर्स?

• उत्पादन में, सर्वर (यदि यह एक वेब ऐप है) या ग्राहक पीसी (यदि यह एक डेस्कटॉप ऐप है) तो .NET फ्रेमवर्क के संस्करण को चलाने में सक्षम हैं जिसका आप उपयोग करने की उम्मीद कर रहे हैं?

लेकिन सबसे महत्वपूर्ण बात यह जानना है कि आप सब कुछ फिर से क्यों लिखना चाहते हैं। वह समस्या क्या है जिसे आप एक पुनर्लेखन के माध्यम से हल करने का प्रयास कर रहे हैं? उत्पादकता का नुकसान? आप इसे कैसे मापेंगे? आप प्रबंधन को उत्पादकता के इस नुकसान को कैसे दिखाते हैं?

एक बार जब आप दिखाते हैं कि आप बर्बाद कर रहे हैं, तो कहें, VB6 के कारण प्रति दिन $ 8 000 (जिसका अर्थ है कि आप C # में माइग्रेट होने के बाद प्रति दिन $ 8 000 बचा लेंगे), आप हर नई सुविधाओं के विकास को रखने के लाभ की व्याख्या कैसे करते हैं और एक पूर्ण पुनर्लेखन पर ध्यान केंद्रित कर रहे हैं? प्रगतिशील पुनर्लेखन की तुलना में क्या लाभ है, जहां आप अपने घटकों को एक-एक करके छोटी-छोटी टुकड़ियों में स्थानांतरित करते हैं, जबकि नई सुविधाओं को शिपिंग करते हैं?

Comments

मेरा मतलब था कि बिक्री व्यक्ति उदाहरण केवल यह दिखाने के लिए कि उनके पास एक 'राशि' है जो पैसे में उनके प्रस्ताव के मूल्य को मापता है। देवता किस 'राशि' का उपयोग कर सकते हैं?

— इवान

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

— विंस ओ'सुल्लिवन

Answer 3

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

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

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

इन 2 नंबरों के साथ, आप पे बैक पीरियड का अनुमान लगा सकते हैं कि री-फैक्टरिंग आपको दे देगा यानी कि नेट-कॉस्ट से री-फैक्टरिंग किस मोड़ पर होगा।

मैं केवल अनुमान लगा सकता हूं कि किसी भी दिए गए परिणाम के लिए कितना प्रेरक होगा। हालांकि, अगर यह एक वर्ष से कम है, तो यह संभवतः काफी मजबूत होगा, 2 साल से ज्यादा तो आप अच्छी तरह से संघर्ष कर सकते हैं।

इसके अतिरिक्त, यह संभवतः आपके मामले को बनाने में मदद करने के लिए अन्य आयामों को जोड़ने के लायक है। एक जो मैंने अतीत में इस्तेमाल किया है वह देख रहा है कि क्या किसी भी निकास साक्षात्कार ने ड्राइवर के रूप में प्रौद्योगिकी का हवाला दिया। यदि ऐसा है, तो आप तर्क दे सकते हैं कि री-फैक्टरिंग स्टाफ को बनाए रखेगा (हायरिंग और ट्रेनिंग v महंगा होना)।

जाहिर है, आप बिना सबूत के समर्थन के इन बातों पर बहस कर सकते हैं, लेकिन मुझे लगता है कि इससे मामले के प्रभाव पर भारी फर्क पड़ सकता है।

Answer 4

रीफैक्टरिंग का मूल्य कई अलग-अलग तरीकों से सामने आता है।

यह आपको बाद में अन्य परिवर्तन करने में मदद करता है, इसलिए उस सुविधा को पूरा करने में X दिन अब 2 / 3X दिन लगेंगे। फुर्तीली शब्दावली का उपयोग करने के लिए यह वेग बढ़ाता है।

सूचीबद्ध स्पष्ट परिवर्तन समय के साथ मदद करेगा क्योंकि अब आपको VB6 अनुभव वाले डेवलपर्स को बनाए रखने की आवश्यकता नहीं होगी, केवल C # अनुभव वाले।

यह स्टाफ के प्रतिधारण और भर्ती जैसे अन्य कम मूर्त तरीकों में भी मदद करता है। क्या C # और VB6 करने वाली नौकरी, C # करने वाली नौकरी से कम या ज्यादा आकर्षक होगी? क्या आपके पास नौकरी लेने या कम कोड बेस या घटिया काम करने वाली नौकरी पर रहने की संभावना अधिक होगी?

Answer 5

मुझे लगता है कि अन्य उत्तरों को याद करने की बात यह है कि आपको खोए हुए राजस्व के खिलाफ रिफैक्टिंग की लागत को मापने की आवश्यकता है, न कि रिफैक्टरिंग से।

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

• अगर हम जो कर रहे हैं, उसे करते रहें, तो क्या हम किसी चीज़ को याद नहीं कर रहे हैं? वहाँ एक पुराने डिजाइन में जगह है कि हमें मूल्य से वापस पकड़ रहा है? उदाहरण के लिए, यदि हम एक विशेषता जोड़ना चाहते हैं तो क्या यह इतना मुश्किल है कि इसे लागू करने में 100 घंटे लग सकते हैं, बनाम रिफ्लेक्टर के लिए 50 घंटे और नए डिजाइन के खिलाफ लागू करने के लिए 25 घंटे?

• क्या मौजूदा कोड में तकनीकी ऋण है जो हमें पैसा खर्च कर रहा है? क्या यह भद्दा पुराना कोड बग्स का स्रोत है? क्या हम इसकी वजह से समस्याओं को ठीक करने के लिए मुफ्त में काम कर रहे हैं? कोई भी मुफ्त में आकर्षक बिल देने योग्य घंटे देना पसंद नहीं करता है।

• क्या रिफैक्टरिंग की लागत, रिफैक्टरिंग की लागत के बराबर या उससे कम है?

• क्या रॉकस्टार्स की एक छोटी टीम द्वारा कोड को परिशोधन के लिए लागत में संशोधन करना संभव है, जिससे सबसे अधिक समस्याएं हो सकती हैं? क्या हम रिफैक्टर को रिलीज के दौरान फैला सकते हैं? हर जगह छोटी अक्षमताएं हैं: क्या हम इस अतिरिक्त काम के साथ बात करने के लिए "अंतराल में भर सकते हैं"?

Answer 6

एक refactored प्रणाली होने के लाभ

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

रिफैक्टरिंग से प्रभावित प्रमुख बजट आइटम इस प्रकार हैं:

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

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

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

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

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

Answer 7

रिफैक्टरिंग के मूल्य को इस तरह मापा जा सकता है: वर्तमान में नई सुविधा x की कीमत 5 सप्ताह 2 सप्ताह होगी। यदि हम y पुराने घटक को रिफलेक्टर करते हैं, तो नई सुविधाओं की लागत अनुमानित 20% तक कम हो जाएगी। इसलिए नई सुविधा x में केवल 2 सप्ताह में 4 devs खर्च होंगे।

रिफैक्टरिंग भविष्य के विकास की लागत को कम करने के लिए एक निवेश है। यदि आप अपने रीफैक्टरिंग के लिए वह तर्क नहीं दे सकते हैं, तो शायद इसके लिए कोई व्यावसायिक मामला नहीं है।

Comments

मुझे लगता है कि आप सुविधाओं को सस्ता / तेज बनाने के महत्वपूर्ण बिंदु पर पहुंचे। मुझे लगता है कि यह संभावना लागत बचत की किसी भी राशि से अधिक मूल्य जोड़ती है

— इवान