सॉफ़्टवेयर ख़रीदना

कस्टम सॉफ़्टवेयर की लागत क्या है, और वास्तव में यह आँकड़ा क्या तय करता है

एक ही ब्रीफ़ के कोटेशन आम तौर पर पाँच गुने तक भिन्न होते हैं। ऐसा इसलिए नहीं कि कोई अधिक वसूल रहा है — आमतौर पर इसलिए कि वे अलग-अलग चीज़ों का मूल्य बता रहे हैं।

9 मिनट का पाठ Plexowave

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

एक ही ब्रीफ़ पर इतने अलग-अलग कोटेशन क्यों आते हैं

तीन कारण, और उनमें से केवल एक दरों के बारे में है।

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

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

तीसरा है दर, और तीनों में यह सबसे कम मायने रखता है। आधी दर पर काम करने वाली टीम जो तीन गुना समय लेती है, सस्ती नहीं है, और जिस निर्माण को दोबारा करना पड़े वह किसी भी दर पर सस्ता नहीं।

वे सात बातें जो इस आँकड़े को सबसे अधिक बदलती हैं

  1. अलग-अलग यूज़र भूमिकाओं की संख्याहर भूमिका स्क्रीन, अनुमतियों और परीक्षणों का अलग समूह है। एक भूमिका वाला सिस्टम पाँच भूमिकाओं वाले उसी सिस्टम का एक अंश है, भले ही अंतर्निहित डेटा एक जैसा हो। यह आमतौर पर सबसे बड़ा कारक है और ब्रीफ़ में लगभग हमेशा कम आँका जाता है।
  2. इंटीग्रेशन, और उन पर नियंत्रण किसका हैप्रलेखित आधुनिक API वाला इंटीग्रेशन पूर्वानुमेय काम है। लेगेसी सिस्टम, अप्रलेखित डेटाबेस, ऐसे विक्रेता जिससे समय तय करना पड़े, या बिना API वाले पोर्टल का इंटीग्रेशन प्रोजेक्ट का सबसे अप्रत्याशित काम है। एक ही नाम के दो इंटीग्रेशन दस गुना भिन्न हो सकते हैं।
  3. डेटा माइग्रेशनएक सिस्टम से साफ़ डेटा माइग्रेट करना सामान्य काम है। असंगत कोड, दोहराए गए पक्षों और ऐसे अपवादों वाली दशक भर की स्प्रेडशीट माइग्रेट करना जिन्हें कोई याद नहीं रखता, पुरातत्व का काम है। मेहनत अपवादों में है, और जब तक कोई देखे नहीं, किसी को नहीं पता वे कितने हैं।
  4. ऑफ़लाइन और मोबाइल आवश्यकताएँ'यह फ़ोन पर भी चलना चाहिए' का अर्थ रेस्पॉन्सिव लेआउट हो सकता है, जो लगभग मुफ़्त है, या सिंक कॉन्फ़्लिक्ट मॉडल वाला ऑफ़लाइन-सक्षम ऐप, जो अपने आप में एक प्रोजेक्ट है। ये एक ही वाक्य में लिखे जाते हैं और इनकी क़ीमत बहुत अलग होती है।
  5. अनुपालन और ऑडिट आवश्यकताएँवैधानिक रिपोर्टिंग, ऑडिट ट्रेल, डेटा रेज़िडेंसी, प्रतिधारण नियम और एक्सेस लॉगिंग वास्तविक इंजीनियरिंग हैं, काग़ज़ी काम नहीं। ये आर्किटेक्चर को भी बाँधते हैं, यानी देर से पता चलने पर ये शुरू में ज्ञात होने की तुलना में कहीं अधिक महँगे पड़ते हैं।
  6. आवश्यकताएँ कितनी बदलेंगीयह ख़ामी नहीं — एक गुण है। यदि क्षेत्र अच्छी तरह समझा गया और स्थिर है, तो निश्चित दायरा संभव है। यदि आप वाक़ई कुछ नया बना रहे हैं, तो दायरा बदलेगा, और फ़िक्स्ड-प्राइस अनुबंध या तो उसे ढकने के लिए बढ़ाया जाएगा या झगड़ा पैदा करेगा। दोनों इसे पहले ही ईमानदारी से मान लेने से बदतर हैं।
  7. परफ़ॉर्मेंस और स्केल, यदि वाक़ई ज़रूरी होअधिकांश व्यावसायिक सिस्टम पर भार मामूली होता है और उन्हें ऐसे नहीं बनाना चाहिए मानो नहीं है। पर यदि आपको वास्तविक समवर्तीता, बड़े डेटा आयतन या सख़्त प्रतिक्रिया समय चाहिए, तो यह आर्किटेक्चर, इन्फ़्रास्ट्रक्चर और परीक्षण है — और यह पहले डिज़ाइन निर्णय से पहले पता होना चाहिए।

किन बातों से यह आँकड़ा उतना नहीं बदलता जितना लोग सोचते हैं

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

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

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

ऐसा अनुमान कैसे लें जिस पर भरोसा किया जा सके

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

फ़िक्स्ड प्राइस, टाइम ऐंड मटीरियल्स, या कैप्ड

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

टाइम ऐंड मटीरियल्स खोजपरक काम के लिए उपयुक्त है और तब ईमानदार मॉडल है जब दायरा बदलेगा, पर इसके लिए भरोसा चाहिए और जब तक आप स्वयं कोई सीमा न लगाएँ, इसमें कोई ऊपरी सीमा नहीं।

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

सबसे सस्ती महँगी ग़लती

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

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

सवाल

आम सवाल।

आप अपनी वेबसाइट पर मूल्य सीमा क्यों नहीं बताते?

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

क्या डिस्कवरी के लिए शुल्क लेते हैं?

एक शुरुआती बातचीत और उच्च-स्तरीय अनुमान निःशुल्क है। एक उचित डिस्कवरी — आपकी टीम के साथ बैठना, आपके वास्तविक दस्तावेज़ पढ़ना, विनिर्देश और पक्का अनुमान तैयार करना — शुल्क योग्य काम है, और उसका परिणाम आपका है चाहे आप हमारे साथ आगे बढ़ें या नहीं।

लॉन्च के बाद कितने चालू ख़र्च का बजट रखें?

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

हमारे लिए प्रति घंटा दर बेहतर है या प्रोजेक्ट मूल्य?

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

इसी निर्णय पर काम कर रहे हैं?

समाधान के बजाय समस्या बताइए। यदि उत्तर कोई ऐसा उत्पाद है जिसे आप ख़रीद सकते हैं, या कोई सॉफ़्टवेयर ही नहीं, तो हम वही कहेंगे।

प्रोजेक्ट शुरू करें