जब आप सॉफ़्टवेयर बनवाते हैं, तो देर-सवेर आपसे पूछा जाता है कि आप उसके लिए भुगतान कैसे करना चाहते हैं। दो पारंपरिक जवाब हैं: पूरे प्रोजेक्ट के लिए तय कीमत, या काम होते समय समय और सामग्री के आधार पर भुगतान। दोनों को सुरक्षित विकल्प बताकर बेचा जाता है। गलत किस्म के प्रोजेक्ट पर इस्तेमाल करने पर दोनों बुरी तरह बिगड़ सकते हैं। मैंने कई सालों तक दोनों के तहत काम किया है, मेज़ के दोनों तरफ़ से, और सही सवाल पूछने पर सही चुनाव लगभग हमेशा साफ़ हो जाता है।
हर मॉडल असल में क्या है
तय दाम (Fixed price) का मतलब है कि सप्लायर एक तय दायरे का काम एक तय रक़म में देने को राज़ी होता है। काम अनुमान से ज़्यादा लंबा खिंचने का जोखिम सप्लायर पर रहता है। बदले में सप्लायर को दायरा साफ़ तय चाहिए, और वह उसमें बदलाव का विरोध करेगा।
टाइम और मटीरियल का मतलब है कि आप असल में लगे प्रयास का भुगतान करते हैं, आमतौर पर घंटे, दिन या महीने के हिसाब से, साथ में तीसरे पक्ष के लाइसेंस जैसे सीधे ख़र्च। काम ज़्यादा लंबा चलने का जोखिम आप पर रहता है। बदले में आपको लचीलापन मिलता है: आप दिशा बदल सकते हैं, फ़ीचर जोड़ सकते हैं और जो ज़रूरी नहीं निकले उन्हें छोड़ सकते हैं।
तीसरी व्यवस्था, समर्पित डेवलपर या मासिक एंगेजमेंट, टाइम और मटीरियल से काफ़ी मिलती-जुलती है: आप हर महीने डेवलपर के समय की एक तय मात्रा आरक्षित करते हैं और तय करते हैं कि उसका इस्तेमाल कैसे हो। इसे हमने अपने समर्पित डेवलपर पेज पर बताया है।
तय कीमत का वादा, और वह कहाँ टूटता है
तय दाम से सुकून मिलता है क्योंकि बजट में डालने के लिए एक संख्या मिल जाती है। यह सुकून तब असली होता है जब ये बातें सच हों:
- आवश्यकताएँ साफ़ हैं, लिखित हैं और बदलने की संभावना कम है।
- तकनीक जानी-पहचानी है और जोखिम कम हैं।
- आप पहले से बता सकते हैं कि आप कैसे तय करेंगे कि काम पूरा हो गया।
इन शर्तों में तय कीमत कारगर रहती है। सबको पता होता है कि क्या बन रहा है और उसकी कीमत क्या है।
परेशानी तब शुरू होती है जब ये शर्तें पूरी नहीं होतीं, जो आम बात है। सोचिए एक प्रोजेक्ट जिसकी आवश्यकताएँ धुँधली हैं। तय कीमत माँगे जाने पर सप्लायर के पास दो ईमानदार विकल्प होते हैं। वह अनजानी बातों को ढकने के लिए बड़ा मार्जिन जोड़ सकता है, जिसमें आप ऐसे जोखिम की कीमत चुकाते हैं जो शायद कभी आए ही नहीं। या वह कम कीमत बताए और फिर हर अस्पष्टता की सबसे संकरी व्याख्या करके खुद को बचाए। दोनों से तनाव पैदा होता है। आप इस बहस में उलझ जाते हैं कि कोई चीज़ "दायरे में" है या नहीं, जबकि बात इस पर होनी चाहिए कि वह उपयोगी है या नहीं।
एक शांत समस्या भी है। जब सप्लायर जोखिम उठा रहा होता है, तो ऐसी जगहों पर कटौती करने का स्वाभाविक प्रलोभन रहता है जो आपको आसानी से दिखती नहीं: कम टेस्टिंग, कमज़ोर दस्तावेज़, तेज़ पर कम टिकाऊ समाधान। अच्छे सप्लायर ऐसा नहीं करते, लेकिन अनुबंध की बनावट इसे लुभावना बना देती है, और यह जानना ज़रूरी है।
समय-और-सामग्री मॉडल का वादा, और वह कहाँ टूटता है
समय-और-सामग्री मॉडल सॉफ़्टवेयर के स्वभाव के बारे में ईमानदार है: समस्या की सबसे अच्छी समझ बनाते समय ही आती है। इससे आप जल्दी शुरू कर सकते हैं, असली उपयोग से सीख सकते हैं और बदलाव कर सकते हैं। जब विचार अभी बन ही रहा हो, तब इससे आमतौर पर बेहतर उत्पाद बनते हैं।
इसका जोखिम उलटा है। अनुशासन के बिना बजट की कोई सीमा नहीं होती और प्रोजेक्ट का कोई स्वाभाविक अंत नहीं। आपको भरोसा करना होगा कि सप्लायर कुशलता से काम करेगा और प्रगति के बारे में सच बताएगा। आपको प्राथमिकताएँ तय करके अपना हिस्सा भी निभाना होगा, क्योंकि आप जो भी फ़ीचर जोड़ते हैं उसकी लागत बढ़ती है।
आप सरल आदतों से इस जोखिम को काफ़ी कम कर सकते हैं:
- शुरू में एक अनुमानित सीमा तय करें और उसे योजना का आँकड़ा मानें, वादा नहीं।
- छोटे माइलस्टोन में काम करें, जिनके अंत में कुछ ऐसा हो जिसे आप देख और टेस्ट कर सकें।
- काम के हर हिस्से पर लगे समय की नियमित रिपोर्ट माँगें।
- एक समीक्षा बिंदु तय करें जहाँ आप तय करें कि जारी रखना है, दिशा बदलनी है या रुकना है।
- एक प्राथमिकता वाला बैकलॉग रखें, ताकि सबसे कीमती काम हमेशा पहले हो।
चुनने का एक आसान तरीक़ा
अपने प्रोजेक्ट के बारे में ख़ुद से ये सवाल पूछें।
आज मैं तैयार प्रोडक्ट का वर्णन कितनी अच्छी तरह कर सकता हूँ? अगर आप तीन सप्लायरों को एक लिखित स्पेसिफ़िकेशन देकर लगभग एक जैसे नतीजे की उम्मीद कर सकें, तो तय दाम ठीक है। अगर नहीं, तो ठीक नहीं।
मेरे अपना मन बदलने की कितनी संभावना है? ईमानदारी से सोचें। ज़्यादातर लोग चलता हुआ सॉफ़्टवेयर देखकर कुछ नया सीखते हैं। अगर आपको योजना बदलने की उम्मीद है, तो टाइम और मटीरियल मॉडल बेहतर बैठेगा।
तकनीक या समस्या कितनी नई है? अनजान क्षेत्र, जैसे कोई नया इंटीग्रेशन या कोई AI फ़ीचर, अपने साथ ऐसी अनिश्चितताएँ लाता है जिन्हें दाम में छिपाने के बजाय आपस में बाँटना बेहतर है।
काम कितना बड़ा है? छोटे, साफ़ सीमा वाले काम, जैसे कोई ख़ास रिपोर्ट, कोई सरल इंटीग्रेशन या कोई तय फ़िक्स, तय दाम पर ठीक रहते हैं। बड़े और लंबे प्रोग्राम को चरणों में बाँटना बेहतर है, हर चरण का अपना समझौता हो।
मेरे लिए बजट की निश्चितता, लचीलेपन से कितनी ज़रूरी है? कुछ संगठनों में ख़रीद के ऐसे नियम होते हैं जिनमें तय रक़म चाहिए। यह एक जायज़ शर्त है, और इसे पूरा करने के तरीक़े नीचे बताए गए हैं।
वे मिले-जुले तरीके जो आमतौर पर सबसे अच्छे चलते हैं
व्यवहार में सबसे अच्छी व्यवस्था अक्सर दोनों का मिश्रण होती है।
पहले सशुल्क डिस्कवरी, फिर तय दाम। एक छोटा सशुल्क चरण (एक-दो हफ़्ते) रखें जिसमें लिखित दायरा, प्रोटोटाइप या सबसे जोखिम भरे हिस्से को परखने वाला तकनीकी स्पाइक तैयार हो। फिर उसी दायरे के आधार पर बिल्ड का दाम तय करें। आप थोड़े, समय-सीमा वाले निवेश से निश्चितता ख़रीदते हैं।
हर माइलस्टोन का तय दाम। प्रोजेक्ट को चरणों में बाँटें, हर चरण का स्पष्ट डिलीवरेबल और तय दाम हो, और हर चरण पिछला चरण पूरा होने के बाद तय करें। आपको छोटे-छोटे क़दमों में अनुमान लगाने की सुविधा मिलती है और बीच में बदलाव की आज़ादी भी।
सीमा के साथ टाइम और मटीरियल। टाइम और मटीरियल पर काम करें, पर एक अधिकतम रक़म तय करें जो आपकी मंज़ूरी के बिना पार न हो। सप्लायर खुले-छोर वाले दायरे से और आप खुले-छोर वाले ख़र्च से सुरक्षित रहते हैं।
मासिक एंगेजमेंट। लगातार बदलाव वाले चालू प्रोडक्ट के लिए, तय डेवलपर समय की एक तय मासिक रक़म का बजट बनाना और चलाना आसान है।
बदलाव और अनुबंध उन्हें कैसे संभालते हैं
आप जो भी मॉडल चुनें, प्रोजेक्ट बदलेगा। अनुबंध में लिखा होना चाहिए कि कैसे। फ़िक्स्ड प्राइस में बदलाव के लिए लिखित प्रक्रिया होनी चाहिए: बदलाव बताएँ, उसका असर आँकें, मंज़ूरी दें, फिर आगे बढ़ें। टाइम एंड मटीरियल में बदलाव प्राथमिकताएँ दोबारा तय करके होते हैं, और सवाल बस यह रहता है कि कुल खर्च अब भी आपके बजट में आता है या नहीं। अगर अनुबंध बदलाव पर चुप है, तो मतभेद की उम्मीद रखें।
लिख लेने लायक और बातें
कीमत तय करने का मॉडल जो भी हो, पक्का कीजिए कि समझौते में कुछ ज़रूरी बातें शामिल हों:
- स्वामित्व। काम का भुगतान होने के बाद कोड और बौद्धिक संपदा (IP) आपकी होनी चाहिए, और कोड ऐसे रिपॉज़िटरी में रहे जो आपके नियंत्रण में हो।
- स्वीकृति। आप कैसे तय करेंगे कि कोई डिलीवरेबल पूरा हो गया? टेस्ट, डेमो या चेकलिस्ट से?
- गोपनीयता। आपकी जानकारी संवेदनशील हो तो NDA।
- वारंटी और सपोर्ट। लॉन्च के एक हफ़्ते बाद कोई बग आ जाए तो क्या होता है?
- रिश्ता ख़त्म करना। कोई भी पक्ष इसे कैसे रोक सकता है, और ऐसा होने पर आपको क्या मिलेगा।
मेरी सिफ़ारिश
अगर आप अपने प्रोजेक्ट को साफ़ बता सकते हैं, तो फ़िक्स्ड प्राइस माँगें और अच्छे सप्लायर से स्पष्ट स्कोप और बदलाव की प्रक्रिया के साथ इसकी उम्मीद रखें। अगर नहीं बता सकते, तो ज़बरदस्ती न करें। एक छोटे, सशुल्क डिस्कवरी चरण से या सीमा वाले टाइम एंड मटीरियल्स चरण से शुरू करें, और जो हिस्से साफ़ परिभाषित हो जाएँ उनके लिए फ़िक्स्ड प्राइस पर आएँ।
IT Labs India में हम ये सभी देते हैं, और हम निःशुल्क प्रारंभिक परामर्श के बाद मॉडल की सिफ़ारिश करते हैं, क्योंकि सही चुनाव आपके प्रोजेक्ट पर निर्भर करता है, इस पर नहीं कि हमारे इनवॉइस के लिए क्या सुविधाजनक है। हर काम लिखित अनुमान से शुरू होता है। यदि आप सोच रहे हैं कि क्या माँगें, तो हमारा लेख कस्टम सॉफ़्टवेयर की लागत किससे तय होती है एक उपयोगी साथी है, और हम प्रोजेक्ट कैसे चलाते हैं, यह आप हमारे हम कैसे काम करते हैं पेज पर पढ़ सकते हैं। जब आप तैयार हों, तो हमें अपने प्रोजेक्ट के बारे में बताएँ।