كثير من أصحاب الأعمال عند توقيع عقد تطوير موقع يركزون على السعر ومدة التنفيذ، ويكتبون في خانة التسليمات عبارة عابرة مثل «موقع واحد، نسخة كود مصدري واحدة». ثم يكتشفون بعد انتهاء المشروع أن: تصاميم التصميم لا تُسلَّم، وحسابات لوحة التحكم بيد الطرف الثاني، والخادم مسجل باسمه، وتغيير بانر واحد يتطلب دفعًا إضافيًا.
المشكلة ليست سوء نية من أحد، بل أن العقد لم يُكتب بوضوح. كلما كانت التسليمات أكثر تحديدًا، كان ما بعدها أسهل. فيما يلي تفصيل بخمس فئات، مع صياغة قابلة للتعديل في كل فئة.
أولًا: الكود المصدري وحزمة النشر: اكتب بوضوح «ماذا يُسلَّم وكيف يُسلَّم»
الكود المصدري هو البند الأكثر غموضًا. يُنصح بتوضيح ثلاثة أمور في العقد: أي أكواد تُسلَّم، وبأي صيغة تُسلَّم، وهل يمكن تشغيلها بشكل مستقل بعد التسليم.
الصياغة الممكنة هي: كود الواجهة الأمامية، كود الخلفية، ملفات بنية قاعدة البيانات، وثائق تعليمات النشر، تُسلَّم كحزمة، مع الاتفاق على أن الطرف الأول يمكنه بعد التسليم النشر والتشغيل بشكل مستقل على خادمه الخاص.
هناك نقطتان يجب تجنبهما. الأولى: كتابة «تسليم الكود المصدري» فقط دون بنية قاعدة البيانات، فلن يعمل الكود حتى لو تم استلامه. الثانية: أن يحتوي الكود على مكونات خاصة أو ملفات مشفرة من بناء الطرف الثاني، فيبدو التسليم ظاهريًا لكنه في الواقع مرتبط به. مواقع الشركات这类项目尤其要注意، فكثير من ما يسمى بالكود المصدري لمواقع القوالب هو في الحقيقة تغليف ثانوي بترخيص.
إذا كان الأمر يتعلق بـتطوير التطبيقات المصغرة، فيجب أيضًا كتابة: أن حساب الكيان الرئيسي للتطبيق المصغر يعود للطرف الأول، وأن الكود يمكن رفعه إلى لوحة المطور الخاصة بالطرف الأول.
ثانيًا: تصاميم التصميم والمواد: لا تكتفِ بلقطات الشاشة
يُنصح بتحديد تسليمات التصميم: الملفات المصدرية القابلة للتحرير (مثل Figma أو Sketch أو PSD)، وموارد التقطيع، وتعليمات استخدام الخطوط والأيقونات.
تسليم لقطات JPG فقط يعادل عدم التسليم. عند تغيير المصمم لاحقًا أو توسيع صفحات الحملات، ستحتاج إلى إعادة الرسم بالكامل.
يجب أيضًا الاتفاق على ملكية حقوق المواد: هل الصور والخطوط والأيقونات التي يستخدمها الطرف الثاني قابلة للاستخدام التجاري، ومن يتحمل المسؤولية عند حدوث نزاع حقوق ملكية. هذا البند يُغفل كثيرًا في مشاريع تطوير المواقع، لكن عند حدوث مشكلة فعلية يكون النتيجة إزالة مباشرة.
ثالثًا: النطاق والخادم والحسابات: يجب تثبيت الملكية كتابةً
هذه منطقة كثيرة النزاعات. يجب أن يوضح العقد: أن النطاق مسجل باسم الطرف الأول، وأن الخادم أو حساب السحابة مشترى بالاسم الحقيقي للطرف الأول، وأن الطرف الثاني يحتفظ فقط بصلاحيات التشغيل الضرورية خلال فترة التطوير والصيانة.
سيناريو محدد: شركة أرادت إعادة تصميم موقعها الرسمي، ثم اكتشفت بعد الانتهاء أن النطاق بيد مزود الخدمة السابق، والتجديد يتطلب مبلغًا إضافيًا، والترحيل يحتاج تعاونًا، وتأخر الأمر شهرًا.
لذلك يجب أن تتضمن قائمة التسليمات: حساب إدارة النطاق، حساب الخادم السحابي، حساب قاعدة البيانات، حساب مسؤول لوحة التحكم، معلومات التسجيل، وحسابات ومفاتيح الخدمات الخارجية (الرسائل النصية، الدفع، الخرائط). تُراجع بندًا بندًا وتُوقَّع عند التسليم.
رابعًا: لوحة التحكم والوثائق: لا تُعد تسليمًا حتى تصبح قابلة للاستخدام
تسليم نظام إدارة لوحة التحكم لا يقتصر على الحساب، بل يشمل: قائمة الوظائف، شرح الحقول، شرح صلاحيات الأدوار، ودليل العمليات الشائعة.
يُنصح بالاتفاق على جلسة تدريب تسليمية حضورية أو عن بُعد، مع الاحتفاظ بتسجيل الشاشة. بهذه الطريقة عند تغير الموظفين يستطيع الزميل الجديد الاطلاع بنفسه.
في مشاريع تطوير التطبيقات ولوحات التحكم المعقدة، يجب أيضًا طلب وثائق الواجهات وسجل الإصدارات، لتسهيل الربط مع أنظمة أخرى لاحقًا.
خامسًا: معايير القبول: حوّل «قابل للاستخدام» إلى بنود قابلة للاختبار
يجب أن تكون بنود القبول قابلة للتنفيذ. يُنصح بكتابة: قبول الوظائف بندًا بندًا وفق وثيقة المتطلبات، قائمة توافق المتصفحات والأجهزة الرئيسية، الحد الأقصى لزمن تحميل الصفحة، والبنود الأساسية لـاختبار أمان الموقع (مثل فحص الحقن الشائع، تجاوز الصلاحيات، وكشف المعلومات الحساسة).
مع الاتفاق على فترة إصلاح العيوب وحدود زمن الاستجابة، وعدد جولات التصحيح عند عدم اجتياز القبول.
تجنب: كتابة «حسب رضا الطرف الأول»، أو عبارات غير قابلة للتحقق مثل «مطابق لمعايير الصناعة».
متى يكون مناسبًا اللجوء إلى MIC Studio
إذا كنت في إحدى الحالات التالية، يمكنك التفكير في التحدث معنا: المتطلبات واضحة وتحتاج قائمة تسليمات قابلة للتنفيذ؛ لديك نظام قائم يحتاج اختبار عكسي أو فحص أمني؛ أو لا يوجد لديك تقني متفرغ داخليًا لكنك تريد أن تكون الحسابات والكود المصدري والوثائق بيدك.
نعمل على مواقع الشركات، تطوير التطبيقات المصغرة، تطوير التطبيقات وتطوير السكريبتات، ونتولى أيضًا اختبارات الأمان. في مرحلة العقد نُدرج التسليمات بندًا بندًا في جدول يُوقَّع كملحق، لتجنب التفسيرات المتكررة لاحقًا.
ثلاث توصيات قابلة للتنفيذ
1. اجعل التسليمات جدولًا ملحقًا، مع كتابة «الاسم، الصيغة، وقت التسليم، طريقة القبول» لكل بند، وتوقيع التأكيد.
2. قبل التوقيع تحقق من اسم مالك النطاق وحساب السحابة، وإن لم يكن باسمك فقم بالترحيل قبل مناقشة التطوير.
3. اربط نسبة الدفعة النهائية بالقبول، واحتفظ بـ10%～20% تُدفع بعد إتمام التدريب التسليمي والتحقق من الحسابات.
كتابة العقد بتفصيل ليست عدم ثقة، بل لتوفير وقت الطرفين في التفسيرات.