MONOLITH LAW OFFICE+81-3-6262-3248काम करने के दिन 10:00-18:00 JST [Englsih Only]

MONOLITH LAW MAGAZINE

IT

सिस्टम विकास में मीटिंग के नोट्स को कैसे रखें, कानूनी दृष्टिकोण से

IT

सिस्टम विकास में मीटिंग के नोट्स को कैसे रखें, कानूनी दृष्टिकोण से

जब कोई कंपनी दूसरी कंपनी को सिस्टम विकास का ठेका देती है, तो मुख्य कार्यकारी अधिकारी के बीच कानूनी मुहर से समझौता होता है, और जिम्मेदार व्यक्ति द्वारा तैयार की गई आवश्यकता परिभाषा दस्तावेज़ केवल इतना स्पष्ट नहीं होता है कि अंत में क्या और कब तक बनाना है। बहुत सारे सिस्टम विकास में, जिम्मेदार व्यक्ति के स्तर की ईमेल और फ़ोन की बातचीत, जिम्मेदार व्यक्ति के स्तर की मीटिंग आदि में, मूल रूप से अस्पष्ट थे विशेषताओं की पुष्टि, परिस्थितियों के बदलाव के अनुसार विशेषताओं का परिवर्तन, फ़ंक्शन के अतिरिक्त अनुरोध, उत्पन्न हुए समस्याओं के संबंध में सहयोग की मांग आदि रोज़ाना होती हैं।

सिस्टम विकास को सुचारू रूप से आगे बढ़ाने, और यदि किसी विवाद की स्थिति उत्पन्न होती है, तो उसके लिए तैयार रहने के दृष्टिकोण से, एक सिस्टम विकास प्रोजेक्ट को सुचारू रूप से संचालित करने के लिए, दस्तावेज़ों का निर्माण और उनका प्रबंधन महत्वपूर्ण हो जाता है।

इस लेख में, हम सिस्टम विकास की प्रगति की बैठकों के लिए बैठक के मिनट्स और बैठक सामग्री को कैसे रखना है, इसके बारे में कानूनी दृष्टिकोण से विवरण देंगे।

सिस्टम विकास में दस्तावेज़ प्रबंधन क्यों महत्वपूर्ण है

सिस्टम विकास परियोजनाओं में, सत्यापन सभाओं में हुई बातचीत और परियोजना की प्रगति और प्रक्रिया के बारे में रिकॉर्ड रखना, कानूनी दृष्टिकोण से देखने पर बहुत महत्वपूर्ण होता है। इसके पीछे के कारणों में निम्नलिखित दो बिंदुओं को उठाया जा सकता है।

बाद में मतभेद ना उत्पन्न होने के लिए

सिस्टम विकास आमतौर पर एक परियोजना होती है जो उपयोगकर्ता और विक्रेता दोनों के लिए कई पक्षों को शामिल करती है। इसलिए, उपयोगकर्ता और विक्रेता दोनों के बीच में, दोनों ने कितनी भूमिका निभाई है और क्या कर्तव्य स्वीकार किया है, इस बारे में दोनों की समझ में अंतर होने पर, परियोजना की आगे की प्रगति में बाधा आ सकती है।

इसके अलावा, कई लोगों की सहभागिता वाली परियोजना होने के कारण, यदि हम दृष्टिकोण बदलें, तो “लोगों द्वारा कही गई बातें थोड़ी अलग होती हैं, और कौन सही है, यह समझना मुश्किल होता है” जैसी संचार समस्याएं आमतौर पर होती हैं।

दोनों पक्षों की समझ में कोई अंतर नहीं है, इसकी जांच करने के लिए भी, बनाए गए समझौते की सामग्री को मुद्रित रूप में संग्रहित करना महत्वपूर्ण होता है, और साथ ही सभी संबंधित पक्षों को (प्रत्येक व्यक्ति के अनुसार) एक ही दस्तावेज़ की समीक्षा करने की क्षमता देता है, जो सभी संबंधित पक्षों के कदम मिलाने में मदद करता है।

