كيف تدير الشريك التقني؟ ما الذي يجب أن تحسمه في العقد وSLA والتسليم؟
Vendor Management · SLA · Handover اختيار شركة البرمجة لا ينتهي عند الموافقة على السعر. العلاقة تبدأ فعلًا عندما يتحول الوعد التجاري إلى عقد، والعقد إلى طريقة عمل، وطريقة العمل إلى تسليم يمكن قياسه. كثير من الخلافات لا تبدأ من…
Vendor Management · SLA · Handover
اختيار شركة البرمجة لا ينتهي عند الموافقة على السعر. العلاقة تبدأ فعلًا عندما يتحول الوعد التجاري إلى عقد، والعقد إلى طريقة عمل، وطريقة العمل إلى تسليم يمكن قياسه. كثير من الخلافات لا تبدأ من سوء النية؛ تبدأ من كلمات واسعة مثل «الدعم»، «التسليم»، «الملكية» و«إنهاء المشروع» بدون تعريف عملي لما تعنيه.
ماذا ستخرج به
- الفرق بين العقد الرئيسي وScope/SOW وSLA وملحق معالجة البيانات.
- ما الذي يجب حسمه في النطاق والدفع وAcceptance Criteria قبل بدء التطوير.
- كيف تكتب SLA قابلة للقياس بدل وعد عام بـ«دعم سريع».
- ما الذي يجب أن تستلمه من Repository وحسابات وبيانات وتوثيق عند نهاية المشروع.
- كيف تجهز Exit Plan حتى تستطيع تغيير الشريك دون فقدان القدرة على تشغيل المنتج.
هذا الدليل يشرح إدارة العلاقة التقنية والتشغيلية، ولا يقدم تفسيرًا قانونيًا ملزمًا لعقد بعينه. البنود المتعلقة بالملكية الفكرية والبيانات والمسؤولية والجزاءات تحتاج مراجعة قانونية وفق حالة شركتك والعقد والقانون المطبق.
الإجابة المباشرة: ما الذي يجب حسمه قبل التوقيع مع شركة البرمجة؟
لا يكفي أن يذكر العقد «تطوير تطبيق وتسليمه». تحتاج على الأقل إلى حسم: النطاق، ما هو خارج النطاق، معايير القبول، الجدول والاعتماديات، طريقة التغيير، الدفع، الملكية، الحسابات والبيانات، الدعم وSLA، الأمن، التسليم النهائي، وإنهاء العلاقة.
العقد ليس وثيقة واحدة: افصل طبقات الاتفاق
العقد الرئيسي
الإطار العام للعلاقة: الالتزامات، السرية، الملكية، المسؤولية، الدفع، الإنهاء والقانون الحاكم حسب الاتفاق.
نطاق العمل
ما الذي سيُبنى، Deliverables، Milestones، الافتراضات، الاستثناءات والأدوار.
مستوى الخدمة
ما الخدمة بعد الإطلاق أو أثناء التشغيل، وكيف تقاس الاستجابة والتوافر والتصعيد عند الحاجة.
معالجة البيانات
إذا كان الشريك يعالج بيانات شخصية، يجب أن تكون الأدوار والتعليمات والالتزامات المتعلقة بالمعالجة واضحة وفق الحالة.
الفصل لا يعني أن هذه الوثائق يجب أن تكون ملفات مستقلة دائمًا؛ يمكن دمجها. الفكرة أن كل موضوع يجب أن يكون له تعريف واضح بدل دفنه داخل فقرة عامة.
1. ابدأ من Scope يمكن تسعيره وقبوله
أكبر مشكلة في العقود البرمجية هي أن يكون السعر ثابتًا بينما النطاق لغويًا مفتوح. اكتب المنتج كرحلات وقدرات وتسليمات، وليس كجملة «تطبيق متكامل» أو «منصة شاملة».
- المنصات: iOS / Android / Web / Admin حسب المشروع.
- الأدوار والصلاحيات الأساسية.
- الرحلات والـFeatures الداخلة في الإصدار.
- التكاملات الخارجية المحددة.
- البيانات أو Migration إذا كانت مطلوبة.
- ما الذي يقدمه العميل: محتوى، API، حسابات، قرارات، بيانات أو موافقات.
- ما هو Out of Scope بوضوح.
- Assumptions التي بُني عليها السعر والجدول.
إذا كنت ما زلت في مرحلة مقارنة التقديرات، راجع أولًا كيف تُقدّر تكلفة ومدة المشروع البرمجي قبل طلب عرض السعر؟ لأن اتفاقًا مبنيًا على Estimate غير مفهوم سينقل المشكلة من مرحلة البيع إلى مرحلة التنفيذ.
ولو كانت المتطلبات نفسها غير مكتوبة، ابدأ من وثيقة متطلبات المشروع الرقمي قبل تثبيت Scope نهائي.
2. Acceptance Criteria: متى نقول إن الـDeliverable تم قبوله؟
عبارة «تم التسليم» لا تكفي. التسليم قد يعني أن الشركة رفعت Build، بينما القبول يعني أن العميل تحقق من شروط متفق عليها. اجعل لكل Milestone مخرجًا وطريقة اختبار وفترة مراجعة ومسارًا لمعالجة الملاحظات.
«يسلّم المورد النظام كاملًا وفق الاتفاق.»
لا تحدد ما هو الكامل أو كيف نتحقق من مطابقته.
«يُراجع التسليم وفق Acceptance Criteria المرفقة لكل Milestone، وتوثق الملاحظات على أنها Defect أو Change.»
تجعل الخلاف قابلًا للتصنيف بدل النقاش المفتوح.
3. اربط الدفع بالـMilestones لا بالانطباع
الدفع المرحلي يقلل التوتر عندما تكون نقطة الاستحقاق واضحة للطرفين. لا تربط كل دفعة بتاريخ فقط إذا كان التأخير قد يكون بسبب اعتماديات أو تسليمات؛ واربطها بمخرج يمكن التحقق منه حسب نموذج العقد.
| مثال Milestone | مخرج يمكن مراجعته | ما الذي يجب حسمه؟ |
|---|---|---|
| Discovery | Scope / flows / assumptions | من يعتمد الوثائق وماذا يحدث عند تغييرها؟ |
| Design | Design System + approved flows | عدد جولات المراجعة وما هو Change. |
| Development | Feature set على Staging | Acceptance Criteria والاعتماديات. |
| Launch | Production release | ما الذي يجب أن يكون جاهزًا من حسابات وبيانات ونشر؟ |
| Handover | Repo + accounts + docs + access | قائمة تسليم نهائية قابلة للتوقيع. |
4. Change Control: كيف تمنع Scope Creep بدون تعطيل المنتج؟
المشروع يتعلم أثناء التنفيذ. المشكلة ليست وجود التغيير، بل أن يحدث التغيير دون معرفة أثره على التكلفة والمدة والأولوية.
- من يحق له طلب Change؟
- ما الحد الفاصل بين Bug وChange Request؟
- من يقدّر أثر التغيير؟
- هل يحتاج موافقة كتابية قبل التنفيذ؟
- هل يغير السعر، الجدول، أو يحل محل Feature أخرى؟
- أين تحفظ Change Log حتى لا تضيع القرارات؟
5. الملكية الفكرية وSource Code: لا تستخدم كلمة «ملكيتي» وحدها
الدليل الاسترشادي للهيئة السعودية للملكية الفكرية يوضح أن نقل كل أو بعض الحقوق المالية على المصنف التقني يجب أن يكون مكتوبًا، وأن يحدد الحقوق والالتزامات وتفاصيل الحق ومداه والغرض والمدة والمكان، وأن الحقوق المالية التي لم يتم التنازل عنها صراحة تبقى للمؤلف. [1]
لذلك لا تكتفِ بجملة «العميل يملك المشروع». راجع مع مستشارك القانوني على الأقل:
- ما الحقوق التي تنتقل ومتى تنتقل؟
- هل الانتقال مرتبط بسداد مبالغ محددة؟
- ما مكونات المورد السابقة Pre-existing components؟
- ما مكونات Open Source / Third-party licenses؟
- ما وضع Design files والتوثيق وقواعد البيانات؟
- من يملك التعديلات التي تُبنى خصيصًا للمشروع؟
امتلاك نسخة من Repository ليس هو نفسه حسم الحقوق القانونية، وحسم الحقوق القانونية لا يعني وحده أنك تستطيع تشغيل المشروع دون الحسابات والبنية والتوثيق. عالج الجانبين.
6. الحسابات والبنية: من يملك مفاتيح التشغيل؟
حتى لو كان العقد ممتازًا، يمكن أن يصبح العميل معتمدًا كليًا على المورد إذا كانت Production والـDomain والمتاجر والخدمات الأساسية داخل حسابات لا يسيطر عليها. الحل ليس أن تكون كل خدمة دائمًا باسم العميل، بل أن يكون نموذج الملكية والوصول والخروج مقصودًا ومكتوبًا.
| الأصل | ما الذي يجب معرفته؟ | عند التسليم/الخروج |
|---|---|---|
| Git Repository | المنظمة، الصلاحيات، الفروع، تاريخ العمل | Admin access ونسخة كاملة من الـRepo حسب الاتفاق |
| Cloud / Hosting | مالك الحساب، Billing، Roles، Production resources | وصول مناسب + Inventory + نقل/فصل عند الحاجة |
| Domain / DNS | Registrar وMFA وBilling | سيطرة العميل أو آلية نقل موثقة |
| App Stores | Apple / Google accounts والأدوار | وصول ونقل التطبيقات إذا كان نموذج الحساب يتطلب ذلك |
| Third-party APIs | SMS، Payments، Maps، Email وغيرها | قائمة الخدمات والمفاتيح والمالكين والفوترة |
| Analytics / Monitoring | لوحات القياس والتنبيهات | حسابات وDashboards وتعريف المؤشرات |
7. إذا كان المورد يعالج بيانات شخصية: لا تتركها داخل بند سرية عام
اللائحة التنفيذية لنظام حماية البيانات الشخصية في السعودية تنص، عند اختيار Controller لمعالج Processor، على تضمين الاتفاق عناصر منها غرض المعالجة، فئات البيانات، مدة المعالجة، التزام الإبلاغ عن خرق البيانات دون تأخير غير مبرر، وتحديد Sub-processors أو الأطراف التي ستُفصح لها البيانات، مع التزام الـController بتقييم امتثال المعالج دوريًا. [2]
هذا لا يعني أن كل شركة تطوير تكون Processor بنفس الصورة؛ الأدوار تعتمد على الواقع الفعلي للمعالجة. لكن إذا كان المورد يستضيف أو يصل أو يعالج بيانات شخصية لصالحك، فتعامل مع الموضوع كمسؤولية تشغيلية وقانونية مستقلة، لا كملحق شكلي.
- ما البيانات التي يمكن للمورد الوصول إليها؟
- لماذا يعالجها وكم يحتفظ بها؟
- من هم Sub-processors؟
- ما آلية الإبلاغ عن الحوادث؟
- ما سياسات الصلاحيات والوصول إلى Production؟
- ماذا يحدث للبيانات عند انتهاء العلاقة؟
8. SLA: لا تكتب «دعم فني سريع»
AWS تعرف SLA كاتفاق يحدد مستوى الخدمة الذي يعد المورد بتقديمه، وقد تشمل مقاييس مثل التوافر ووقت الاستجابة ووقت الحل ومسار التصعيد عند عدم تحقيق الالتزام. [3]
لكن قبل SLA، افصل المصطلحات. Google SRE تفرق بين: SLI كمقياس فعلي للخدمة، وSLO كهدف لذلك المقياس، وSLA كاتفاق يتضمن ما يحدث عند عدم تحقيق الهدف. [4]
9. ماذا يجب أن يحتوي SLA للدعم؟
نطاق الدعم
ما الأنظمة والبيئات المشمولة؟ Production فقط أم Staging أيضًا؟ هل الدعم يشمل Bugs فقط أم Configuration واستفسارات؟
ساعات الخدمة
24/7 أم ساعات عمل؟ ما المنطقة الزمنية؟ ماذا يحدث خارجها للحوادث الحرجة؟
Severity Matrix
ما الذي يجعل البلاغ Critical أو High أو Medium؟ التعريف يجب أن يعتمد على أثر المستخدم/العمل لا على غضب صاحب البلاغ.
Response vs Resolution
وقت الاستجابة يعني بدء التعامل أو الرد، وليس بالضرورة إصلاح المشكلة. اكتب كل هدف منفصلًا إذا كان كلاهما مهمًا.
Clock Rules
متى يبدأ العداد؟ هل يتوقف بانتظار معلومات من العميل؟ ما الصيانة المستثناة؟
Measurement Source
أي Monitoring أو Ticketing System يحسم وقت البداية والنهاية والتوافر؟
Escalation
من يُصعد إليه الحادث بعد تجاوز مستوى معين؟ وكيف يتواصل أصحاب القرار أثناء Incident كبير؟
Consequence / Remedy
إذا كان هناك Service Credit أو إعادة خدمة أو آلية أخرى، يجب أن تكون محددة قانونيًا وتجاريًا في الاتفاق وليس في صفحة تسويق.
«الأعطال الحرجة تُحل بأسرع وقت.»
لا يوجد تعريف Critical، ولا Clock، ولا هدف ولا مصدر قياس.
«P1 = توقف الوظيفة الأساسية لكل المستخدمين، ويقاس وقت الاستجابة من تسجيل البلاغ في القناة المحددة.»
ثم يحدد الاتفاق الهدف، ساعات التغطية، التصعيد وما يحدث عند الإخفاق.
10. لا تعد بـ100% Availability بلا سبب
Google SRE تحذر من اعتبار 100% SLO هدفًا واقعيًا في معظم الخدمات، لأن اختيار هدف Reliability هو قرار تقني وتجاري معًا، والأهداف المبالغ فيها قد تستهلك جهدًا وتكلفة لا تتناسب مع احتياج المستخدم. [5]
لا تنسَ أيضًا أن تطبيقك يعتمد غالبًا على Cloud وPayment Gateway وSMS وخدمات أخرى لها حدودها وشروطها. إذا كتبت SLA أعلى من قدرة سلسلة الاعتماديات كلها، فأنت تكتب التزامًا لا يعكس Architecture الفعلية.
11. فرّق بين Warranty وSupport وMaintenance وNew Features
| المصطلح | المقصود تشغيليًا | السؤال الذي يجب حسمه |
|---|---|---|
| Warranty / Bug Fix | إصلاح Defects في نطاق تم قبوله وفق شروط محددة | كم مدتها؟ وما الذي لا يعتبر Bug؟ |
| Support | استقبال وتشخيص البلاغات والمساعدة التشغيلية | القنوات، الساعات، Severity وSLA |
| Maintenance | تحديثات تقنية، Dependencies، OS/SDK أو أعمال استقرار | ما المشمول وما دور العميل؟ |
| Feature Development | وظائف أو تغييرات جديدة | هل لها Backlog وعقد/ميزانية مستقلة؟ |
12. Governance: كيف تدير العلاقة أثناء التنفيذ؟
العقد لا يدير المشروع وحده. تحتاج Cadence للقرارات، Visibility على التقدم، وسجلًا واضحًا لما تغير.
- مالك قرار واضح من جانب العميل.
- مالك Delivery واضح من جانب الشريك.
- Backlog أو Tracking System مشترك.
- تقرير دوري: Done / Next / Risks / Decisions needed.
- Decision Log للقرارات المؤثرة في Scope أو Architecture.
- Risk Register للمشكلات التي قد تغير الجدول أو التكلفة.
- مسار Escalation عند تعطل قرار أو اعتماد.
13. اربط العقد بالقيمة وليس بالتسليم فقط
يمكن أن ينجح المشروع في تسليم كل Screens ويفشل كاستثمار. لذلك اجعل Business Owner يعرف لماذا تُبنى كل مرحلة وما المؤشر الذي ستؤثر فيه، حتى لو لم تكن كل قيمة قابلة للتحويل إلى ريال فورًا.
إذا كان المشروع يحتاج اعتماد ميزانية، استخدم حساب العائد على الاستثمار التقني قبل طلب ميزانية المشروع لبناء Baseline وتكاليف كاملة ومنافع قابلة للقياس بدل تبرير الاستثمار بعد أن يبدأ التنفيذ.
14. التسليم النهائي Handover: لا تجعل آخر دفعة تسبق آخر أصل
التسليم الجيد يثبت أن فريقًا آخر يمكنه فهم الأصول والوصول إليها وتشغيلها ضمن حدود الاتفاق. ليس المطلوب إغراق العميل في ملفات؛ المطلوب Minimum Set يجعل الملكية والتشغيل قابلين للاستمرار.
- Repository والـBranches وتاريخ العمل حسب الاتفاق.
- Instructions للبناء والتشغيل والنشر.
- Architecture overview.
- Database schema وMigrations.
- API documentation والتكاملات.
- Inventory للحسابات والخدمات الخارجية.
- Cloud / Hosting / Domains / DNS access.
- App Store / Google Play access إذا كان المشروع تطبيقًا.
- Environment variables / Secrets inventory عبر طريقة آمنة، لا داخل وثيقة مكشوفة.
- Backups وRecovery information حسب نطاق الخدمة.
- Known Issues وTechnical Debt المعروف.
- Design assets المطلوبة.
- Runbooks أو Support procedures عندما تكون ضمن الاتفاق.
15. Exit Plan: ماذا يحدث إذا انتهت العلاقة؟
لا تنتظر الخلاف حتى تسأل كيف تنتقل. Exit Plan الجيد يُكتب عندما تكون العلاقة جيدة.
| السؤال | ما الذي يجب أن يكون واضحًا؟ |
|---|---|
| Termination | متى يحق لكل طرف إنهاء الاتفاق وما الإشعار المطلوب؟ |
| Outstanding Work | كيف يعالج العمل غير المكتمل والدفعات المتعلقة به؟ |
| Data Return | شكل تسليم البيانات ومتى، وما الذي يحدث للنسخ المتبقية وفق الالتزامات المطبقة. |
| Knowledge Transfer | عدد جلسات الانتقال أو الوثائق إذا كانت ضمن الاتفاق. |
| Access Removal | متى تُسحب صلاحيات الفريق السابق؟ |
| Transition Support | هل توجد فترة دعم انتقالية وبأي سعر/حدود؟ |
16. مثال افتراضي: عقد رخيص يمكن أن يصبح مكلفًا
افترض عرضين لتطوير نظام. العرض A أقل سعرًا، لكنه لا يحدد Data Migration ولا ملكية حساب Cloud ولا QA Acceptance ولا دعم بعد الإطلاق. العرض B أعلى قليلًا لكنه يفصل Scope، Migration، الحسابات، Acceptance، Handover وChange Control. هذا المثال لا يعني أن B أفضل تلقائيًا؛ يعني أن السعر لا يمكن مقارنته قبل توحيد ما الذي تشتريه ومَن يتحمل المخاطر المخفية.
لا تقارن Total Price قبل أن تقارن Scope + Risk + Ownership + Support + Exit. العقد الأرخص قد يكون فقط العقد الذي ترك أسئلة أكثر خارج السعر.
17. Red Flags قبل التوقيع
Scope في سطرين
عنوان المنتج ليس نطاقًا يمكن قبوله أو تسعيره.
«ملكية كاملة» بلا تفاصيل
لا تعرف ما الحقوق أو المكونات أو الحسابات التي يشملها التعبير.
SLA فيها رقم بلا طريقة قياس
لا تعرف من أين يأتي الـUptime أو متى يبدأ Response Clock.
Support غير محدود
قد تبدو ميزة تسويقية، لكنها تحتاج تعريفًا حتى يعرف الطرفان ما المتوقع وما حدود Capacity.
لا يوجد Change Process
كل تعديل سيتحول إلى نقاش حول «هل كان ضمن الاتفاق أم لا؟».
Production داخل حساب شخصي
ينشئ Risk في الاستمرارية والوصول والفوترة.
لا توجد Exit أو Handover
أنت تعرف كيف تبدأ العلاقة ولا تعرف كيف تنهيها.
18. Checklist نهائية قبل التوقيع
- العقد يحدد الأطراف ونطاق المسؤولية بوضوح.
- Scope وOut of Scope مكتوبان.
- Acceptance Criteria لكل Milestone مهمة.
- Dependencies على العميل والمورد واضحة.
- Payment Milestones مرتبطة بمخرجات مفهومة.
- Change Request Process موجودة.
- حقوق الملكية والمكونات السابقة والطرف الثالث محددة قانونيًا.
- نموذج ملكية الحسابات وProduction واضح.
- متطلبات البيانات والخصوصية متوافقة مع الدور الفعلي للمورد.
- SLA تحدد Scope وSeverity وResponse/Resolution والقياس والتصعيد.
- Warranty وSupport وMaintenance وNew Features منفصلة.
- Handover Checklist محددة قبل آخر Milestone.
- Exit Plan وTransition Support واضحان.
- أصحاب القرار والتصعيد Governance معروفون.
أسئلة شائعة
هل SLA ضرورية أثناء مرحلة التطوير؟
SLA تُستخدم أساسًا عندما توجد خدمة أو دعم يمكن قياس مستواه. أثناء التطوير، قد تحتاج بدلًا منها Milestones وAcceptance Criteria وCadence واتفاقًا على أوقات الرد في قنوات المشروع. لا تسمِّ كل وعد زمني SLA إذا لم يكن اتفاق خدمة قابلًا للقياس.
ما الفرق بين وقت الاستجابة ووقت الحل؟
وقت الاستجابة يقيس متى يبدأ المورد التعامل أو يرد وفق التعريف، بينما وقت الحل يتعلق بإغلاق المشكلة أو استعادة الخدمة وفق الشروط. AWS تذكر الاثنين كمقاييس قد تظهر في SLA.[3]
هل دفع قيمة النظام يعني أن Source Code أصبح ملكي تلقائيًا؟
لا تفترض ذلك. الدليل السعودي للملكية الفكرية يوضح أن نقل الحقوق المالية يحتاج تصرفًا مكتوبًا يحدد الحقوق وتفاصيلها، وأن الحقوق غير المتنازل عنها صراحة تبقى للمؤلف.[1] راجع عقدك مع مستشار قانوني.
هل يجب أن تكون حسابات Cloud والمتاجر باسم العميل؟
لا توجد قاعدة تقنية واحدة لكل نموذج تعاقد، لكن يجب أن تعرف من يملك الحساب، من يدفع، من يملك Admin access، وكيف سيتم النقل أو الخروج. الغموض هنا هو المشكلة الأساسية.
هل 99.9% Availability مناسبة لكل تطبيق؟
ما أهم شيء أستلمه قبل آخر دفعة؟
لا يوجد أصل واحد يكفي. اربط آخر Milestone بقائمة Handover تناسب مشروعك: Repo، حسابات، Production access، توثيق، بيانات، خدمات خارجية، Known Issues وآلية التشغيل والنقل.
التعاقد التقني الجيد يبدأ قبل أول Sprint
إذا كنت تقارن عروض تطوير، لا تجعل القرار سعرًا ومدة فقط. ثبّت Scope، Acceptance، الحسابات، الملكية، الدعم والتسليم قبل بدء التنفيذ، حتى تصبح العلاقة قابلة للإدارة وليست معتمدة على الذاكرة والتوقعات.
ناقش نطاق مشروعك مع SpinesTech استعرض خدمات SpinesTechالمصادر والمراجع
- الهيئة السعودية للملكية الفكرية — الدليل الاسترشادي لحماية حقوق الملكية الفكرية في البرمجيات. نقل الحقوق المالية ومتطلبات الكتابة وتحديد نطاق الحقوق.
- الهيئة السعودية للبيانات والذكاء الاصطناعي — Executive Regulations of the Personal Data Protection Law. Article 17 المتعلق باختيار Processor ومحتوى الاتفاق والـSub-processors والإبلاغ.
- AWS — ما المقصود باتفاقية مستوى الخدمة (SLA)؟. تعريف SLA ومقاييس مثل التوافر والاستجابة والحل والتصعيد.
- Google Site Reliability Engineering — Service Level Objectives. تعريف SLI وSLO وSLA وطريقة القياس.
- Google SRE Workbook — Implementing SLOs. اختيار أهداف Reliability واقعية ومرتبطة بما يهم المستخدم.
