कैसे "कस्टम सॉफ्टवेयर कंपनियों" तकनीकी ऋण के साथ सौदा करते हैं?


20

"कस्टम सॉफ़्टवेयर कंपनियां" क्या हैं?

"कस्टम सॉफ़्टवेयर कंपनियों" से मेरा अभिप्राय उन कंपनियों से है जो मुख्य रूप से कस्टम, वन ऑफ़, सॉफ्टवेयर के बिट्स के निर्माण से अपना पैसा कमाती हैं। उदाहरण एजेंसियां ​​या मध्य-वेयर कंपनियां या ठेकेदार / सलाहकार जैसे Redify हैं

"कस्टम सॉफ़्टवेयर कंपनियों" के विपरीत क्या है?

उपरोक्त व्यवसाय मॉडल के विपरीत वे कंपनियां हैं जो दीर्घकालिक उत्पादों पर ध्यान केंद्रित करती हैं, चाहे वे तैनाती योग्य डेस्कटॉप / मोबाइल एप्लिकेशन या सास सॉफ़्टवेयर हों।

तकनीकी ऋण के निर्माण का एक निश्चित तरीका:

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

यह तकनीकी ऋण को खत्म करने का एक निश्चित तरीका है। अब हमारे पास सॉफ्टवेयर का एक सा हिस्सा है जो हमारे मुख्य उत्पाद में कुछ भी नहीं जोड़ता है।

यदि कस्टम काम तकनीकी ऋण के निर्माण के लिए एक निश्चित आग तरीका है, तो एजेंसियां ​​इसे कैसे संभालती हैं?

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


5
मुझे यह कहने का तीव्र आग्रह क्यों है, "बुरी तरह से"?
HLGEM

5
क्या यह तकनीकी ऋण या फीचर क्रीप और वन-क्लाइंट-ओनली सॉफ्टवेयर के बारे में प्रश्न है? तकनीकी ऋण बुरी प्रथाओं का योग है जो आपको बाद में वापस करने के लिए आते हैं। फ़ीचर क्रीप और वन-क्लाइंट-ओनली सॉफ़्टवेयर एक अलग तरह का प्रबंधन बुरा सपना है।
फिल

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

3
एक ग्राहक के दृष्टिकोण से, अनुभव ने संकेत दिया है कि अधिकांश कस्टम दुकानें दृढ़ता से आपको खराब तकनीकी ऋण को रैक करने के लिए प्रोत्साहित करती हैं ताकि आप उन्हें नए, अलग-अलग तकनीकी ऋणों को फिर से बनाने के लिए कॉल कर सकें।
व्यट बार्नेट

2
@WyattBarnett एक कस्टम शॉप के नजरिए से: कई ग्राहकों को तकनीकी ऋण की खराब समझ है, और उन्हें केवल घर्षण के बारे में शिक्षित करने का प्रयास किया जाता है। वे प्रभावी रूप से जोर देते हैं कि आप पेशेवरों और विपक्ष पर चर्चा किए बिना, तकनीकी ऋण को रैक करने में उनकी मदद करते हैं।
MarkJ

जवाबों:


13

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

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

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

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

बहुत सारे स्वचालित परीक्षणों के साथ मॉड्यूलर कोड होने से आपको अपने उत्पाद में सुविधाओं को हैक करने और उन्हें फिर से हैक करने में मदद मिलेगी, लेकिन अंततः यह एक प्रोग्रामिंग सवाल नहीं है, बल्कि एक प्रबंधन है। बिक्री करने के लिए कोड लिखना मूर्ख का खेल है।


+1 महान उत्तर dslh, यह वास्तव में हमारे द्वारा किए जाने वाले संशोधनों या हैक के प्रकार के लिए है। मुझे एक्सपायरी आइडिया पसंद है ... वाकई दिलचस्प।
एंडी

+1 उन छोटी-छोटी विशेषताओं को हासिल करने में कोई समस्या नहीं है जिनका समर्थन किया जाना है, जब तक कि ग्राहक फीचर + समर्थन के लिए भुगतान करता है। क्षमा करें, हम आपकी सुविधा का समर्थन मुफ्त में नहीं कर सकते ...
फिल

18

जब मुझे कस्टम विकास अनुरोधों का सामना करना पड़ता है तो मैं उन्हें शांत फिल्टर के माध्यम से फ़िल्टर करता हूं जो 3 बवासीर में अनुरोधों को विभाजित करता है:

  1. भयानक चीजें जो सभी के लिए उपयोगी होंगी और जिन्हें लागू करना अपेक्षाकृत आसान है
  2. भयानक चीजें जो सभी के लिए उपयोगी होंगी और जिन्हें लागू करना कठिन है
  3. बेवकूफ़ चीजों में से जो केवल इस एक ग्राहक के लिए आवश्यक हैं, जो वास्तव में उन्हें किसी भी तरह की आवश्यकता नहीं है
  • श्रेणी 1 को वर्तमान देव चक्र में लागू किया जाता है।
  • श्रेणी 2 अगले देव चक्र में लागू हो जाती है।
  • श्रेणी 3 को देव समय के 1 आदमी महीने का एक उद्धरण मिलता है जिसके बाद अधिकांश ग्राहकों को पता चलता है कि उनका अनुरोध इसके लायक नहीं है।