वैसे, विवाद की संभावना को पहले से ही रोकने के लिए कानूनी ज्ञान का उपयोग करने की प्रक्रिया को कभी-कभी प्राथमिक कानूनी उपाय कहा जाता है।

बाद में विवाद उत्पन्न होने पर उपाय के रूप में

इसके अलावा, पहले के प्राथमिक कानूनी दृष्टिकोण से थोड़ा अलग होने पर भी, दस्तावेज़ प्रबंधन के महत्व को समझाने के लिए, फिर भी वास्तव में विवाद के रूप में स्थिति का सामना करने के लिए, “संकट प्रबंधन” का बिंदु उठाया जा सकता है।

किसी भी प्रकार की समस्या उत्पन्न होने पर, यदि परिणामस्वरूप बनने से पहले परियोजना रुक जाती है, या यदि मूल डेडलाइन के अनुसार काम नहीं होता है, तो यदि हम कोर्ट के मामले की स्थिति का सामना करने की स्थिति का अनुमान लगाते हैं। उपयोगकर्ता और विक्रेता दोनों के लिए यह कहना सही होगा कि “जो स्थिति उत्पन्न हुई है, उसके लिए मेरी तरफ से भी कुछ कहने की बात है”, लेकिन यदि रिकॉर्ड लिखित रूप में नहीं है, तो आप अपने पक्ष को साबित करने में सक्षम नहीं होंगे और आपको कोर्ट में भी अनुकूल नहीं मिलेगा।

विशेष रूप से “समय पर नहीं होने” के कारण उत्पन्न हुई समस्याओं में, उसके कारण के बारे में, “कब और कैसे समस्या का पता चला”, “किस समय में विशेषताओं में परिवर्तन का अनुरोध किया गया”, “उपयोगकर्ता द्वारा फ़ंक्शन जोड़ने के अनुरोध के प्रति, विक्रेता ने कैसा प्रतिक्रिया किया” जैसे बिंदु, कई बार महत्वपूर्ण विवादित मुद्दे बन जाते हैं जो कोर्ट के निर्णय को प्रभावित कर सकते हैं। इस संदर्भ में, यदि “मैंने कहा, मैंने नहीं कहा” जैसी समस्याएं बहुत उत्पन्न होती हैं, तो निष्पक्ष विवाद समाधान की उम्मीद कम हो जाती है।

सिस्टम विकास सभाओं की मीटिंग के रूप में विशेष रूप से महत्वपूर्ण क्या है

हम सिस्टम विकास परियोजनाओं में मीटिंग के नोट्स कैसे रखें, इसके बारे में विवरण देंगे।

सिस्टम विकास में सभाओं के प्रकार

सिस्टम विकास की परियोजनाओं में, विभिन्न सभाएं समय-समय पर आयोजित की जाती हैं। यह बात स्वयं में, बड़ी संख्या में लोगों की सहभागिता वाली परियोजना होने के नजरिए से, अद्भुत नहीं होगी। प्रोग्राम का कार्यान्वयन विकास स्थल पर करने वाले प्रोग्रामर और इंजीनियर भी, नियमित रूप से कार्य की प्रगति की स्थिति की जांच करने के लिए समीक्षा सभाएं आयोजित करते हैं। इसके अलावा, कार्यान्वित कोड के प्रति, रखरखाव और सुरक्षा पहलुओं में कमजोरियाँ आदि की समस्याएं नहीं हैं, इसकी जांच करने के लिए, वास्तविक कोड को देखते हुए समीक्षा आदि करने की स्थिति भी हो सकती है।

इसके अलावा, इन विकास स्थलों पर जिम्मेदारी स्तर की सभाओं के अलावा, कंपनी के निदेशक या अधिकार वाले जिम्मेदार लोग भी सभाओं में शामिल होते हैं। इस मामले में, विकास परियोजना में समग्र दिशा और नीति को निर्धारित करने वाली सभाएं हो सकती हैं। इन जिम्मेदारी स्तर की, महत्वपूर्ण मुद्दों को ‘समझने’ के लिए सभाओं को स्टीयरिंग कमेटी भी कहा जाता है।

विशेष रूप से सतर्क रहने वाली सभा स्टीयरिंग कमेटी है

