डिजिटल अनुबंध: वकीलों के लिए एक त्वरित गाइड

यह सामग्री डिजिटल परियोजना प्रबंधन पाठ्यक्रम का एक छोटा सा हिस्सा है , और मुख्य रूप से परियोजना प्रबंधकों, खाता प्रबंधकों और एजेंसी प्रबंधकों के लिए उपयोगी होगी।

हमने अपने अनुभव को अच्छे कारण के साथ साझा करने का फैसला किया: उद्योग के सहयोगियों और स्व-भरवां धक्कों से अप्रिय मामले बताते हैं कि यह विषय कई (और न केवल आईटी में) के लिए एक व्यथा बिंदु है। उस सामग्री में पढ़ें, जो संरचना को चुनने के लिए अनुबंध पर काम करती है जब SCRUM (और क्यों), और सबसे महत्वपूर्ण बात, ग्राहक के वकीलों के साथ इसका बचाव कैसे करें। सहमत होने पर जीवन हैक, 5 एहतियाती नियम, वास्तविक कहानियों के एक जोड़े, साथ ही अंदर से सिबिरिक्स स्टूडियो में वर्कफ़्लो प्रक्रिया - यहां।

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

लगभग 8 साल पहले हमने SCRUM पर काम करना शुरू किया - वेब डेवलपमेंट में पहला (एक होलीवर के साथ एक अलग पोस्ट इस कारण से पहले से ही आर्काइव में है;)। यह बहुत अच्छा था, लेकिन हमारे परिचित और आरामदायक अनुबंध टेम्पलेट नई प्रक्रियाओं के साथ अच्छी तरह से फिट नहीं थे।

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



इस टेम्प्लेट में, हमने धीरे-धीरे बदलाव और परिवर्धन किए, जो हम भरे हुए सभी धक्कों के आधार पर करते हैं। यह धीरे-धीरे बढ़ता गया, पढ़ना और समझना मुश्किल हो गया। यह जाँच, संशोधन, समन्वय करने के लिए अभद्र रूप से बहुत समय तक जाने लगा। प्रश्न उठता है: "क्या हमें एक वकील की आवश्यकता है?"

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

उदाहरण के लिए:

• एक नया अनुबंध हमेशा एक टेम्पलेट से तैयार किया जाना चाहिए, न कि पिछले ग्राहक से अनुबंध से। दस्तावेजों में किसी और के नाम के लिए माफी मांगना पहले से ही अप्रिय है, लेकिन एनडीए पर अभी भी काम कर रहे हैं ...।
• वे स्थान जहां डेटा बदल सकते हैं, रंग में हाइलाइट किए जाते हैं: यह वास्तव में टेम्पलेट्स से दस्तावेज़ तैयार करते समय 20 प्रतिशत समय बचाता है।
• ग्राहक को अनुबंध भेजने से पहले, किसी भी मामले में, इसे फिर से जांचना होगा। और बहुत वांछनीय है - एक अलग व्यक्ति। समस्या यह है कि ऐसा व्यक्ति आमतौर पर कंपनी में अकेला होता है। और कई दस्तावेज हो सकते हैं (उदाहरण के लिए, हमारे पास एक वर्ष में 400 से अधिक हैं)।
• और न केवल - नियम वास्तव में बड़े हैं।

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

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

1. प्रक्रिया शोधन। अधिकांश अक्सर ग्राहक की ओर से परियोजना प्रबंधकों से आते हैं। आमतौर पर यह एक बार फिर आपको यह बताने के लिए पर्याप्त है कि काम इस तरह क्यों बनाया जाएगा और अन्यथा नहीं और यह क्लाइंट को क्या लाभ देता है।
2. "बाहर दस्तक" अधिक अनुकूल परिस्थितियों। संपादन के अधिक पुनरावृत्तियों, कम समय, कम कीमत। क्या करें? सामान्य ज्ञान से कनेक्ट करें, यह दिखाएं कि लागत और समय सीधे जटिलता पर निर्भर करते हैं। हमें संपादन के अधिक पुनरावृत्तियों की आवश्यकता है - ठीक है, लेकिन इसमें अधिक धन और दिन लगेंगे। यह सस्ता होना चाहिए - हम काम के दायरे को कम करते हैं: आप हमेशा कुछ कार्यों को बजट से बाहर फेंक सकते हैं। मुफ्त का काम पाप है।
3. ग्राहक के वकीलों से संदर्भ। कई, अधिक सटीक रूप से, MANY हैं। विशेष रूप से उन मामलों में जब वकील कुछ वास्तविक समस्या को हल करने की कोशिश नहीं कर रहे हैं, लेकिन काम की उपस्थिति बनाने के लिए। संपादन बहुत तर्कसंगत और समझ में नहीं आ सकता है। आइए देखें कि न्यूनतम नुकसान के साथ दस्तावेजों के समन्वय के लिए इसके साथ कैसे काम करें।

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


