2010-01-20 11 views
5

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

हम एक सीएमएस प्रणाली बेचते हैं, इस प्रणाली के साथ हम कुछ उप-उत्पादों को बनाने के

  • वेबसाइटें
  • प्रस्ताव प्रजापति
  • मार्केटिंग अभियान ट्रैकर

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

कृपया सलाह,

भू


सभी को धन्यवाद! मैं वास्तव में इस विषय पर आपकी टिप्पणियों, राय और विचारों की सराहना करता हूं।

मैं नीचे

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

मैं आपको सभी प्रतिक्रियाओं को पढ़ने के दौरान उत्तर जोड़ना जारी रखूंगा।

+3

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

उत्तर

7

के बाद से आवेदन बहुत अच्छी तरह से architected है आप नहीं यह रिटायर करने के लिए कर सकते हैं और ढीली सभी निवेश आप तारीख को बनाया है।

यहाँ मेरी सुझाव हैं:

  • एक जूनियर डेवलपर इस वर्तमान डेवलपर शामिल हो लो।
  • डंप जूनियर डेवलपर पर भावी अपडेट के सबसे (एसआर की सहायता से। डेवलपर)
  • जूनियर डेवलपर पूछो अपने काम
  • की प्रलेखन करने के लिए सीनियर डेवलपर से पूछो की समीक्षा करने के प्रलेखन

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

नीचे Jefferey सुझाव के साथ इस समाधान का विस्तार ("कभी कभी पुनर्लेखन एक अच्छा निवेश है।")

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

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


अपने (जियो) के अनुसार टिप्पणी

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

  • सीएमएस
  • वेबसाइटों के लिए व्यावसायिक आवश्यकताएं
  • प्रस्ताव प्रजापति
  • मार्केटिंग अभियान ट्रैकर

यहाँ मेरी सुझाव

  • मॉड्यूल विस्तृत उपयोग के द्वारा मॉड्यूल बनाएं मामले दस्तावेज़ हैं इस पी के लिए roject। आपका डेवलपर ऐसा कर सकते हैं या उसी के लिए एक अलग व्यवसाय विश्लेषक के लिए आदर्श होगा।
  • अगर खुला स्रोत सीएमएस अपनी आवश्यकताओं (जैसे जूमला, Drupal, आदि) के सभी या सबसे संभाल कर सकते हैं का मूल्यांकन करने के एक वरिष्ठ डेवलपर किराया।
  • सबसे महत्वपूर्ण बात यह है कि यहां नई प्रणाली के लिए अपने मौजूदा डेटा को स्थानांतरित करने की क्षमता होगी। आप को अपने मौजूदा अनुबंध डेवलपर की ओर से मदद की जरूरत है ऐसा कर सकते हैं।
  • आप व्यापार प्रक्रिया या नए प्रणाली का उपयोग करने कार्यप्रवाह अद्यतन करने के लिए हो सकता है।
  • मॉड्यूल खुला स्रोत सीएमएस का उपयोग कर लागू नहीं किया जा सकता है कि आवश्यकता हो सकती है कस्टम वेबसाइट का उपयोग कर लागू किया जाना।

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

+0

+1: एक समझदार दृष्टिकोण। –

+0

अच्छा दृष्टिकोण, मेरे लिए वोट मिला। लेकिन यहां तक ​​कि अगर हमेशा के लिए प्रयोग योग्य है - शायद अवतार उद्धृत करने के लिए सिस्टम ने प्रगति की है, "सब कुछ बदलता है"। शायद एक ब्रांड नया डिजाइन जरूरी है? वर्तमान कोडबेस से अधिक लाभ प्राप्त करने के लिए रचनात्मक दृष्टिकोण के लिए – Anders

+1

+1। यह देखने के लिए पढ़ें - http://www.joelonsoftware.com/articles/fog0000000069.html –

2

आवेदन किसी भी प्रकार के दस्तावेज के बिना भेज दिए जाने के पल के अंत तक पहुंच गया। विकास शुरू करें, और आप उस व्यक्ति को बदलने पर विचार करना चाहेंगे जो मूल प्रणाली जानता है। अगर वे किसी भी तरह के दस्तावेज़ीकरण के बिना 6/7 साल गए हैं, तो वे आपकी कंपनी में कोई भी व्यक्ति नहीं चाहते हैं।

+1

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

+0

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

+1

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

0

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

3

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

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

+0

सहमत हैं। कभी-कभी किसी अन्य तकनीक में पूरी चीज को फिर से लिखना एक अच्छा निवेश है। –

1

एक लंबी कहानी कम करने के लिए: मैं तुलनीय स्थिति में हूं।

  • जब तक इस आवेदन एक cashcow की तरह कुछ है, लेकिन कंपनी को वहन नहीं कर सकते (या इरादा) एक नया आवेदन की विकसित करने के लिए इससे पहले कि ग्राहकों को एक नवसिखुआ प्रणाली खरीदने का निर्णय, तो वह मर नहीं होंगे।

  • बिना (दस्तावेज) आवश्यकताओं नए सिरे से लिखना लगभग असंभव है।

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

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