सिस्टम विकास के क्षेत्र में, लोगों की स्थिति के अनुसार, और उद्देश्य के अनुसार विभिन्न सभाएं आयोजित की जाती हैं, जैसा कि पहले उल्लेख किया गया है, लेकिन कानूनी दृष्टिकोण से इसमें से विशेष रूप से महत्वपूर्ण सभा, स्टीयरिंग कमेटी है। जिम्मेदारी स्तर की प्रगति की समीक्षा सभाओं और समीक्षा सभाओं की तुलना में, स्टीयरिंग कमेटी विवादों की रोकथाम और, विवाद के समय की योजनाओं के दृष्टिकोण से विशेष रूप से, दस्तावेजीकरण की महत्वपूर्णता को ठीक से समझने वाली चीज है। इस तरह कहने के लिए कारण हैं,

  1. स्टीयरिंग कमेटी जिम्मेदारी स्तर के लोगों द्वारा आयोजित सभा होने के नाते, महत्वपूर्ण निर्णयों से जुड़ी सभाएं होती हैं, और उपयोगकर्ता और विक्रेता दोनों की पहचान क्या है, इसे दर्शाने वाली चीज के रूप में, कानूनी बात के रूप में भी महत्वपूर्ण माना जाता है।
  2. जिम्मेदारी स्तर की सभाएं होने पर सामान्यतः, उस सभा की सामग्री अधिकांशतः, विभिन्न डिजाइन दस्तावेजों और विशेषता दस्तावेजों में, बाद में प्रतिबिंबित होती है, और मूल रूप से ‘दस्तावेज़ अनुपस्थिति’ जैसी समस्या उत्पन्न होने की संभावना वास्तविक रूप से कम होती है। (हालांकि, यदि इनमें से किसी पर भी दस्तावेजीकरण हल्का है, तो उसमें भी सुधार की आवश्यकता हो सकती है।)

इस प्रकार के बिंदु उठा सकते हैं।

स्टीयरिंग कमेटी की मीटिंग के मिनट्स से संबंधित न्यायिक प्रकरण

नीचे, हम एक मामले का उल्लेख कर रहे हैं जिसमें स्टीयरिंग कमेटी की मीटिंग के मिनट्स को वास्तविक न्यायाधीनता में महत्वपूर्ण साक्ष्य के रूप में देखा गया था। निम्नलिखित निर्णय में उद्धृत मामला, सिस्टम विकास परियोजना के बीच में असफल होने के संबंध में है, जिसमें विक्रेता की प्रोजेक्ट प्रबंधन की कर्तव्य उल्लंघन को मान्यता दी गई थी। मीटिंग के मिनट्स की सामग्री ने, विक्रेता और उपयोगकर्ता दोनों के प्रारंभिक समझ को दर्शाने के रूप में, न्यायाधीनता में भी बहुत बड़ा अर्थ रखा।

