استلام مشروع برمجي 2026: قائمة السورس كود والحسابات قبل الدفعة النهائية

لماذا استلام مشروع برمجي أكبر من رفع الموقع على الإنترنت؟

استلام مشروع برمجي لا يعني فقط أن الرابط يعمل. المنتج يعتمد على كود، بيانات، دومين، استضافة، مفاتيح خدمات، حسابات بريد أو دفع، وربما حسابات App Store وGoogle Play. إذا بقيت هذه العناصر في حساب شخصي لا تملكه، فقد تعمل النسخة اليوم لكن تصبح الصيانة أو الانتقال إلى فريق آخر صعبة غدًا.

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

1. السورس كود ومستودع Git

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

• مستودع كامل يحتوي الفرع أو النسخة التي تم نشرها.
• سجل الإصدارات أو Tags إذا كان المشروع يستخدمها.
• ملف README يوضح تشغيل المشروع محليًا وخطوات البناء والنشر الأساسية.
• ملفات إعداد نموذجية مثل .env.example بدون أسرار حقيقية.
• قائمة الخدمات الخارجية المطلوبة للتشغيل.

2. الحسابات التي يجب مراجعة ملكيتها وصلاحياتها

3. البيانات والنسخ الاحتياطية

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

لا تجعل النسخة الاحتياطية عبارة عن ملف وحيد غير مختبر. الأهم أن تعرف طريقة الاسترجاع ومن المسؤول عنها في فترة التشغيل.

4. اختبار القبول قبل الدفعة النهائية

• اختبر الوظائف الأساسية من منظور كل نوع مستخدم.
• نفذ عملية دفع أو طلب تجريبية إذا كانت موجودة.
• راجع رسائل الخطأ والحالات الفارغة والهواتف المختلفة.
• تأكد من النماذج والإيميلات والإشعارات والتكاملات.
• راجع الفهرسة وrobots وsitemap وcanonical للمواقع العامة.
• سجّل Bugs المتبقية وحدد هل تمنع الإطلاق أم يمكن جدولتها.

5. التوثيق والتشغيل بعد التسليم

التوثيق المطلوب يعتمد على تعقيد المنتج. قد يكفي README واضح لموقع بسيط، بينما نظام داخلي قد يحتاج وصف الصلاحيات والتدفقات وطرق الاسترجاع والتكاملات. اطلب توثيقًا يناسب من سيتولى التشغيل فعليًا.

إذا كان هناك لوحة إدارة، تأكد أن فريقك يعرف إدارة المحتوى أو المستخدمين والمهام اليومية. جلسة Handover مسجلة أو وثيقة قصيرة قد توفر ساعات من الأسئلة بعد الإطلاق.

6. الملكية الفكرية: اجعل الاتفاق مكتوبًا

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

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

نفذ جلسة تسليم فعلية بدل إرسال ملفات في آخر يوم

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

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

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

• خريطة مختصرة لمستودعات الكود والفروع الأساسية.
• قائمة الخدمات الخارجية والغرض من كل خدمة.
• طريقة النشر والرجوع إلى إصدار سابق عند الحاجة.
• المستخدمون الإداريون ومسؤولية كل صلاحية.
• نقاط المراقبة والسجلات التي تفيد عند تشخيص مشكلة.

ضع فترة قبول واضحة قبل إغلاق المشروع والدفعة النهائية

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

فرّق بين Bug يمنع الوظيفة المتفق عليها، وتحسين جديد ظهر بعد الاستخدام. هذا الفصل يحمي الطرفين: العميل يعرف ما سيصحح ضمن التسليم، والفريق يستطيع تقدير الخصائص الجديدة بدل إدخالها بلا نهاية في مرحلة الإغلاق.

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

ابدأ تجهيز التسليم قبل الإطلاق وليس بعد انتهاء التطوير

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

راجع قائمة التسليم في كل مرحلة كبيرة. عند اكتمال التصميم تأكد من ملفات المصدر، وعند اكتمال Backend راجع الوصول إلى قاعدة البيانات والخدمات، وقبل الإطلاق راجع DNS والتحليلات والنسخ الاحتياطي، وبعد الإطلاق راجع المستودع والإصدار النهائي والتوثيق. التقسيم يجعل كل بند صغيرًا وقابلًا للفحص.

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

قائمة سريعة قبل إغلاق المشروع

• الكود في مستودع يمكن الوصول إليه.
• الحسابات الأساسية تحت ملكية أو صلاحية واضحة.
• النسخة المنشورة تطابق النسخة المقبولة.
• البيانات والنسخ الاحتياطية موثقة.
• Bugs المفتوحة ومسؤوليات إصلاحها مكتوبة.
• فترة الضمان أو الدعم وتاريخ بدايتها واضحان.
• قناة التواصل بعد الإطلاق معروفة.

أسئلة شائعة