सिस्टम विकासको आदेश दिने प्रयोगकर्ता पक्षले बहन गर्नुपर्ने सहयोग दायित्व के हो?
सिस्टम विकासको काम जति ठूलो स्केलमा हुन्छ, त्यति धेरै मानव शक्ति र समयको आवश्यकता पर्दछ। त्यसैले, यसमा विकास गर्ने वेन्डरको मात्र होइन, सिस्टम विकासको आदेश दिने प्रयोगकर्ताको तर्फबाट पनि निश्चित सहयोगको दायित्व अपेक्षित हुन्छ।
यो सामान्य खरिद-बिक्री सम्बन्धभन्दा फरक हो। उदाहरणको लागि, यदि आईटी सिस्टम होइन तर अर्डरमा बनाइएको सूटको निर्माणको लागि सूटको पसललाई आदेश दिन्छ भने, आदेश दिने ग्राहक (प्रयोगकर्ता) तर्फबाट कुनै विशेष ‘दायित्व’ बहन गर्नु पर्दैन। ‘दायित्व’ बहन गर्ने व्यक्ति विशेष गरी आदेश प्राप्त गर्ने सूटको पसल (वेन्डर) तर्फ हुन्छ। धेरै मानव शक्ति र समयको आवश्यकता पर्ने आईटी सिस्टमको कारणले, प्रयोगकर्ताले पनि वेन्डरलाई ‘सहयोग’ गर्नु आवश्यक छ, यो त्यस्तो संरचना हो।
यस लेखमा, हामी वेन्डरमात्र भर पर्न नसकिने सिस्टम विकासको बारेमा छलफल गर्नेछौं र आदेश दिने पक्षले कुन कुन कानूनी दायित्वहरू बहन गर्नुपर्छ भन्ने बारेमा व्याख्या गर्नेछौं।
आफ्नै कम्पनीको सिस्टम भएकोले, सबै कुरा ‘पूर्ण रूपमा अर्कोलाई जिम्मा लगाउने’ भन्ने हुँदैन
एउटा सिस्टम विकास परियोजना भए पनि, धेरै जसो समयमा धेरै मानिसहरू र संस्थाहरू संलग्न हुन्छन्। कोडिङ प्रविधिमा दक्ष इन्जिनियरहरू र प्रोग्रामरहरू त छन् नै, तर यी मानिसहरूको आउटपुटलाई एक सफल परिणाममा परिणत गर्नका लागि परियोजना प्रबन्धकको भूमिका पनि महत्वपूर्ण हुन्छ।
तर, वेन्डर पक्षले जति उच्च प्राविधिक शक्ति र संगठनात्मक क्षमता भएको होस्, सिस्टम विकासलाई वेन्डर पक्षको मात्रै प्रयासले पूरा गर्न सकिन्न। उदाहरणका लागि, कम्पनी भित्र मात्र प्रयोग हुने आन्तरिक शब्दावली वा कम्पनीको विशेष व्यावसायिक ज्ञान जस्ता कुराहरू वेन्डर पक्षको एकतर्फी प्रयासले मात्र जान्न सकिन्न। ठूलो प्रणालीको विकास भएको खण्डमा, सामान्यतया त्यो सिस्टम प्रयोग गर्ने कम्पनी पनि धेरै मानिसहरू र कामहरू समेटिएको ठूलो संस्था हुने गर्छ। सिस्टम विकास परियोजनालाई सफलताको दिशामा अगाडि बढाउनका लागि, वास्तवमा कम्प्युटरको काम भन्दा पहिले, यस्ता व्यावसायिक तर्कहरूको व्यवस्थापन नै धेरै ठूलो महत्व राख्छ।
तसर्थ, प्रयोगकर्ता पक्षले पनि ‘म आईटी प्रविधिको विशेषज्ञ होइन’ भन्ने कारणले ग्रहणशील बन्नुको सट्टा, उल्टो सक्रिय रूपमा जानकारी प्रदान गरेर परियोजनाको प्रगति सुचारु रूपमा अगाडि बढाउन सकिन्छ। यस अर्थमा, सिस्टम विकास परियोजनामा प्रयोगकर्ता पक्षले निर्वाह गर्नुपर्ने भूमिका वास्तवमा त्यति सानो होइन।
नेपालीमा: जापानी प्रणाली अनुसार उपयोगकर्ताको सहयोग दायित्व के हो?
त्यसो भए, सिस्टम विकास परियोजनामा उपयोगकर्ताको तर्फबाट लिइने सहयोग दायित्व के हुन सक्छ? यस विषयमा, अतीतका न्यायिक निर्णयहरूले धेरै संकेतहरू छोडेका छन्।
न्यायालयमा, विक्रेताको तर्फबाट (प्रतिवादी) डेलिभरीको समयमा ढिलाइ भएको मामलामा, उपयोगकर्ता (वादी) को निर्णय लिने प्रक्रियामा ढिलाइ भएको थियो भन्ने कुरा उठाइएको थियो, जसले उपयोगकर्ताको विकासमा सहयोग दायित्वको उपस्थिति वा अनुपस्थितिलाई विवादको विषय बनायो। यस मामलामा अदालतले उपयोगकर्ताको तर्फबाट सहयोग दायित्व उल्लंघन गरिएको ठहर गरी, विक्रेताको दायित्व पूरा नगरेको जिम्मेवारीलाई अस्वीकार गर्यो। (अनुबंधको रद्दीकरणलाई स्वीकार गरिएको थियो, तर त्यसमा पनि छठाउँको दोष समायोजन स्वीकार गरिएको थियो।)
यो विशेष जापानी इलेक्ट्रोनिक सिस्टम विकास सम्झौता, तथाकथित अनुकूलित सिस्टम विकास सम्झौता हो, जहाँ यस्तो अनुकूलित सिस्टम विकासमा ठेकेदार (वेन्डर) मात्रले सिस्टम पूरा गर्न सक्दैन, त्यसैले, आदेशकर्ता (प्रयोगकर्ता)ले विकास प्रक्रियामा आफ्नो भित्री मत समायोजन गरी एकमतमा पुगेर, कुन कार्यहरू चाहिन्छ भनेर स्पष्ट रूपमा ठेकेदारलाई जानकारी दिनुपर्छ र ठेकेदारसँगै ती कार्यहरूको अध्ययन गरी अन्ततः कार्यहरू निर्णय गर्नुपर्छ, त्यसपछि, स्क्रिन र फारमहरू निर्णय गर्नुपर्छ, र परिणामको परीक्षण गर्नुपर्छ जस्ता कार्यहरू बाँडफाँट गर्नु आवश्यक छ।
टोक्यो जिल्ला अदालत, हेइसेइ (2004) १६औं वर्ष मार्च १० तारिखको निर्णय
यो निर्णयले, सिस्टम विकास आफैमा प्रयोगकर्ता पक्षसँगको सहकार्य हो भन्ने मात्र होइन, ‘कुन विशेष बिन्दुहरूमा सहकार्य गर्नुपर्छ’ भन्ने बारेमा पनि व्याख्या गरेको छ, जुन अत्यन्तै सुझावपूर्ण छ।
आउनुहोस्, उक्त निर्णयको शब्दावलीलाई IT सिस्टम विकासका शब्दहरूमा अनुवाद गरौं।
| अन्ततः कार्यहरू निर्णय गर्नुपर्छ… → आवश्यकता परिभाषा: कुन प्रकारका कार्यहरू समावेश गरिएको सिस्टम बनाउन चाहिन्छ भन्ने स्पष्टीकरण |
| स्क्रिन र फारमहरू निर्णय गर्नुपर्छ… → मूलभूत डिजाइन: सिस्टम अपरेटरको दृष्टिकोणबाट सिस्टमको बाह्य रूपको डिजाइन, जस्तै स्क्रिन र फारमहरू |
| परिणामको परीक्षण… → परीक्षण: विशिष्टताहरू अनुसारको सिस्टम तयार भएको छ कि छैन भनेर परीक्षण गरी, DB डम्प जस्ता प्रमाण सामग्रीहरूसँगै जाँच गरी, डेलिभरी स्वीकार गर्ने। |
यसरी व्यवस्थित गर्न सकिन्छ। यी सबै कुराहरू, IT सिस्टमको प्राविधिकता जति उच्च दर्जाको भए पनि, प्रयोगकर्ताको सहयोग बिना एक्लैले सम्पन्न गर्न सकिने कुराहरू होइनन्। चाहिएका कार्यहरू र स्क्रिनको लेआउट कस्तो हुनुपर्छ भन्ने कुरा मूलतः प्रयोगकर्ताले स्पष्ट पार्नुपर्ने हुन्छ, र त्यस्तै चाहिएको कुरा प्राप्त भएको छ कि छैन भन्ने पनि प्रयोगकर्ताले नै जाँच गर्न सक्छन्।
यद्यपि, वेन्डरलाई प्रोजेक्ट प्रबन्धनको कर्तव्य लगाइएको छ भनेर, प्रयोगकर्तालाई पनि सहयोगको कर्तव्य लगाइएको छ, त्यसैले प्रयोगकर्ताले उल्लेखित प्रक्रियामा सहयोगको कर्तव्य उल्लंघन गरे, उल्टो वेन्डरले प्रयोगकर्तासँग अनुबन्ध अनुपालन नगरेको वा अवैध कार्यको आधारमा क्षतिपूर्ति दावी गर्न सक्ने सम्भावना पनि छ।
जापानमा सिस्टम विकास पछि विशेष आवश्यकताहरूको अनुरोध कसरी सम्झिने?
यदि हामी यसलाई आधार मान्ने हो भने कि सिस्टम विकास परियोजना प्रयोगकर्ता र विक्रेताको संयुक्त प्रयास हो, त्यसपछि अझ विकसित छलफलमा कुरा अगाडि बढ्छ। यो छलफलमा यस्तो प्रश्न उठ्छ कि “यदि प्रयोगकर्ताले पछि कार्यक्षमता थप्न वा सुधार गर्न अनुरोध गर्छन् र त्यसले डेलिभरीको समयसीमा पूरा गर्न गाह्रो हुन्छ भने, त्यसको जिम्मेवारी कसको हुन्छ?”
सिस्टम विकास सामान्यतया आवश्यकता परिभाषा बाट सुरु हुन्छ, र बेसिक डिजाइन, विस्तृत डिजाइन, निर्माण (प्रोग्राम कार्यान्वयन), परीक्षण जस्ता चरणहरूमा क्रमशः अगाडि बढ्छ, र यसलाई यथासंभव पुन: काम गर्नुपर्ने अवस्था नआओस् भन्ने लक्ष्य राखिन्छ (सामान्यतया यसलाई वाटरफल मोडेल भनिन्छ)। तर कुनै कारणले गर्दा, पूर्व चरणमा त्रुटि रहेको पत्ता लाग्दा, प्रक्रियामा पुन: काम गर्नुपर्ने अवस्था आउने घटना वास्तविकतामा अक्सर देखिन्छ।
यस्ता मामलाहरूमा, यदि डेलिभरीको समयमा नभएको खण्डमा कसरी सोच्ने? भूतकालका न्यायिक निर्णयहरूलाई विश्लेषण गर्दा, थप काम आवश्यक परेको समयानुसार निष्कर्षमा भिन्नता देखिन्छ।
जापानमा बाह्य डिजाइन वा अन्य विशिष्टताहरू स्पष्ट हुनुभन्दा पहिले अतिरिक्त काम गर्नुपरेमा
उल्लिखित निर्णयले बुनियादी डिजाइन चरणमा (प्रोग्राम कार्यान्वयन चरणभन्दा पहिले) प्रयोगकर्ताबाट प्राप्त अतिरिक्त विकासको अनुरोधलाई समेत सम्बोधन गर्दै, यस्ता मागहरू उठाउनु स्वयंमा सहयोग गर्ने कर्तव्यको उल्लंघन नभएको पनि स्पष्ट पारेको छ।
प्रयोगकर्ताले विक्रेतालाई बुनियादी डिजाइन कार्यक्रमको बीचमा निर्माण गर्ने प्रणालीसँग सम्बन्धित विभिन्न मागहरू राख्नु यस्तो प्रणाली विकास प्रक्रियामा स्वाभाविक हो, र त्यसमाथि, विशेषज्ञ ज्ञान नभएका मुद्दावाला प्रयोगकर्ताले ती मागहरूले अतिरिक्त सेवा शुल्क वा डेलिभरी समयसीमा विस्तार आवश्यक पार्ने कि नपार्ने, कार्य प्रक्रियामा बाधा पुर्याउने कि नपुर्याउने भन्ने कुरा यथार्थ रूपमा निर्णय गर्न सक्नु गाह्रो हुन्छ, त्यसैले मुद्दावाला प्रयोगकर्ताले अतिरिक्त सेवा शुल्क वा डेलिभरी समयसीमा विस्तार जस्ता मागहरूलाई स्वयं नियन्त्रण गर्नुपर्ने भन्ने कुरा पनि हुन सक्दैन। बरु, मुद्दावाला प्रयोगकर्ताले यस्ता मागहरू गरेको खण्डमा, परियोजना प्रबन्धन कर्तव्य बहन गर्ने प्रतिवादीले प्रयोगकर्तालाई त्यसको बारेमा जानकारी दिनुपर्ने थियो, मागहरू फिर्ता लिन वा डेलिभरी समयसीमा विस्तारको लागि छलफल माग्नुपर्ने थियो, र विकास कार्यमा कुनै बाधा नआउने गरी गर्नुपर्ने थियो।
टोक्यो जिल्ला अदालत, हेइसेइ १६ (२००४) मार्च १० को निर्णय
उक्त निर्णयले प्रयोगकर्ताको तर्फबाट पनि केही हदसम्म सहयोग कर्तव्य रहेको भन्ने कुरालाई स्वीकार गर्दै, प्रयोगकर्ता आफैं प्रणाली विकासका विशेषज्ञ नभएको कुरालाई पनि मध्यनजर गर्नुपर्ने बताएको छ। अर्थात्, प्रणाली विकासका विशेषज्ञ नभएका प्रयोगकर्ताहरूले, प्रणालीको सामग्री स्पष्ट हुनुभन्दा पहिले, (कहिलेकाहीं आदेश दिनमा समेत अनुभव नभएकाले) विभिन्न आदेशहरू दिनु स्वाभाविक हो, र त्यस्ता आदेशहरूले डेलिभरी समयसीमा आदिको पुनरावलोकन आवश्यक पार्ने खण्डमा ‘आफैंले त्यसको बारेमा जान्नुपर्ने’ भन्ने कुरा अनुचित हो।
तथापि, यहाँ विक्रेताको तर्फबाट लगाइएको कर्तव्य भनेको, अन्ततः सम्पर्कको प्रयास गर्नु हो, जस्तै डेलिभरी समयसीमा विस्तारको माग गर्नु (वा यदि डेलिभरी समयसीमा परिवर्तन गर्न सकिन्न भने, अतिरिक्त मागहरू नै फिर्ता लिन सुझाव दिनु)। त्यसैले, प्रयोगकर्ताका सबै मागहरूलाई स्वीकार गरी, तोकिएको मितिमा डेलिभरी गर्नु नै सबै कर्तव्य भित्र पर्छ भन्ने अर्थमा होइन, त्यसैले यस बिषयमा सचेत हुनु आवश्यक छ।
जापानमा उत्पादन र परीक्षण प्रक्रियाको विशिष्टता तय भएपछि थप काम गर्नुपरेमा
उल्लेखित निर्णयको सामग्रीलाई उल्टाउँदा, विशिष्टता पहिले नै तय भइसकेको अवस्थामा थप विकासको लागि के प्रकारको निष्कर्षमा पुग्न सकिन्छ भन्ने कुरा पनि केही हदसम्म अनुमान गर्न सकिन्छ। त्यस्तो अवस्थामा, यस्ता मागहरू पूरा गर्न गाह्रो हुन सक्छ। निश्चित रूपमा, प्रयोगकर्ता पक्ष र विक्रेता पक्षबीच विकास कार्यमा समझको फरक विशिष्टता तय भएको अघि वा पछि भए पनि उस्तै रहन्छ।
तर, विशिष्टता तय भएपछि अर्डरको सामग्री परिवर्तन गर्नु वा थप्नुले कामको पुन:सुरुवात गर्न बाध्य पार्ने सम्भावना धेरै हुन्छ। यस्तो अवस्थामा भएको डेलिभरी ढिलाइको बारेमा ‘ग्राहक हो त्यसैले विभिन्न माग राख्नु स्वाभाविक हो’ भनेर बचाउ गर्नु कठिन हुन सक्छ। थपमा, धेरै विशिष्टता परिवर्तन र सुविधा थप्नु पछि हुनुले यो पनि प्रश्न उठाउँछ कि के यस्तो अवस्था प्रारम्भिक डिजाइन जस्ता पहिले नै सम्पन्न भएको हुनुपर्ने उपरी प्रक्रियामा प्रयोगकर्ता पक्षको सहयोगको कर्तव्य उल्लंघन भएको छैन?
यस्ता बिन्दुहरूबाट पनि, विशिष्टता एक पटक तय भएपछि गरिएको विशिष्टता परिवर्तनको लागि त्यसको कारणले भएको डेलिभरी ढिलाइलाई विक्रेता पक्षको जिम्मेवारीको रूपमा लिनु व्यावहारिक नहुन सक्छ। पहिले उल्लेखित निर्णयबाट, यस्तो अर्थ निकाल्नु पनि उचित हुन्छ।
यस्तो निर्णय अनुबंध पत्र मात्र होइन, सिस्टम विकासको प्रगतिसँग मिलाएर बनाइएका मिनट्सहरूलाई पनि प्रमाणको रूपमा लिने प्रवृत्ति छ। मिनट्सको बारेमा तलको लेखमा विस्तृत रूपमा व्याख्या गरिएको छ।
सम्बन्धित लेख: जापानी कानूनी दृष्टिकोणबाट हेर्दा सिस्टम विकासमा मिनट्स कसरी राख्ने[ja]
सारांश: आवश्यकता परिभाषा प्रक्रिया प्रयोगकर्ताको तर्फबाट हुने कुरा नबिर्सनु महत्त्वपूर्ण छ
आवश्यकता परिभाषा प्रक्रिया विक्रेताको क्षमता देखाउने अवसर हो भने पनि, यसलाई प्रयोगकर्ताको तर्फबाटको कार्यको रूपमा सचेत रहनु आवश्यक छ। यदि त्यो आफ्नै कम्पनीको प्रयोगमा आउने सिस्टम हो भने, बाहिरी विशेषज्ञको सहयोगले निर्माण गरिएको भए पनि, कानूनी रूपमा यो क्षेत्रमा आफ्नो कम्पनीको गभर्नेन्स प्रभाव पर्नुपर्छ भन्ने बुझ्नु आवश्यक छ।
यदि प्रयोगकर्ताको तर्फबाट विकास प्रक्रियामा सहयोगी भावना नभएमा, परियोजना जति नै जटिल बनोस्, अदालतले प्रयोगकर्ताको तर्फमा पनि कठोर दृष्टिकोण अपनाउन सक्ने सम्भावना छ भन्ने कुरा पहिले नै बुझ्नु आवश्यक छ।
Category: IT
Tag: ITSystem Development