विक्रेता ने, स्टीयरिंग कमेटी की मीटिंग के मिनट्स के आधार पर इस सिस्टम विकास की प्रगति को मान्यता देने के बारे में, यह संकेत दिया कि मिनट्स की सामग्री को उपयोगकर्ता द्वारा संशोधित किया गया था, और यह कार्य आदि की वास्तविक स्थिति को अवश्य ही प्रतिबिंबित नहीं करता है। हालांकि, स्टीयरिंग कमेटी का गठन इस सिस्टम विकास के ऊपरी प्रबंधन स्तर पर निर्णय लेने के उद्देश्य से किया गया था, और विक्रेता और उपयोगकर्ता दोनों ने, इस सिस्टम विकास के कार्यान्वयन के लिए जिम्मेदार व्यक्ति को शामिल किया, और उन्होंने उसका समग्र मूल्यांकन, अनुसूची, कार्य प्रगति की वास्तविक स्थिति, साझा करने के लिए मुद्दे, महत्वपूर्ण मुद्दों के निर्णय आदि किया। और, वहां चर्चा किए गए मुख्य बिंदुओं के बारे में, विक्रेता ने मीटिंग के अगले-अगले कार्य दिवस की सुबह तक मिनट्स तैयार किए, और उन्होंने मिनट्स डेटाबेस में पंजीकृत किए, और उन्होंने मिनट्स के माध्यम से मीटिंग के अंतिम निर्णय को रिकॉर्ड करने का निर्णय लिया। मिनट्स को स्थायी बनाने के लिए, विक्रेता और उपयोगकर्ता ने, मिनट्स के माध्यम से कार्य को रिकॉर्ड करने के महत्व को पूरी तरह से समझते हुए, उसकी सामग्री और अभिव्यक्ति का अध्ययन किया, और मीटिंग की वास्तविक स्थिति को प्रतिबिंबित करने वाले, उसकी सामग्री को स्थायी बनाया। विशेष रूप से, विक्रेता ने सिस्टम विकास का कारोबार किया, और इस प्रकार के मिनट्स निर्माण के महत्व और तरीके को वह स्वाभाविक रूप से जानता था। इसलिए, स्थायी मिनट्स को, स्टीयरिंग कमेटी की वास्तविक कार्य स्थिति को प्रतिबिंबित करने वाले के रूप में देखा जाना उचित है, और विशेष परिस्थितियाँ मान्य नहीं होने तक, कार्य की प्रगति आदि के बारे में, वहां उल्लिखित सामग्री को स्टीयरिंग कमेटी में उस तिथि के रूप में संक्षेपित माना जाना उचित है।

टोक्यो हाई कोर्ट, 26 सितंबर, हेसी 25 (2013)

न्यायालय का दृष्टिकोण यह है कि यदि विक्रेता और उपयोगकर्ता दोनों ने मिलकर बैठक के लिखित मिनट्स तैयार किए हैं, तो उन्हें ‘साक्ष्य’ के रूप में एक निश्चित अनुमानित शक्ति माना जा सकता है। दूसरे दृष्टिकोण से देखें, तो यदि मिनट्स में बहुत आसानी से उल्लेख किया जाता है, तो उसका जोखिम यह है कि वह सीधे साक्ष्य बन जाता है, और इस बात का ध्यान रखना चाहिए कि इसे पूरी तरह से ध्यान में रखना चाहिए।

बैठक की कार्यवाही में कौन से विषयों को विशेष रूप से दर्ज करना चाहिए

बैठक की कार्यवाही में कौन से विषयों को लिखित रूप में दर्ज करना चाहिए?

बैठक की कार्यवाही, चाहे वह न्यायिक मामले में साक्ष्य के रूप में हो या फिर बिना न्यायिक मामले के, पक्षों के बीच सुचारू रूप से आगे की वार्ता को आगे बढ़ाने में, महत्वपूर्ण भूमिका निभाती है। तो, विशेष रूप से, बैठक की कार्यवाही में हमें क्या लिखित रूप में दर्ज करना चाहिए? नीचे हम इसे व्यवस्थित कर रहे हैं।

विक्रेता की दृष्टि से दर्ज करने योग्य विषय

विक्रेता को प्रोजेक्ट के प्रति, सिस्टम विकास के विशेषज्ञ के रूप में प्रोजेक्ट प्रबंधन की जिम्मेदारी होती है। इस जिम्मेदारी के बारे में विस्तार से निम्नलिखित लेख में विवरण दिया गया है।

https://monolith.law/corporate/project-management-duties[ja]

इस जिम्मेदारी को ध्यान में रखते हुए, विक्रेता के द्वारा विशेष रूप से दर्ज करने योग्य बातें हैं,

  1. प्रत्येक विकास प्रक्रिया का समापन होने का तथ्य और उसकी तारीख
  2. उपयोगकर्ता की ओर से प्राप्त हुए विशेषताओं के परिवर्तन या फंक्शन के जोड़ने जैसे अनुरोधों का उत्तर देने का इतिहास
  3. उपयोगकर्ता की स्वयं की सुविधा के कारण, विकास कार्य की प्रगति में बाधा होने पर, सहयोग की मांग करने के लिए उठाए गए कदम और उसका विवरण

इनमें से कुछ उदाहरण दिए जा सकते हैं।