2

प्रलेखन का केवल प्रकार है जो आपके सिस्टम के जीवन स्वचालित रूप से विस्तार होगा चीजें हैं जो, अपने जीवनकाल में प्रणाली में परिवर्तन के रूप में लगातार रहने परीक्षण स्वीट, आत्म नैदानिक ​​उपकरण, कोड टिप्पणी की तरह, interfcaces तरह कथात्मक ठेके हैं, और उत्पन्न दस्तावेज।

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

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

0

ये बातें की तरह मैं यह निर्णय लेते समय अगर एक प्रणाली संभवतः जा रहे हैं "अंत का जीवन" विचार कर सकते हैं:

कार्यक्षमता है कि इस प्रणाली अंतिम उपयोगकर्ताओं को एक सस्ता, और अधिक में उपलब्ध प्रदान करता है उपयोग करने के लिए विश्वसनीय या आसान? यदि अब नहीं, तो यह कब संभव है? क्या यह उत्पाद लंबी अवधि में व्यवहार्य है?

क्या यह ऐसी तकनीक में लिखा गया है जो ग्राहक दूर हो जाएंगे क्योंकि यह उनके उत्पादों में इंटरफ़ेस करने के लिए अजीब होगा, या उन्हें "अप्रचलित" प्लेटफ़ॉर्म चलाने की आवश्यकता होगी? क्या यह एक संभावित ग्राहक को इंप्रेशन देगा कि आपकी कंपनी महत्वपूर्ण समय के बाद है। वीबी 6 शायद 2010 में भी अभी भी ठीक है, लेकिन संभवतः Win16 संगतता की आवश्यकता नहीं है।

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

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

यदि यह समर्थित है, तो क्या विक्रेता आपको पुराने प्लेटफॉर्म का समर्थन करने के लिए प्रीमियम चार्ज कर रहे हैं? यदि अब नहीं, तो वे कितने समय से पहले करते हैं?

मौजूदा रुझानों का लाभ उठाने के लिए नई प्रौद्योगिकियों को एकीकृत करना कितना मुश्किल है जो आपको उपयोगकर्ताओं को प्रतिस्पर्धात्मक रखने के लिए समृद्ध कार्यक्षमता प्रदान करता है? क्या आप इसके बारे में परवाह करते हैं? इससे कोई फर्क नहीं पड़ता कि आप अनिवार्य रूप से बंद सिस्टम चला रहे हैं।

पूरे सिस्टम में व्यापक "शॉटगन" परिवर्तनों के बिना कार्यात्मक परिवर्तनों को जारी करना कितना मुश्किल है? यह वापस आता है कि कैसे मॉड्यूलर प्रणाली को पहले स्थान पर डिजाइन किया गया था। यदि आप इससे भी बदतर नहीं हैं कि आपके प्रतिस्पर्धियों को बाजार में सुविधाएं मिल रही हैं तो आप शायद ठीक हैं।

क्या प्रणाली को फिर से लिखकर की लागत होगा? इससे बिक्री राजस्व को बनाए रखने या बढ़ाने के लिए कितना सस्ता होगा? यह पूरी तरह से लिखने के लिए आर्थिक रूप से व्यवहार्य नहीं हो सकता है। यदि विकास मंच ध्वनि है तो आप केवल एक रिफैक्टरिंग दृष्टिकोण की कोशिश कर सकते हैं। यह वह जगह है जहां एक अच्छा परीक्षण-सूट और दस्तावेज मदद करता है।

0

मैं एक समान प्रक्रिया के माध्यम से चला गया। हमारे पास एक वेब ऐप था जो लगभग 8 वर्षों तक चला था। उस समय बहुत से रखरखाव किए गए थे, जिस तरह से हमने कल्पना नहीं की थी। हालांकि, कोर अच्छा था और यह अभी भी फैलाने में सक्षम था।

क्या हमें पर धक्का रखरखाव लागत था। सही कौशल सेट वाले लोगों को ढूंढना 8 साल पहले आसान था। आज, कोई भी उन वातावरण में काम नहीं करना चाहता; हमें भी नहीं :)

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

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

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

अंतिम कारक यह था कि हमारा ऐप मॉड्यूलर है। तो हम प्रत्येक वितरित करने योग्य के बीच डाउनटाइम/विश्लेषण अवधि के साथ लघु वितरण कार्यक्रमों के संयोजन के लिए पर्याप्त आकार में इसे छोटा करने में सक्षम थे। यह सुनिश्चित करता है कि हम हर स्तर पर सही रास्ते पर थे।

+0

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

संबंधित मुद्दे