سبعة بنود يجب أن تكون في عقد تطوير البرمجيات

معظم نزاعات تطوير البرمجيات تعود إلى شيء لم يُكتب قط، لا إلى شيء جرى انتهاكه. العقد لم يذكر لمن يعود الكود بعد انفصال في منتصف المشروع، فلا أحد مخطئ تقنياً - والجميع عالق.

إليك البنود السبعة التي تمنع ذلك.

الإجابة المختصرة

سبعة بنود، والصياغة المحددة في كل منها أهم من مجرد وجود بند بهذا العنوان.

ملكية الكود والملكية الفكرية مع تاريخ محفّز

أهم بند، وأكثرها كتابةً بصيغة غامضة، عمداً أو سهواً.

"يملك العميل جميع مخرجات العمل" يبدو محمياً. لكنه ليس كذلك دون محفّز: يملكها اعتباراً من متى؟ بعض العقود تنقل الملكية فقط "عند اكتمال الارتباط" - وهو ما يصبح مشكلة حقيقية إن انتهت العلاقة في الشهر الثاني من بناء يمتد أربعة أشهر، لأن لا شيء اكتمل تقنياً.

ما تبحث عنه بدلاً من ذلك: انتقال الملكية عند كل دفعة مرحلية، أو فور الإنشاء مع ترخيص عكسي للمطوّر لأغراض ملف الأعمال. كلاهما ينجح. أما التوقيت الغامض فلا.

استثناءات نطاق صريحة

كتبنا سابقاً عن سبب حاجة مستند النطاق إلى قسم استثناءات، ويجب أن يحمل العقد التحديد نفسه لا مجرد إشارة عابرة إليه.

"تطوير الـ MVP كما هو موصوف في النطاق المرفق" أضعف مما يبدو إن لم يسرد النطاق المرفق نفسه ما هو مستثنى - تكاليف واجهات برمجية خارجية، كتابة المحتوى، ترحيل البيانات، الدعم بعد فترة محددة. وبدون تلك القائمة يعود كل طرف إلى افتراضاته، ونادراً ما تتطابق الافتراضات.

دفع قائم على المراحل لا على التقويم

جدول الدفع المرتبط بالتواريخ - صافي 30 يوماً، ثم بعد 30 يوماً، ثم بعد 30 يوماً أخرى - يدفع سواء سُلّم شيء أم لا. وهذا يسلبك نقطة النفوذ الحقيقية الوحيدة إن تأخر المشروع.

أما الجدول المرتبط بمراحل الإنجاز - تدفق تسجيل دخول يعمل، معاملة أساسية تعمل من البداية للنهاية، لوحة إدارة تعمل - فلا يُفرج عن الدفع إلا مقابل شيء يمكنك التحقق منه فعلاً. هذا التغيير وحده يحمي العميل أكثر من أي بند آخر في العقد تقريباً.

إجراء محدد لطلبات التغيير

سيتغيّر النطاق. والعقد الذي لا يبيّن كيف يقول ضمنياً "سنتدبّر الأمر حين يحدث"، وهذا يخدم من يملك نفوذاً أكبر في تلك اللحظة - وعادةً ليس أنت، في منتصف المشروع، حين يكون تبديل الشريك مكلفاً.

يجب أن ينص البند بوضوح: طلب التغيير خارج النطاق المحدد يُقدَّر ويُسعَّر بشكل منفصل وكتابياً قبل بدء العمل عليه. وهذا يحمي الطرفين - فالمطوّر لا يستوعب زحف نطاق مجانياً، وأنت لا تكتشف فاتورة مفاجئة لشيء ظننته مشمولاً.

نافذة دعم محددة ومحدودة صراحةً

"الدعم بعد الإطلاق مشمول" ليس بنداً بل عبارة. محدود كيف - لكم يوماً، وأي نوع من المشكلات يغطي، وبأي زمن استجابة؟

ثلاثون يوماً من إصلاح الأخطاء في الوظائف القائمة أساس معقول وشائع. وأي شيء بعد ذلك - ميزات جديدة، صيانة مستمرة، أزمنة استجابة ذات أولوية - ينبغي أن يكون اشتراكاً منفصلاً ومسعّراً منصوصاً عليه في العقد أو في اتفاق مرتبط، لا افتراضاً يقوم به كل طرف بصمت.

شروط الإنهاء والخروج

يجب أن يجيب كل عقد كتابياً، قبل الحاجة إليه: ماذا يحدث إن أراد أحد الطرفين الخروج قبل انتهاء المشروع؟

كحد أدنى: مدة الإشعار، وما يُستحق مقابل العمل المنجز حتى تلك النقطة، وتأكيد أن شروط الملكية (انظر البند الأول) تنطبق بنظافة عند الإنهاء المبكر أيضاً - لا عند النهاية الناجحة فقط. العقد الذي يصف فقط ما يحدث عند اكتمال نظيف لم يخطط للسيناريو الأكثر احتمالاً للتسبب في نزاع.

السرية وعدم إعادة الاستخدام

معيار في معظم العقود المهنية، لكن يستحق التحقق من الشيء المحدد الذي يفترض المؤسسون أنه مشمول وغالباً ليس كذلك: بند يمنع المطوّر من إعادة استخدام منطق عملك المحدد أو بياناتك أو نهجك الخاص في مشروع عميل آخر، لا مجرد سرية عامة بعدم مناقشة عملك علناً.

اتفاقيات عدم الإفصاح العامة تغطي الكتمان. أما هذا البند فيغطي إعادة الاستخدام، وهي النسخة التي تهم فعلاً إن كانت قيمة منتجك في كيفية عمل شيء ما، لا في مجرد وجوده.

ماذا تفعل إن غابت هذه البنود عن العقد

معظمها إضافات لا إعادة صياغة. والشريك الذي يقاوم بشدة إضافة تواريخ ملكية واضحة أو دفعات مرحلية أو قائمة استثناءات يمنحك معلومة تستحق الحصول عليها قبل التوقيع لا بعده - وتتناول الأسئلة التي تستحق الطرح قبل التوقيع النسخة الحوارية من عملية الفحص نفسها.

لا شيء من هذه البنود السبعة غير معتاد أو عدواني في طلبه. إنها الفرق بين عقد يصف علاقة وعقد يحميك فعلاً إن انحرفت تلك العلاقة.

تراجع عقداً لبناء MVP وتريد رأياً ثانياً في الشروط؟ أرسل لنا التفاصيل - سنخبرك بما هو ناقص. بنية عقودنا، بما فيها شروط الملكية الفكرية ومراحل الدفع، موضّحة في أسعارنا.