वैसे, उपरोक्त 3. बिंदु के संबंध में यदि हम विस्तार से बताएं, तो उदाहरण के लिए, यदि उपयोगकर्ता द्वारा स्वीकृति नहीं दी जाती है, तो विक्रेता द्वारा विचार करने योग्य विषयों के बारे में निम्नलिखित लेख में विवरण दिया गया है। निम्नलिखित लेख में, विक्रेता ने उपयोगकर्ता की स्वीकृति के लिए कितना सहयोगी रहा, इस पर न्यायालय का निर्णय कितना बदल सकता है, इसका विवरण वास्तविक निर्णय पाठ के साथ दिया गया है।

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

उपयोगकर्ता की दृष्टि से दर्ज करने योग्य विषय

स्वाभाविक रूप से, उपयोगकर्ता भी अपनी कंपनी के अंदर उपयोग होने वाले सिस्टम के लिए, सिस्टम विकास में विक्रेता के विकास कार्य के प्रति कुछ सहयोग की जिम्मेदारी लेता है। इस जिम्मेदारी के बारे में सम्पूर्ण विवरण निम्नलिखित लेख में दिया गया है।

https://monolith.law/corporate/user-obligatory-cooporation[ja]

  1. चाहिए विशेषताएं, स्क्रीन की बाहरी दिखावट आदि, उपयोगकर्ता द्वारा विक्रेता को बताने योग्य बातों का इतिहास
  2. विक्रेता की प्रक्रिया में उत्पन्न हुए विभिन्न समस्याओं का इतिहास (उदाहरण के लिए, सदस्यों का अचानक निवास या, विक्रेता की अध्ययन की कमी के कारण उत्पन्न हुए विकास प्रक्रिया की समय सारणी में देरी और उसके कारण आदि)

उपरोक्त 2. बिंदु से संबंधित, विशेष रूप से अनपेक्षित समस्याओं में विकास की संभावना होती है, जब पुराने सिस्टम को हटाकर नए सिस्टम का विकास किया जाता है। पुराने सिस्टम के डेटा को नए सिस्टम में स्थानांतरित करते समय विशेष रूप से समस्याएं उत्पन्न होती हैं, लेकिन इस तरह की समस्याओं से जुड़े कानूनी मुद्दों का विस्तृत विवेकन निम्नलिखित लेख में किया गया है।

सारांश

उपरोक्त, सिस्टम विकास के क्षेत्र में बैठक के रिकॉर्ड रखने के तरीके के नियमों का कानूनी दृष्टिकोण से विवेचन है। व्यावहारिक हाउ-टू के साथ-साथ, ‘कानून’, ‘सिस्टम विकास’, ‘दस्तावेज़ प्रबंधन’ जैसे विषयों के संबंध के प्रति समझ बढ़ाना भी महत्वपूर्ण होगा। सिस्टम विकास एक ऐसी चीज़ है जो कई लोगों और संगठनों को शामिल करती है, और यह बड़े पैमाने पर वाणिज्यिक लेन-देन में विकसित होने की प्रवृत्ति रखती है, इसलिए इससे संबंधित विवादों की रोकथाम और उपाय करना महत्वपूर्ण होता है। और, कानूनी दृष्टिकोण से देखने पर, सबूत की सुरक्षा की आवश्यकता से, ‘दस्तावेज़’ की मौजूदगी का बड़ा महत्व होता है, जिसे किसी भी व्यक्ति द्वारा वस्तुनिष्ठ रूप से जांचा जा सकता है।

निश्चित रूप से, सभी विमर्शों और परियोजनाओं के प्रवाह को पूरी तरह से भाषांतरित करना एक बड़ा बोझ हो सकता है, और यह वास्तविक रूप से संभव भी नहीं हो सकता। हालांकि, कानूनी दृष्टिकोण से महत्वपूर्ण मुद्दों को पहचानना, और फिर महत्वपूर्ण मुद्दों को उचित रूप से दस्तावेजीकृत करना महत्वपूर्ण है, यह बात कानून के विशेषज्ञ होने या न होने के बावजूद, व्यापार से जुड़े सभी लोगों द्वारा व्यापक रूप से समझी जानी चाहिए।

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

ऊपर लौटें