يمكن لـ Caira مراجعة عقدك في 3 نقرات:
احصل على التغييرات المقترحة والتعليقات المضافة مباشرةً إلى ملفك
أنشئ ملخصًا عبر البريد الإلكتروني لإرساله إلى الطرف الآخر
لا يستغرق التسجيل في تجربة مجانية أكثر من 30 ثانية. لا حاجة إلى بطاقة ائتمان: ابدأ تجربتك المجانية
"يعمل على جهازي": لماذا يحتاج مطورو الويب إلى عقود أفضل
يعاني عالم تطوير الويب من "فجوة التوقعات".
تسلّم كودًا يطابق المواصفات. يفتحه العميل على iPhone 6 من 2014 ويصرخ "إنه لا يعمل!"
تبني نظام إدارة المحتوى الذي طلبوه. يتصلون بك بعد ستة أشهر مطالبين بإصلاح خلل سببه إضافة قام هم بتثبيتها.
التطوير منطقي. العملاء عاطفيون. عقدك هو الجسر الوحيد بين الأمرين. من دونه، فإنك تسجّل نفسك لدعم تقني غير مدفوع طوال العمر.
فيما يلي الأخطاء القانونية التي تحتاج إلى إصلاحها في شروط العمل الخاصة بك.
1. الثقب الأسود لـ "توافق المتصفح"
السيناريو: تبني موقعًا أنيقًا باستخدام React. يعمل بسرعة على Chrome وSafari. يفتحه الرئيس التنفيذي للعميل على Internet Explorer 11 في المكتب. يتعطل تصميم الشبكة. يحجبون الدفع حتى "يعمل على كل شيء".
الواقع القانوني:
"يعمل على كل شيء" أمر مستحيل تقنيًا. من دون قائمة محددة، قد تفسر المحكمة "موقعًا وظيفيًا" على أنه "يعمل على أدوات الأعمال القياسية"، وهو ما قد يشمل المتصفحات الأقدم.
الحل:
بند المتصفحات المدعومة.
كن محددًا. "تم تصميم الموقع ليعمل على أحدث نسختين من Chrome وSafari وFirefox وEdge. ويُستثنى الالتزام بالمتصفحات القديمة (مثل IE11) ما لم يتم الاتفاق صراحةً على ذلك في المواصفات."
2. اختبار القبول (مشغل "الإطلاق")
السيناريو: تنهي الموقع. ترسل الرابط. "أخبرني ما رأيك."
صمت لمدة 3 أسابيع.
ثم: "هل يمكننا تغيير الخط؟"
ثم صمت لمدة أسبوعين.
ثم: "في الواقع، هل يمكننا نقل الشعار؟"
أنت متأخر 3 أشهر عن الموعد النهائي ولم تحصل على الدفعة النهائية البالغة 50%.
الواقع القانوني:
من دون "فترة قبول" محددة، يصبح المشروع في حالة زومبي. فهو ليس منتهيًا ولا غير منتهٍ.
الحل:
بند "القبول المفترض".
"لدى العميل 7 أيام من تاريخ التسليم لاختبار البرنامج. إذا لم يتم الإبلاغ كتابيًا عن أي 'خطأ' محدد (يُعرّف على أنه تعطل/فشل حرج) خلال 7 أيام، فسيُعتبر البرنامج مقبولًا وستكون الدفعة النهائية مستحقة."
هذا يجبرهم على فحصه، أو الدفع لك.
3. تمدد النطاق ("مجرد تغيير صغير واحد")
السيناريو: تعرض سعرًا لـ 5 صفحات. وفي منتصف التنفيذ، يرسل العميل النص النهائي. أصبح 12 صفحة. "لقد قسّمت صفحة من نحن فقط، الأمر ليس كبيرًا، أليس كذلك؟"
إنه بالفعل أمر كبير. فهو يؤثر في منطق التنقل، وتأثيرات قائمة الهاتف المحمول، ووقت إدخال المحتوى.
الحل:
توقف عن التسعير لـ "موقع إلكتروني". قدّم عرضًا لـ "نطاق عمل".
التسليمات الصارمة: "5 صفحات ثابتة. 1 نموذج تواصل."
بند التغيير: "أي طلبات محددة خارج هذا النطاق ستُحتسب وفق سعرنا الساعي القياسي البالغ £[X]. سيتوقف التطوير حتى تتم الموافقة على التغيير."*
4. من يملك الكود؟ (حقوق الملكية الفكرية)
السيناريو: تستخدم "القالب الأساسي" القياسي لديك أو مكتبة من الدوال المساعدة التي كتبتها قبل سنوات. يختلف العميل معك. ويطالبون بـ "تنازل كامل عن حقوق النشر" لجميع الكود.
إذا تنازلت عن كل شيء، فلن تتمكن قانونيًا من استخدام قالبك الأساسي للعميل التالي. لقد بعت "الأدوات"، لا "المنزل" فقط.
الحل:
فرّق بين "الكود المخصص" و"الملكية الفكرية الخلفية".
"ينقل المطور حقوق النشر في التصميم المخصص وتخطيط النص إلى العميل عند السداد الكامل."*
"يحتفظ المطور بملكية جميع 'الملكية الفكرية الخلفية' (المكتبات/الأطر القابلة لإعادة الاستخدام) ويمنح العميل ترخيصًا دائمًا وغير حصري لاستخدامها لهذا الموقع."*
5. إصلاح الأخطاء "مدى الحياة"
السيناريو: يتم إطلاق الموقع. بعد عامين، يتحدّث WordPress. يتعطل الموقع. يتصل العميل: "أنت من بنَاه، إذًا أصلحه."
الحل:
فترة الضمان.
"نوفّر فترة ضمان مدتها 30 يومًا بعد الإطلاق لإصلاح الأخطاء الموجودة عند الإطلاق. أي مشكلات تظهر بعد 30 يومًا، أو تنتج عن تحديثات الجهات الخارجية (الإضافات/تغييرات المتصفح)، تُعد صيانةً قابلةً للفوترة."
لماذا مراجعة العقد هي توثيقك
تعلّق على كودك. يجب أن تعلّق على علاقتك التجارية أيضًا.
تقوم مراجعة العقود بالذكاء الاصطناعي بتحليل اتفاقية التطوير الخاصة بك. وتتحقق مما إذا كنت قد وعدت عن طريق الخطأ بـ "الملاءمة للغرض" (وهو معيار قانوني مرتفع) بدلًا من "الخبرة والعناية المعقولتين". كما تضمن أن مسار "القبول" لديك محكم. وتساعدك على تسليم المشروع والحصول على أجره، دون ديون تقنية موروثة.
تنبيه: المعلومات الواردة في هذه المقالة هي للإرشاد العام فقط، وليست مخصصة لتكون نصيحة مهنية قانونية أو مالية أو ضريبية أو طبية.
