1. बाहर निकलने की लागत सिमुलेशन
Sunk cost नेतृत्व के निर्णय को धुंधला कर देता है।
परंपरागत fixed-bid अनुबंध में परियोजना रोकने की हानि बनाम लचीले DaaS/Staff Augmentation मॉडल की तुलना करें।
संचयी लागत तुलना
स्लाइडर खिसकाकर वह महीना बदलें जब आप बाहर निकलने (रद्द करने) का निर्णय लेते हैं।
परंपरागत जोखिम (fixed-bid)
समाप्ति दंड और मध्यवर्ती डिलिवरेबल्स के buyout दायित्व अक्सर लागू होते हैं, जिससे sunk cost का जोखिम बढ़ता है।
DaaS जोखिम (लचीला अनुबंध)
आप केवल किए गए काम के लिए भुगतान करते हैं। क्योंकि आप कभी भी रोक सकते हैं, नुकसान बढ़ने से पहले बाहर निकल सकते हैं।
कभी भी रद्द करने की क्षमता विक्रेता को उच्च गुणवत्ता बनाए रखने के लिए प्रेरित करती है।
2. vendor lock-in और "पारदर्शिता" की संरचना
Lock-in का डर अंदर क्या है यह न दिखने से आता है।
वे तत्व तुलना करें जो black box को रोकते हैं और स्वायत्त नियंत्रण लौटाते हैं।
Black-box विकास
विस्तृत स्पेसिफिकेशन केवल विक्रेता के दिमाग में होता है
-
✕
कोड स्वामित्व अस्पष्ट
कस्टम frameworks और लाइब्रेरी किसी अन्य टीम द्वारा takeover को कठिन बनाते हैं।
-
✕
दस्तावेज़ीकरण अनुपस्थित
आपको काम करने वाला उत्पाद मिलता है, लेकिन उसका "क्यों" नहीं।
-
✕
लोगों पर निर्भरता
अगर कोई मुख्य व्यक्ति चला जाए, सिस्टम रुक सकता है।
White-box विकास
सिस्टम को किसी भी समय हैंडओवर के लिए तैयार रखें
-
✓
मानक तकनीक चयन
व्यापक रूप से अपनाई गई भाषाएँ और frameworks चुनें ताकि विकल्प बने रहें।
-
✓
हमेशा GitHub आदि में साझा
क्लाइंट के repo में रोज़ाना commit करें ताकि प्रगति और गुणवत्ता realtime दिखे।
-
✓
Exit रणनीति शुरुआत से परिभाषित
पहले दिन से internalization/transition योजना डिजाइन करें।
पार्टनर चयन के लिए मूल्यांकन अक्ष (Risk Radar)
पार्टनर चुनते समय केवल कीमत नहीं, नीचे दिए पाँच अक्ष भी आँकें ताकि reversibility मापी जा सके।
- पारदर्शिता: सूचना तक पहुंच
- मानक तकनीक: टेक स्टैक कितना सामान्य है
- अनुबंध लचीलापन: रद्द करने की आसानी
- दस्तावेज़ीकरण: रिकॉर्ड किया गया डिज़ाइन इरादा
- स्व-निर्भरता समर्थन: internalization में मदद करने की इच्छा
3. निर्भरता से मुक्त हों: Exit रणनीति
अनुबंध lock-in से मूल्य-आधारित संबंध की ओर जाएं।
ज़रूरत पड़ने पर स्मूथ बाहर निकलने और हैंडऑफ़ की रोडमैप तय करें।
चरण 01 एसेट का स्वामित्व सुनिश्चित करें
सुनिश्चित करें कि स्रोत कोड, डिज़ाइन डेटा और दस्तावेज़ीकरण क्लाइंट के स्वामित्व में हों।
क्लाइंट repository (GitHub आदि) बनाता है और विक्रेता को आमंत्रित करता है।
चरण 02 ज्ञान को व्यक्ति-निर्भर न बनाएं
मीटिंग नोट्स के साथ-साथ कोड टिप्पणियाँ और ADRs भी दस्तावेज़ करें।
"क्यों" का संदर्भ छोड़ना हैंडऑफ़ लागत कम करता है।
चरण 03 ओवरलैप अवधि
internalization या विक्रेता परिवर्तन पर 1-2 महीने का ओवरलैप रखें।
pair programming और code review के जरिए कार्य-स्तर पर अधिकार ट्रांसफर करें।
लक्ष्य पूर्ण स्वतंत्रता
ऐसी स्थिति जिसमें सिस्टम बाहरी साझेदारों के बिना चलता रहे।
यही जोखिम प्रबंधन का अंतिम लक्ष्य है — एक स्वस्थ विकास मुद्रा।