जब कस्टम सॉफ्टवेयर प्रोजेक्ट की कीमतों पर बातचीत होती है, तो अक्सर दोनों पक्षों के बीच समान होने वाली इकाई «मैन-डे» होती है: कितने इंजीनियर, कितने दिन और कितना प्रति मैन-डे। यह मॉडल तभी काम करता है जब आवश्यकताएं स्थिर हों और डिलीवरी की सीमाएं स्पष्ट हों; लेकिन जब फ़ील्ड के नियम बार-बार बदलते हैं, AI टूल्स कोडिंग की दक्षता को बढ़ा देते हैं, और ग्राहक अभी भी «मैन-पॉवर के ढेर» के आधार पर ही स्वीकृति देता है, तो तनाव फट जाता है—दूसरा पक्ष महसूस करता है कि आवश्यकताएं बढ़ गई हैं, जबकि ग्राहक का मानना है कि «इंजीनियरों की संख्या नहीं बढ़ी, लेकिन काम ज्यादा नहीं हुआ»।
नीतिगत संकेत: मैन-पॉवर बेचने से लेकर परिणाम बेचने तक
सितंबर 2026 में, मिनिस्ट्री ऑफ़ इंडस्ट्री एंड इनफ़ॉर्मेशन टेक्नोलॉजी ने «एआई+सॉफ्टवेयर» विशेष अभियान के कार्यान्वयन का निर्देश जारी किया, जिसमें कई बार सॉफ्टवेयर उत्पादन मॉडल में परिवर्तन लाने और «मॉडल एस ए सर्विस», «एजेंट एस ए सर्विस» के विकास का उल्लेख किया गया, साथ ही 2028 तक महत्वपूर्ण उद्योगों में एजेंट-आधारित सॉफ्टवेयर के बेंचमार्क ऐप्लिकेशन बनाने का लक्ष्य भी निर्धारित किया गया। दस्तावेज़ ने कस्टम डेवलपमेंट को नकारा नहीं, लेकिन एक स्पष्ट दिशा दी: सॉफ्टवेयर के मूल्य का आकलन अब अधिक व्यावहारिक परिणामों पर आधारित है, न कि केवल इतने मैन-डे लगाने पर ।
जो एंटरप्राइज़ ERP, MES, CRM या उद्योग प्रबंधन प्रणाली बना रहे हैं, उनके लिए इसका मतलब है कि अगर अनुबंध में अभी भी केवल «XX लोग × XX दिन» लिखा गया है, तो लॉन्च के बाद «कोड तो तैयार है, लेकिन व्यवसाय इसका उपयोग नहीं कर पा रहा है» जैसे विवादों में फंसने की संभावना बढ़ जाती है। अधिक स्थिर तरीके से लिखने के लिए, डिलीवरी को स्वीकृति योग्य व्यावसायिक परिणामों में विभाजित करना चाहिए ।
व्यावसायिक तर्क: मील के पत्थर लोगों के दिनों से अधिक विशिष्ट होने चाहिए
प्रोजेक्ट को «चरणवार भुगतान» से «मील के पत्थर भुगतान» में अपग्रेड करें, जहाँ हर मील के पत्थर के लिए चार बातें एक साथ पूरी होनी चाहिए:
- व्यावसायिक परिदृश्य : कौन इसका उपयोग कर रहा है, किस कार्रवाई का समाधान कर रहा है (उदाहरण के लिए, «गोदाम कर्मचारी स्कैन करके सामान दर्ज कर रहा है» बजाय «इनबाउंड मॉड्यूल को पूरा करने» के)।
- डेटा के मापदंड : कौन से मुख्य डेटा, स्थिति फ़ील्ड और अधिकार सीमाएं शामिल हैं, और नमूना लेने का नियम क्या है।
- स्वीकृति स्क्रिप्ट : दिए गए परीक्षण डेटा के आधार पर, कौन से प्रक्रियाएं चलाई जाती हैं, कौन से दस्तावेज़ या रिपोर्ट उत्पन्न होती हैं।
- अपवाद प्रबंधन : विफलता के समय सिस्टम कैसे संकेत देता है, किसके पास संशोधन का अधिकार है, और क्या इसका रिकॉर्ड रखा जाता है।
मील के पत्थर को 2–4 सप्ताह से अधिक नहीं होना चाहिए; अगर यह बहुत लंबा है, तो यह फिर से «ब्लैक बॉक्स डेवलपमेंट» की ओर ले जाएगा। विशिष्ट विभाजन का उदाहरण: मुख्य डेटा और अधिकार → कोर दस्तावेज़ का लूप → रिपोर्ट और बैलेंसिंग → इंटरफ़ेस और लॉन्च स्विच।
डिज़ाइन तर्क: दायरा, परिवर्तन और «स्मार्ट सहायता» को अनुबंध में शामिल करना
AI सहायता से कोडिंग, परीक्षण के लिए ऑटोमेटेड केसेस का उत्पादन, और दस्तावेज़ों का स्मार्ट भरना, एक ही कार्य के लिए मैन-डे की खपत को बदल देगा, लेकिन व्यावसायिक जटिलता को स्वतः नहीं बदलेगा । अनुबंध और आवश्यकता विनिर्देश में एक अलग सूची की सिफारिश की गई:
- दायरे की बेसलाइन (Baseline) : कार्यों की सूची + जो दायरे से बाहर हैं (Out of Scope), परिवर्तन के लिए चेंज ऑर्डर की आवश्यकता है।
- परिवर्तन के मूल्यांकन के नियम : नए मील के पत्थरों का मूल्यांकन «परिदृश्य + स्वीकृति स्क्रिप्ट» के आधार पर किया जाता है, न कि अस्थायी रूप से मैन-डे जोड़ने से।
- स्मार्ट सहायता की सीमाएं : किन चरणों में AI दक्षता बढ़ा सकता है (कोड जनरेशन, डॉक्यूमेंट ड्राफ्ट), और किन चरणों में मानव हस्ताक्षर ज़रूरी हैं (सुरक्षा, अनुपालन, बाहरी वादे)।
- ज्ञान के संग्रह का स्वामित्व : प्रक्रिया दस्तावेज़, कॉन्फ़िगरेशन और स्क्रिप्ट किसके पास हैं, ताकि डिलीवरी के बाद ऑपरेशन में कोई रुकावट न आए।
डेवलपमेंट का लागू होना: स्वीकृति का ऑटोमेशन और निरीक्षण
«परिणाम-ओरिएंटेड» को लागू करने के लिए, तकनीकी पक्ष को तीन चीज़ों का समर्थन करना चाहिए:
- स्वीकृति के उदाहरणों का डेटा बेस : हर मील के पत्थर के लिए एक समूह ऑटोमेटेड या अर्ध-ऑटोमेटेड उदाहरण होते हैं, जिन्हें रिटर्न चलाकर बार-बार चलाया जा सकता है।
- वातावरण और डेटा का अलगाव : UAT वातावरण के डेटा को रीसेट किया जा सकता है, ताकि «केवल प्रदर्शन वातावरण में ही पास होने» जैसी समस्या न हो।
- निरीक्षण लॉग : महत्वपूर्ण कार्रवाई के लिए ऑडिट लॉग होते हैं, जिससे विवाद के समय यह पता चल सकता है कि किसने क्या बदला।
अगर प्रोजेक्ट में एजेंट या रूल इंजन शामिल है, तो स्वीकृति में सैंपलिंग तंत्र जोड़ना चाहिए: बाहरी मामलों के लिए यादृच्छिक इनपुट देकर, जांच करना कि क्या नकारात्मक जवाब, मानव संशोधन या अधिकार रोकने की व्यवस्था डिज़ाइन के अनुरूप है, न कि केवल «चैट करने की क्षमता» को देखना।
तीन प्रकार के आम विवाद और उनकी रोकथाम
विवाद नंबर एक: «सभी कार्य पूरे हो गए, फिर भी व्यवसाय इसका उपयोग क्यों नहीं कर रहा?» — रोकथाम: मील के पत्थर को नौकरी के अनुसार कार्यों और प्रशिक्षण की हाज़िरी से जोड़ दें, स्वीकृति के दौरान फ़ील्ड में गश्त लगाएं, केवल PPT प्रदर्शन न करें।
विवाद नंबर दो: «एक छोटी सी आवश्यकता जोड़ने के लिए पैसे क्यों चाहिए?» — रोकथाम: चेंज ऑर्डर में प्रभावित मील के पत्थर, स्क्रिप्ट और समय का स्पष्ट उल्लेख करें, और दोनों पक्षों के हस्ताक्षर के बाद ही डेवलपमेंट शुरू करें।
विवाद नंबर तीन: «AI ने दक्षता बढ़ाई, तो क्या मैन-डे कम किया जा सकता है?» — रोकथाम: अनुबंध में «रियलाइज़ेशन कॉस्ट» और «व्यावसायिक जटिलता» को अलग करें; दक्षता के लाभ को कुल कीमत या अवधि में दिखाया जा सकता है, लेकिन स्वीकृति के मानकों को कम नहीं किया जाता।
पायलट सिफारिश: एक बंद लूप वाले मॉड्यूल से शुरू करें
पूरे सिस्टम के लिए अनुबंध फिर से लिखने का इंतजार न करें। एक ऐसे मॉड्यूल का चयन करें जो 2–3 सप्ताह में बंद लूप बना सकता है (जैसे इनबाउंड/आउटबाउंड, वर्क ऑर्डर रिपोर्टिंग, खर्चों का अनुमोदन), और नए टेम्पलेट के साथ अतिरिक्त समझौता पर हस्ताक्षर करें: परिदृश्य, स्क्रिप्ट, अपवाद और भुगतान के चरणों को सूचीबद्ध करें। इसे चलाने के बाद ही पूरे प्रोजेक्ट में विस्तार करें। सफलता का आकलन करने के लिए, देखें कि चेंज ऑर्डर के विवादों का समय कम हुआ है , और UAT के एक बार में पास होने की दर बढ़ी है , न कि यह कि दूसरा पक्ष कितने मैन-डे कम रिपोर्ट कर रहा है। अगर पायलट मॉड्यूल अच्छी तरह चुना गया है, तो पूरे प्रोजेक्ट के लिए अनुबंध बदलने का आधार बनेगा।
मैन-डे रातोंरात गायब नहीं होंगे, लेकिन वे «कीमत की एकमात्र इकाई» से «लागत के अनुमान का संदर्भ» बन रहे हैं। मील के पत्थर और स्वीकृति स्क्रिप्ट को अनुबंध में शामिल करना ही कस्टम सॉफ्टवेयर का मूल अभ्यास है, जो «एआई+सॉफ्टवेयर» के परिदृश्य में भी विश्वसनीय परिणाम दे सकता है।
फिक्स्ड टोटल प्राइस और एजाइल इटरेशन के साथ समन्वय
मील के पत्थर की स्वीकृति एजाइल को खारिज नहीं करती: हर स्प्रिंट में अभी भी प्रदर्शनीय वृद्धि डिलीवर की जा सकती है, लेकिन भुगतान और औपचारिक स्वीकृति बड़े मील के पत्थर पर निर्भर है। फिक्स्ड टोटल प्राइस अनुबंध में विशेष रूप से «दायरे के फ्रीज़ पॉइंट» को स्पष्ट करना चाहिए — किस समीक्षा के बाद नई आवश्यकताएं चेंज ऑर्डर के तहत चलें, ताकि मौखिक रूप से कार्यों को जोड़ने की समस्या न हो। एजेंट वाले मॉड्यूल के लिए, अलग मील के पत्थर की स्वीकृति की सिफारिश की गई है: «रूल वर्जन + सैंपलिंग पास रेट», और इसे पूरे साइट के लॉन्च के साथ एक साथ न जोड़ें।
उद्योग डेटा बताता है कि सॉफ्टवेयर प्रोजेक्ट की विफलता का लगभग एक तिहाई आवश्यकताओं और स्वीकृति के मापदंड की अस्पष्टता के कारण होती है, न कि तकनीकी कार्यान्वयन के कारण। पहले «क्या पूरा हुआ» को अनुबंध में लिख दें, यह AI ने कितने प्रोग्रामर को बदल दिया, इस बारे में बहस करने से अधिक महत्वपूर्ण है। अगली बार जब प्रोजेक्ट की समीक्षा हो, तो पहले एक सवाल पूछें: अगर कल दूसरा पक्ष पूरी टीम के साथ छुट्टी पर चला जाता है, तो क्या हम स्क्रिप्ट के आधार पर यह निर्धारित कर सकते हैं कि वर्तमान मील के पत्थर का स्तर ठीक है या नहीं — अगर जवाब नहीं आता, तो यह दर्शाता है कि स्वीकृति अभी तक स्पष्ट नहीं हुई है। मील के पत्थर को अनुबंध में शामिल करना दूसरे पक्ष को कठिन बनाने के लिए नहीं है, बल्कि दोनों पक्षों को एक ही पेपर पर «क्या पूरा हुआ» के बारे में बातचीत करने के लिए है। यह बात जितनी अधिक एआई दक्षता वाले प्रोजेक्ट में स्पष्ट होती है, उतनी ही अधिक जरूरी है कि इसे पहले से समझाया जाए।