التسليم بالمراحل وبند القبول: كيف تُنهي مشروع برمجةٍ «بلا نهاية» وتضمن دفعتك في عقود التطوير

اتفقتَ على تطوير موقعٍ أو تطبيقٍ أو نظام SaaS، وبدأ العمل بحماس. ثم تعثّر الدفع لأن العميل «لم يقتنع أن المرحلة اكتملت»، أو تعطّل التسليم لأن كل ميزةٍ تجرّ التي بعدها بلا معيار قبولٍ واضح. هذه ليست مشكلة كودٍ رديء غالباً، بل فجوةٌ في العقد: غياب تسليمٍ بالمراحل يربط الدفع بالإنجاز، وبند قبولٍ يحدّد متى تُعدّ المرحلة «مقبولة». هذا الدليل يشرح كيف تكتب البندين فتحمي وقت المطوّر ومال العميل معاً.

لماذا يتعثّر مشروع التطوير عند الدفع أو التسليم؟

جذر المشكلة أن البرمجيات غير مرئية حتى تُختبر. فالعميل لا يرى «تقدّماً» ملموساً كما يرى في جدارٍ يُبنى، والمطوّر يرى إنجازاً حقيقياً لا يُقابله دفع. حين لا يقسّم العقد المشروع إلى مراحل يُدفَع عند اكتمال كلٍّ منها، يتحوّل التمويل إلى رهانٍ على الثقة: العميل يخشى الدفع قبل رؤية نتيجةٍ نهائية، والمطوّر يخشى مواصلة العمل بلا دفعات. والنتيجة مشروعٌ يتوقّف في منتصفه، أو «يمتدّ بلا نهاية» لأن لا أحد يعرف متى ينتهي.

الحلّ بندان متكاملان: التسليم بالمراحل (Milestones) الذي يجزّئ العمل والدفع، وبند القبول (Acceptance) الذي يعرّف متى تُعدّ المرحلة «مقبولة» بمعيارٍ موضوعي لا بمزاج. حين يُكتب البندان بوضوح يتحوّل المشروع من رهانٍ إلى خطواتٍ محسوبة.

أولاً: كيف تكتب بند «التسليم بالمراحل» (Milestones)؟

المرحلة وحدةٌ من العمل لها مخرَجٌ محدَّد ودفعةٌ مرتبطة به. اكتب البند بحيث يجيب عن أربعة أسئلة:

• ما مخرَج كل مرحلة؟ لا تكتب «المرحلة الأولى: البداية»، بل «تسليم تصميم الواجهات (UI) لخمس شاشاتٍ رئيسية معتمدة». المخرَج الملموس يُغلق باب الجدل.
• كم دفعة كل مرحلة؟ اربط نسبةً من الأتعاب بكل مرحلة: مثلاً 20% دفعةً مقدّمة، ثم 30% عند اعتماد التصميم، ثم 30% عند تسليم النسخة القابلة للاختبار، ثم 20% عند القبول النهائي والنشر.
• ما مدة كل مرحلة؟ حدّد مهلةً زمنية لكل مرحلة، ومهلة اعتمادٍ للعميل بعد كل تسليم — فتأخّر العميل في المراجعة لا يجوز أن يجمّد المشروع بلا حد.
• ما شرط بدء المرحلة التالية؟ عادةً: قبول المرحلة السابقة وسداد دفعتها. هذا يمنع تراكم العمل غير المدفوع.

ثانياً: بند «القبول والاختبار» — المعيار الذي يحسم «هل اكتملت؟»

هنا يُحسم أكثر نزاعات التطوير. النصّ الجيّد يتضمّن أربعة عناصر:

1. معايير قبولٍ موضوعية: تُقبل المرحلة إذا اجتازت قائمة اختبارٍ متّفقٍ عليها (وظائف تعمل وفق المواصفات، خلوّ من الأخطاء الحرجة، توافق المتصفّحات/الأجهزة المحدَّدة) — لا «حتى يرضى العميل» المفتوح.
2. مهلة اختبارٍ محدَّدة: يختبر العميل التسليم خلال [ ] أيام ويرسل ملاحظاته مكتوبةً دفعةً واحدة. وإن لم يعترض خلال المهلة تُعدّ المرحلة مقبولةً تلقائياً.
3. تصنيف الأخطاء: فرّق بين خطأٍ حرجٍ يمنع القبول (تعطّل وظيفة أساسية) وخطأٍ بسيطٍ يُصحَّح لاحقاً دون تعطيل الدفع. هذا يمنع حجز الدفعة بحجّة عيبٍ تجميلي.
4. فترة إصلاح الأخطاء بعد النشر: حدّد مدةً (مثلاً 30 يوماً) يُصلح فيها المطوّر أخطاء البرمجة المكتشفة مجاناً، مقابل تمييزها عن «الميزات الجديدة» التي تُحتسب عملاً إضافياً.

الأخطاء الشائعة مقابل الصياغة المحكمة

نموذج صياغة جاهز يمكنك اقتباسه

«يُنفَّذ المشروع على مراحلَ محدَّدة في الملحق (أ)، لكل مرحلةٍ مخرَجٌ ودفعةٌ ومهلة. ويختبر العميل تسليم كل مرحلة خلال [ ] أيام ويرسل ملاحظاته مكتوبةً دفعةً واحدة؛ فإن لم يعترض خلال المهلة عُدّت المرحلة مقبولةً وتُستحقّ دفعتها. وتُقبل المرحلة إذا اجتازت معايير القبول المتّفق عليها وخلت من الأخطاء الحرجة، على أن تُصحَّح الأخطاء البسيطة لاحقاً دون تعطيل الدفع. ويلتزم المطوّر بإصلاح أخطاء البرمجة المكتشفة خلال [30] يوماً من النشر مجاناً، وتُعدّ أي ميزةٍ جديدة خارج المواصفات عملاً إضافياً بأجرٍ مستقل.»

هذا النصّ القصير يحوّل ثلاثة مصادر نزاعٍ إلى بنودٍ واضحة: توقيت الدفع، ومعيار الاكتمال، وحدود الصيانة. ولاحظ أنه لا يمنع العميل من التوسّع — بل يجعل للتوسّع إطاراً وأجراً.

قبل أن توقّع: ثلاث خطوات عملية

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

نماذج عقدي لتطوير البرمجيات مصمّمة أصلاً لتضمّ هذه البنود: راجع عقد تطوير نظام SaaS مخصّص بالمراحل للمشاريع المرحلية، أو عقد تطوير تطبيق جوال (iOS و Android)، أو عقد تطوير موقع إلكتروني تعريفي للمشاريع الأصغر. وإن كان المشروع كبيراً أو معقّداً فاستعن بـدليل مزوّدي الخدمات القانونية لمراجعةٍ متخصّصة.