कस्टम सॉफ़्टवेयर की लागत कितनी होती है? असल में कीमत किस बात पर निर्भर करती है

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

यह लेख आपको कीमत नहीं बताता, क्योंकि यहाँ छापा गया कोई भी आँकड़ा आपके प्रोजेक्ट के लिए गलत होगा। यह आपको वे बातें बताता है जो असल में लागत को घटाती-बढ़ाती हैं, ताकि अनुमान मिलने पर आप उसे परख सकें, और ऐसे चुनाव कर सकें जो नतीजे को नुकसान पहुँचाए बिना लागत घटाएँ।

"एक ही चीज़" के लिए दो कोटेशन इतने अलग क्यों हो सकते हैं

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

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

लागत के मुख्य कारण

1. दायरा: यह कितनी चीज़ें करता है

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

2. अनिश्चितता: समस्या कितनी अच्छी तरह समझी गई है

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

3. इंटीग्रेशन: यह कितने दूसरे सिस्टम से जुड़ता है

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

4. यूज़र, डेटा और परफ़ॉर्मेंस

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

5. प्लेटफ़ॉर्म और डिवाइस

डेस्कटॉप और फ़ोन के ब्राउज़र पर चलने वाला वेब एप्लिकेशन एक बात है। नेटिव Android और iOS ऐप, ऑफ़लाइन चलना, पुश नोटिफ़िकेशन और स्टोर पर प्रकाशन अलग बातें हैं। Flutter और React Native जैसे क्रॉस-प्लेटफ़ॉर्म टूल Android और iOS के बीच ज़्यादातर कोड साझा कर सकते हैं, इसीलिए वे बिज़नेस ऐप के लिए अक्सर समझदारी भरा चुनाव होते हैं, पर इनसे काम मुफ़्त नहीं हो जाता। तय करें कि आपके यूज़र के लिए कौन से प्लेटफ़ॉर्म सच में मायने रखते हैं।

6. गुणवत्ता, सुरक्षा और अनुपालन की अपेक्षाएँ

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

7. डेटा माइग्रेशन और मौजूदा सिस्टम

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

8. लॉन्च के बाद

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

ईमानदार अनुमान कैसा दिखता है

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

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

मूल्य घटाए बिना लागत कैसे कम करें

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

ईमानदार जवाब

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

IT Labs India में हम निःशुल्क प्रारंभिक परामर्श और लिखित अनुमान देते हैं, कोई प्रकाशित दर नहीं, क्योंकि सही संख्या हमारे द्वारा आपकी समस्या समझ लेने के बाद ही बनती है। यदि आप वह बातचीत शुरू करना चाहें, तो हमारी कस्टम सॉफ़्टवेयर डेवलपमेंट सेवा के बारे में और जान सकते हैं या संपर्क कर सकते हैं।