एजाइल विकास से जुड़े कानूनी और अनुबंध समस्याएं क्या हैं
सिस्टम विकास को आगे बढ़ाने के लिए कई तरीके होते हैं। सबसे पुराना और सामान्य तरीका वॉटरफॉल मॉडल है, और कई सिस्टम विकास से संबंधित कानूनी पुस्तकें भी इस मॉडल को ध्यान में रखकर लिखी गई हैं। इस लेख में, हम बताएंगे कि एजाइल विकास मॉडल के आधार पर सिस्टम विकास में क्या कानूनी समस्याएं हो सकती हैं, जिसके बारे में पुस्तकों और अन्य स्रोतों से जानकारी प्राप्त करना मुश्किल होता है।
एजाइल विकास मॉडल और कानूनी मामले
सिस्टम विकास में मॉडल क्या होता है
सिस्टम विकास परियोजनाओं में, प्रगति को समग्र रूप से समझने के लिए, विकास मॉडल कहलाने वाला एक ढांचा होता है। इसका प्रमुख उदाहरण, सामान्यतः “वॉटरफॉल मॉडल” होता है। यानी, नदी के “उपरी धारा” से “निचली धारा” तक एक बार में गिरने वाले पानी की तरह, आवश्यकता परिभाषा, डिजाइन, कार्यान्वयन, परीक्षण आदि के प्रत्येक चरण को एक बार में पूरा करना। यह तरीका काम करने का उद्देश्य रखता है कि काम की पुनरावृत्ति और दोहराव को कम से कम किया जाए, और कार्य को योजनाबद्ध रूप से आगे बढ़ाया जाए।
वहीं, एजाइल विकास मॉडल में, छोटे प्रोग्राम का कार्यान्वयन करके परीक्षण किया जाता है, और यह क्रिया बार-बार दोहराई जाती है। इस प्रकार, छोटे प्रोग्राम का कार्यान्वयन करके परीक्षण करने की इस पुनरावृत्ति के माध्यम से, धीरे-धीरे एक बड़ा सिस्टम बनाया जाता है। इन सिस्टम विकास मॉडलों के अधिक विस्तृत विवरण के लिए, और दोनों विकास मॉडलों के लाभ और हानियों की तुलना के लिए, नीचे दिए गए लेख में अधिक विस्तृत जानकारी दी गई है।
https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]
एजाइल विकास मॉडल की विशेषताएं
एजाइल विकास मॉडल के अनुसार विकास का बड़ा लाभ यह है कि यह त्वरित गति से कार्य में लगने की अनुमति देता है। आवश्यकताओं की परिभाषा और डिजाइन दस्तावेज़ के निर्माण जैसे ‘उपरी धारा’ के कार्य और प्रोग्राम के कार्यान्वयन कार्य अलग नहीं होते हैं, इसलिए, सुविधाओं के जोड़ने, सुधार, विशेषताओं के परिवर्तन आदि के प्रतिक्रिया सहित, यह निर्णय लेने में लचीला होता है। कानूनी दृष्टिकोण से देखने पर, एजाइल विकास मॉडल को सफलता की ओर ले जाने के लिए विशेष रूप से महत्वपूर्ण बात यह है कि दस्तावेज़ प्रबंधन और परिवर्तन प्रबंधन को कैसे किया जाए। एजाइल विकास मॉडल में, वॉटरफॉल मॉडल की तरह, भूमिकाएं और जिम्मेदारियां स्पष्ट रूप से विभाजित नहीं होती हैं। साथ ही, ‘प्रबंधन’ के बजाय कार्यान्वयन और शुरुआत की ‘गति’ पर ध्यान देने की तकनीक होने के कारण, विभिन्न डिजाइन दस्तावेज़, विशेषता दस्तावेज़, मीटिंग रिकॉर्ड्स की अधूरी जानकारी का संबंध बन सकता है।
इसके अलावा, परिवर्तन प्रबंधन के संबंध में कहने की बात यह है कि, एजाइल विकास मॉडल में परिवर्तन के प्रतिक्रिया स्वचालित होती है, इसलिए, अनुमोदन प्रक्रिया को छोड़कर, यदि स्थलीय स्तर पर विशेषता परिवर्तन के अनुरोध का सामना करते हुए परियोजना जलती रहती है, तो ऐसा हो सकता है। अगर ऐसा होता है, तो “परिवर्तन के प्रतिक्रिया स्वचालित होने” की विकास मॉडल की लाभ भी, स्वयं को परियोजना के जलने का जोखिम बन सकती है।
एजाइल विकास में दस्तावेज़ प्रबंधन और परिवर्तन प्रबंधन का तरीका
दस्तावेज़ प्रबंधन का महत्व
एजाइल विकास मॉडल के आधार पर विकसित परियोजनाओं में, कानूनी रूप से चिंता का विषय होता है कि मौखिक आधारित संवाद संचित होते हैं, जिससे दस्तावेज़ों की कमी होती है। इस बिंदु पर, सिस्टम विकास परियोजनाओं में दस्तावेज़ प्रबंधन क्यों महत्वपूर्ण होता है, इसके बारे में हमने निम्नलिखित लेख में विस्तार से व्याख्या की है।
https://monolith.law/corporate/the-minutes-in-system-development[ja]
उक्त लेख में, विवाद की पूर्वानुमान (अर्थात ‘निवारक कानूनी कार्य’) और विवाद होने पर साक्ष्य संरक्षण (अर्थात ‘संकट प्रबंधन’) के दोनों दृष्टिकोणों से, सिस्टम विकास परियोजनाओं में दस्तावेज़ प्रबंधन के महत्व को समझाया गया है।
संपर्क समिति की स्थापना दस्तावेज़ प्रबंधन के लिए प्रभावी होती है
अगर आप एजाइल विकास मॉडल का अनुसरण कर रहे हैं, तो वॉटरफॉल मॉडल की तुलना में, पहले से स्पष्ट योजना तैयार नहीं होती है। इसलिए, योजना और वास्तविकता के बीच के अंतर को केवल प्रबंधित करने की जरूरत नहीं होती, बल्कि यह चिंता भी होती है कि अगर यह केवल स्थल पर छोड़ दिया जाए, तो समय और धन दोनों की लागत बढ़ सकती है।
इसलिए, यह उपाय प्रभावी होता है कि प्रभारी नियमित रूप से संपर्क समिति की बैठक का आयोजन करें, ताकि परियोजना को सुचारू रूप से आगे बढ़ाया जा सके। जब विकास का पैमाना छोटा होता है, तो निश्चित रूप से, नियमित रूप से संपर्क समिति की बैठक का आयोजन करने की तुलना में, प्रभारी लोगों के बीच में समय-समय पर मिलने का तरीका अधिक पसंद किया जाता है। हालांकि, एजाइल विकास मॉडल के मामले में, समय पर मुद्दों को बैठक में नहीं संभालने का खतरा भी बढ़ जाता है। इसलिए, नियमित रूप से संपर्क समिति की बैठक का आयोजन करना सुरक्षित माना जाता है, और इसे अनुबंध दस्तावेज़ में भी शामिल करना चाहिए। नियमन के तौर पर, जापानी उद्योग मंत्रालय मॉडल अनुबंध में इसे निम्नलिखित तरीके से दर्शाया गया है।
(संपर्क समिति की स्थापना)
धारा 12 के अनुसार, पार्टी A और B, इस कार्य के समापन तक, उसकी प्रगति, जोखिम प्रबंधन और रिपोर्टिंग, पार्टी A और B द्वारा साझा कार्य और प्रत्येक का कार्य की स्थिति, सिस्टम विनिर्देश पुस्तिका में शामिल करने के लिए सामग्री की पुष्टि, समस्याओं की चर्चा और समाधान और अन्य आवश्यक बातें चर्चा करने के लिए, संपर्क समिति की बैठक का आयोजन करेंगे। हालांकि, (मध्य छोड़ें)।
2. संपर्क समिति की बैठक, सिद्धांततः, व्यक्तिगत अनुबंध में निर्धारित आवृत्ति के अनुसार नियमित रूप से आयोजित की जाएगी और इसके अतिरिक्त, जब पार्टी A या B इसे आवश्यक मानती है, तो यह कभी भी आयोजित की जाएगी।
3. संपर्क समिति की बैठक में, पार्टी A और B के प्रभारी, मुख्य अधिकारी और प्रभारी द्वारा उचित माने जाने वाले लोग उपस्थित होंगे। इसके अलावा, पार्टी A और B, संपर्क समिति की बैठक में चर्चा के लिए आवश्यक लोगों की उपस्थिति का अनुरोध कर सकती है, और दूसरी पार्टी को यथोचित कारण के अभाव में, इसे मानना होगा।
4. पार्टी B, संपर्क समिति की बैठक में, पार्टी A और B के बीच अलग से तय किए गए प्रारूप के अनुसार प्रगति प्रबंधन रिपोर्ट तैयार करेगी और प्रस्तुत करेगी, और इस प्रगति प्रबंधन रिपोर्ट के आधार पर प्रगति की स्थिति की पुष्टि करेगी, क्या कोई देरी है, अगर देरी है तो उसका कारण और उपाय, इस अध्याय में निर्धारित प्रोत्साहन योजना के परिवर्तन (कर्मचारियों का बदलाव, वृद्धि, फिर से ठेका देने वाले का परिवर्तन आदि) की आवश्यकता, सुरक्षा उपाय की कार्यवाही की स्थिति, व्यक्तिगत अनुबंध में परिवर्तन की आवश्यकता, व्यक्तिगत अनुबंध में परिवर्तन की आवश्यकता होने पर उसकी सामग्री आदि की चर्चा करेगी, और निर्णयित मुद्दों, जारी रखने के लिए निर्धारित मुद्दों और जारी रखने के लिए मुद्दों की मौजूदगी में, चर्चा की समयसारिणी और चर्चा करने वाले पक्षों की पहचान करेगी।
(निम्नलिखित, धारा 5, 6, 7 छोड़ दी गई हैं।)
संपर्क समिति की बैठक के अस्तित्व को, अनुबंध की धाराओं में एक निश्चित मान्यता प्रदान करने, और अन्य अनियोजित बैठकों के विपरीत एक अलग अर्थ प्रदान करने का यही मुख्य बिंदु है।
संपर्क समिति को परिवर्तन प्रबंधन में उपयोग करने का मार्ग
इसके अलावा, एजाइल विकास में, दोनों पक्षों द्वारा मूल रूप से सहमत किए गए मामलों में परिवर्तन होना एक पूर्वनिर्धारित मामला होता है। इसलिए, पश्चात्ताप के विशेषज्ञ परिवर्तन की स्थिति को कैसे प्रबंधित करना है, यह भी बहुत महत्वपूर्ण होता है।
इस समय, यदि संपर्क समिति की नियमित बैठक होती है, तो परिवर्तन प्रबंधन और उसका तरीका भी बहुत सुचारु हो जाता है। उदाहरण के लिए, परिवर्तन चर्चा को संपर्क समिति में करने का निर्णय किया जाता है, और यदि एक पक्ष से परिवर्तन चर्चा की मांग होती है, तो दूसरे पक्ष को उस चर्चा में शामिल होने का अनुबंध में शामिल किया जाता है। (नीचे उद्धरण के रूप में जापानी वाणिज्य मंत्रालय मॉडल अनुबंध की प्रावधानों का उल्लेख किया गया है।)
(परिवर्तन प्रबंधन प्रक्रिया)
धारा 37 के अनुसार, पक्ष A या पक्ष B, यदि दूसरे पक्ष से (मध्यवर्ती) परिवर्तन प्रस्ताव पत्र प्राप्त करते हैं, तो वे उस प्राप्ति की तारीख से ○ दिनों के भीतर, निम्नलिखित विषयों को लिखित रूप में (जिसे ‘परिवर्तन प्रबंधन पत्र’ कहा जाता है।) दूसरे पक्ष को सौंपेंगे, और पक्ष A और पक्ष B, धारा 12 के अनुसार संपर्क समिति में उक्त परिवर्तन की स्वीकृति के बारे में चर्चा करेंगे। (नीचे, विवरण के बारे में छोड़ दिया गया है)
उपरोक्त प्रावधान के बिंदुओं को निम्नलिखित तरीके से संगठित किया जा सकता है:
- ‘परिवर्तन प्रस्ताव पत्र’ के रूप में परिवर्तन की प्रस्तुति को स्वीकार करने का तरीका एकीकृत किया गया है
- प्रस्ताव पत्र प्राप्त करने के बाद, उस पर चर्चा करने के लिए तारीख की सीमा निर्धारित की गई है → ‘◯ दिनों के भीतर’ जैसे विवरण के बिना भी, ‘तत्परता से’ जैसे शब्दों को बदलने पर विचार किया जा सकता है।
- परिवर्तन की स्वीकृति के बारे में चर्चा करने का स्थल, ‘संपर्क समिति’ की बैठक में एकीकृत किया गया है
अर्थात, ‘परिवर्तन की प्रस्तुति की गई, नहीं की गई’ या ‘परिवर्तन की स्वीकृति के बारे में उत्तर दिया गया, नहीं दिया गया’ जैसी समझ के अंतर को उत्पन्न नहीं करने के लिए, प्रक्रिया के तरीके को स्पष्ट किया गया है।
ईमानदारी के फर्ज और ईमानदारी के नियमों की समझ की जांच की जाती है
अब तक, हमने ‘संपर्क समिति’, ‘परिवर्तन वार्ता’ आदि के बारे में अनुबंध की धाराओं के मॉडल का परिचय दिया है। हालांकि, इनकी मौलिक समझ के लिए महत्वपूर्ण बात यह है कि ‘ईमानदारी के फर्ज’, ‘ईमानदारी के नियम’ जैसे मुद्दों पर ध्यान केंद्रित किया जाता है। आधारभूत रूप से, एजाइल विकास मॉडल का अनुसरण करने में आदेशकर्ता और आदेश प्राप्तकर्ता के विश्वास संबंध के बिना कठिनाई हो सकती है। इसका कारण यह है कि यह कार्य की शुरुआत की गति पर ध्यान केंद्रित करता है, और शुरुआत के लिए प्रक्रियाएं कम से कम रखी जाती हैं। इसलिए, दूसरे पक्ष पर ‘ईमानदारी के फर्ज’ की धारा शामिल करना भी व्यावसायिक रूप से आम हो जाता है।
धारा 4 अनुच्छेद 3 में परिवर्तन वार्ता में, परिवर्तन का विषय, परिवर्तन की संभावना, परिवर्तन के कारण मूल्य और समय के प्रभाव को मान्य करते हुए, परिवर्तन करने के बारे में दोनों पक्षों को ईमानदारी से विचार करना चाहिए।
यह ऐसी बातों को रोकने के लिए है जो मूल रूप से विश्वास के आधार पर आगे बढ़ रही थीं, और अचानक, ‘समझौते में परिवर्तन करने के लिए सहमत होना या नहीं, यह केवल प्रस्ताव देने वाले की स्वतंत्रता है, और इसे बाध्य करने का कोई फर्ज नहीं है’ जैसे, विधि के रूप में दूसरे को धोखा देने वाले तरीके को रोकने के लिए। सिस्टम विकास के अलावा, यह निजी व्यापार के कानूनी सिद्धांतों को भी दर्शाता है।
सिविल कोड धारा 1 अनुच्छेद 2
अधिकारों का उपयोग और फर्जों का पालन, ईमानदारी के अनुसार ईमानदारी से किया जाना चाहिए।
कानून, हमेशा ‘समझौते की लिखित सामग्री’ या ‘धारा के शब्दों’ को ही महत्व नहीं देता है। विशेष रूप से जब दूसरे पक्ष के साथ व्यापार हो, तो ‘ईमानदारी’ और ‘ईमानदारी’ को शामिल करते हुए इसका उपयोग लचीला होना चाहिए। वैसे ही, ‘फर्ज’ के रूप में कानूनी रूप से लागू की जाने वाली चीजें, जरूरी नहीं है कि ‘समझौते’ की प्रक्रिया के आधार पर हों, इस बारे में निम्नलिखित लेख में विस्तार से विवरण दिया गया है।
https://monolith.law/corporate/system-development-unlawful-responsibility[ja]
सारांश
एजाइल विकास मॉडल के आधार पर सिस्टम विकास परियोजनाओं में, कार्यालयी प्रक्रियाओं और प्रबंधन ढांचे की अनियमितता के बढ़ते जोखिम को समझना निश्चित रूप से महत्वपूर्ण है। हालांकि, यह केवल इतना ही नहीं है, ‘ईमानदारी का सिद्धांत’ जैसे कानूनी मूल्यों की लचीली विशेषताओं को समझना और उन्हें व्यावसायिक अभ्यास में लागू करने का दृष्टिकोण भी महत्वपूर्ण माना जाता है।
Category: IT
Tag: ITSystem Development