ईमानदारी से, यह कभी विफल नहीं हुआ और मुझे नहीं लगता कि हमने श्रेणी 3 में से किसी भी सुविधा को लागू करना समाप्त कर दिया है। और निश्चित रूप से कोई भी ग्राहक नहीं चला (बिक्री ने मुझे इसे अन्यथा नहीं खींचने दिया :)

(यह अनुभव एक आईएसवी कंपनी में था)


दिलचस्प एमके। हालांकि मुझे यकीन नहीं है कि 3 संभावित नए ग्राहक के साथ उड़ान भरेंगे, लेकिन संभवतः मौजूदा ग्राहक के साथ काम करेंगे। कोई भी कम, बहुत दिलचस्प नहीं।
एंडी

6
1 आदमी महीना? आपके पास बहुत छोटे फीचर अनुरोध वाले ग्राहक होने चाहिए!
जॉन बी

@ जॉन हां, ठीक है, या तो वह या उत्पाद पहले से ही बहुत लचीला था।
एमके 01

6
@ जॉन आप कह रहे हैं कि आदमी-महीना एक मिथक है?
अष्टकूट

2
@ मुझे लगता है कि अन्य लोग संदर्भ से चूक गए :-)
अर्नोल्ड जोकस

12

कुछ बाधाओं के कारण हम कभी-कभी कुछ ग्राहकों की इच्छा के आगे झुक जाते हैं और हम कस्टम सॉफ्टवेयर के बिट्स का निर्माण करते हैं जो केवल उस ग्राहक के लिए उपयोग किया जा सकता है।

आपकी समस्या यह नहीं है कि आप केवल एक क्लाइंट के लिए उपयोग किए जाने वाले कोड बना रहे हैं। समस्या यह है कि आप उस कोड को शामिल कर रहे हैं जो केवल एक ग्राहक के लिए एक उत्पाद में उपयोग किया जाता है जिसे आप कई अन्य ग्राहकों को बेच रहे हैं जिन्हें उस कार्यक्षमता की आवश्यकता नहीं है।

जिन कंपनियों के पास अपने व्यवसाय मॉडल के केंद्र के रूप में एक मुख्य उत्पाद नहीं है, वे अच्छी तरह से हमेशा कस्टम सॉफ्टवेयर काम कर रहे हैं। वे तकनीकी ऋण की धारणा का सामना कैसे करते हैं? यह उन्हें तकनीकी दिवालिएपन में कैसे नहीं चलाता है?

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

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


3

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

उदाहरण के लिए, मान लें कि आपके पास एक डिलिबल था जो एक आंतरिक वेब एप्लिकेशन था जिसे आपके ग्राहक इंट्रानेट पर इंस्टॉल करेंगे। एक दिन, एक ग्राहक आता है और आपकी कंपनी तक पैसे से भरे एक डंप ट्रक को ड्राइव करने की पेशकश करता है यदि आप उनके लिए एक संस्करण बनाएंगे जिसमें ब्राउज़र इंटरफ़ेस के बजाय "समृद्ध क्लाइंट" डेस्कटॉप एप्लिकेशन है। ठीक है, यदि आपका सिस्टम अच्छी तरह से आर्किटेक्चर में है और आपकी निर्भरता अच्छी तरह से प्रबंधित है, तो यह केवल एक नया प्रस्तुति घटक बनाते समय डोमेन, डेटा एक्सेस और सेवा घटकों के पुन: उपयोग करने का मामला है। तकनीकी ऋण एक विचार नहीं है, भले ही आपके पास केवल एक ग्राहक है जो 1999 में वापस लौटना चाहता है और इसके लिए एक डेस्कटॉप एप्लिकेशन है।


1

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

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

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

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

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

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


+1 उत्तर S.Robins के माध्यम से धन्यवाद। मुझे लगता है कि मैं जो मुख्य बिंदु बनाने की कोशिश कर रहा था, वह यह है कि यदि आप अल्पकालिक लक्ष्य के लिए कुछ बनाते हैं, लेकिन आप समय के साथ उस उत्पाद का समर्थन करने के लिए तैयार नहीं हैं, तो आपने हर बार से तकनीकी ऋण लिया है उन उत्पादों को समर्थन की आवश्यकता होती है, आपको, एक कंपनी के रूप में, तैयार नहीं किया जाएगा, और फिर आपको किसी चीज़ को ठीक करने के लिए मुख्य उत्पाद टीम के सदस्यों को ले जाना होगा जो कोई भी अब के लिए भुगतान नहीं कर रहा है।
एंडी

0

कस्टम सॉफ्टवेयर तकनीकी ऋण की गारंटी नहीं है, लेकिन दो स्वामी की सेवा है।

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.