हमारे टेम्पलेट्स में, ऐसे आइटम हाइलाइट किए गए हैं, और प्रबंधक उन पर स्वतंत्र रूप से निर्णय ले सकते हैं।

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

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

तुलना - वकील इस शब्द पर सहमत नहीं थे:

ग्राहक ठेकेदार को अपने नाम (नाम), लोगो, ट्रेडमार्क, पोर्टफोलियो में वाणिज्यिक पदनाम और ठेकेदार की सूचना सामग्री का उपयोग करने का अधिकार प्रदान करता है। ग्राहक ठेकेदार को अधिकार देता है
समझौते के तहत सभी कार्यों के परिणामों की घोषणा करने के लिए।

और यह एक याद किया गया था:

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

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

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

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

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

सुधारों को समन्वित करने के लिए लिपियों के अलावा, हमारे नियमों में कई एहतियाती नियम हैं जो किसी भी उद्योग में उपयोगी होंगे:

नियम 1. वर्ड में कोई दस्तावेज नहीं। हम Google में संपादन मोड में ग्राहक को दस्तावेज़ देते हैं, या (यदि ग्राहक के वकीलों को एक फ़ाइल की आवश्यकता है) एक पीडीएफ फाइल। असहमत परिवर्तनों की उपस्थिति के लिए वर्ड से पाठ की पूरी तरह से जांच करने की तुलना में Google के असहमति के प्रोटोकॉल से अंक स्थानांतरित करना आसान है।

नियम 2. दस्तावेजों को सत्यापित करें। ऐसा होता है कि ग्राहक संपादन मोड में 2-3 संपादन जोड़ते हैं, और बाकी चुपचाप बनाते हैं, इस उम्मीद में कि कोई भी नोटिस नहीं करेगा। हमारे पास दो ऐसे मामले थे: शर्तें, मात्राएं और प्रक्रियाएं बदल गईं।

नियम 3. ग्राहक से मूल संस्करणों की जाँच करें। वे अचानक दस्तावेज़ से सहमत से भिन्न हो सकते हैं। दुर्भाग्य से, हमारे व्यवहार में, ऐसा विकल्प कई बार मिला है।

नियम 4. यदि सामान्य निदेशक द्वारा अनुबंध पर हस्ताक्षर नहीं किए गए थे, तो पावर ऑफ अटॉर्नी की मांग करें। और जांचें कि यह समाप्त नहीं हुआ है। अन्यथा, अदालत में, अनुबंध को अमान्य घोषित किया जा सकता है, और इससे कोई फर्क नहीं पड़ता कि आप अपना काम कितना अच्छा करते हैं, आपको पैसे वापस करने होंगे। मामला काल्पनिक नहीं है (सहकर्मी साझा)।

नियम 5. हस्ताक्षर सत्यापित करें। किसी विशिष्ट दस्तावेज़ पर हस्ताक्षर को फ्रेमवर्क एग्रीमेंट में हस्ताक्षर मॉडल के साथ मेल खाना चाहिए (और कंपनी के घटक दस्तावेजों में, आप उनकी प्रतियों के लिए समकक्षों से पूछते हैं, ठीक है?) और हस्ताक्षरकर्ता के नाम के साथ सामान्य रूप से कुछ है। संदिग्ध हस्ताक्षर के कारण, दस्तावेजों को अमान्य भी किया जा सकता है।

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

मास्टर कॉन्ट्रैक्ट के टेम्प्लेट और उसके एनेक्स को यहाँ डाउनलोड किया जा सकता है ।