प्रोजेक्ट समझौता क्या है और यह क्यों महत्वपूर्ण है

प्रोजेक्ट एग्रीमेंट क्या है

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

प्रोजेक्ट एग्रीमेंट महत्वपूर्ण है क्योंकि यह एक हाथ मिलाने को एक रिकॉर्ड में बदल देता है। यदि एक ग्राहक एक लोगो, एक लैंडिंग पेज, या एक अनुवाद पैकेज मांगता है, तो एग्रीमेंट में यह कहा जाना चाहिए कि कौन से फाइलें शामिल हैं और कौन सी नहीं। यह बुनियादी लगता है। यह बाद में बहसों को बचाता है।

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

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

हस्ताक्षर करने से पहले कानूनी समीक्षा क्यों महत्वपूर्ण है

समीक्षा के बिना हस्ताक्षर करने से तीन सामान्य समस्याएँ उत्पन्न हो सकती हैं: अस्पष्ट दायरा, भुगतान विवाद, और देयता जोखिम। इनमें से प्रत्येक वास्तविक कार्य में प्रकट होता है, केवल अदालत की कहानियों में नहीं। एक ग्राहक सोच सकता है कि "वेबसाइट" का मतलब 12 पृष्ठ हैं, एक सामग्री लेखक सोच सकता है कि "ब्लॉग पैकेज" का मतलब 4 लेख हैं, और एक फ्रीलांसर यह जान सकता है कि इनमें से कोई भी धारणा लिखित नहीं है।

भुगतान विवाद आमतौर पर उबाऊ होते हैं जब तक कि वे नहीं होते। एक ग्राहक भुगतान में देरी कर सकता है क्योंकि कोई मील का पत्थर कभी परिभाषित नहीं किया गया था। एक फ्रीलांसर काम रोक सकता है क्योंकि चालान में एक बात कही गई है और समझौते में दूसरी। यही वह प्रकार का असंगति है जो 3-दिन की देरी को 3-सप्ताह के विवाद में बदल देती है।

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

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

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

शामिल करने के लिए प्रमुख धाराएँ

काम का दायरा पहले आता है। इसे साधारण शब्दों में कार्य का वर्णन करना चाहिए और अपवादों के साथ-साथ समावेशों की सूची बनानी चाहिए। यदि ग्राहक 10 उत्पाद विवरण चाहता है, तो 10 कहें। यदि सोशल मीडिया कैप्शन काम का हिस्सा नहीं हैं, तो वह भी कहें। "संबंधित कार्य" एक जाल बन सकता है।

डिलीवर करने योग्य चीज़ों को इस तरह नामित किया जाना चाहिए कि एक अजनबी उन्हें पहचान सके। एक लोगो पैकेज में PNG, SVG, और स्रोत फ़ाइलें शामिल हो सकती हैं। एक रिपोर्ट में एक PDF और एक संपादनीय संस्करण शामिल हो सकता है। एक डेवलपर को स्टेजिंग एक्सेस, डिप्लॉयमेंट नोट्स, और एक हैंडओवर कॉल की आवश्यकता हो सकती है। संख्याएँ मदद करती हैं।

समय सीमा को एक अस्पष्ट वादा से अधिक की आवश्यकता होती है। "जितनी जल्दी हो सके" एक समय सीमा नहीं है। "18 अप्रैल तक" है। यदि परियोजना में 3 मील का पत्थर हैं, तो प्रत्येक में एक तारीख या एक शर्त होनी चाहिए जो अगले चरण को सक्रिय करती है। यह सामान्य "मुझे लगा कि आप अगले सप्ताह का मतलब है" समस्या को रोकता है।

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

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

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

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

बौद्धिक संपत्ति और स्वामित्व

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

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

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

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

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

गोपनीयता और डेटा सुरक्षा

गोपनीयता धाराएँ आमतौर पर व्यापार योजनाओं, पासवर्ड, ग्राहक सूचियों, उत्पाद विशिष्टताओं और किसी भी चीज़ को कवर करती हैं जिसे निजी के रूप में चिह्नित किया गया है। उन्हें यह भी बताना चाहिए कि यह दायित्व परियोजना समाप्त होने के बाद कितने समय तक चलता है। एक महीना 2 वर्षों के समान नहीं है। यदि समझौता मौन है, तो भ्रम का जोखिम बढ़ जाता है।

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

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

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

यदि परियोजना सार्वजनिक-फेसिंग उपकरणों या साझा होस्टिंग से संबंधित है, तो क्लाउड स्टोरेज जल्दी ही तस्वीर में आ सकता है। एक संक्षिप्त समीक्षाक्लाउड कंप्यूटिंग तकनीकस्टोरेज प्रश्न को फ्रेम करने में मदद कर सकता है, लेकिन अनुबंध को अभी भी वास्तविक नियमों की आवश्यकता है।

जिम्मेदारी, वारंटी, और क्षतिपूर्ति

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

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

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

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

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

शासन कानून और विवाद समाधान

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

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

मध्यस्थता और मध्यस्थता सामान्य विकल्प हैं। मध्यस्थता एक तटस्थ तीसरे पक्ष के साथ मुद्दे को सुलझाने की कोशिश करती है। मध्यस्थता एक सार्वजनिक अदालत के बजाय एक निजी निर्णय लेने वाले का उपयोग करती है। प्रत्येक मार्ग के अपने व्यापारिक समझौते होते हैं। मध्यस्थता अक्सर सस्ती होती है। मध्यस्थता तेज हो सकती है, लेकिन यह अपीलों को सीमित कर सकती है।

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

सीमाओं के पार ग्राहकों के साथ काम करने वाले फ्रीलांसरों के लिए, पढ़ना 24freelance.pro साइट के नियम। फ्रीलांसप्लेटफ़ॉर्म की शर्तों को अनुबंध की शर्तों से अलग रखने में मदद कर सकता है। साइट के नियम परियोजना समझौते के समान नहीं हैं, और यह भेद महत्वपूर्ण है।

आपके हस्ताक्षर करने से पहले व्यावहारिक कदम

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

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

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

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

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