كيف يجب صياغة عقود التطوير الخارجي والتشغيل والصيانة ── التمييز بين شبه التفويض والمقاولة كما تُعلِّمه «العقد النموذجي» الصادر عن IPA

· آخر تحديث: · · عقد تطوير الأنظمة, التطوير الخارجي, التشغيل والصيانة, شبه التفويض, المقاولة, IPA, العقد النموذجي, BtoB

«تعاقدنا بمقاولة إجمالية، لكن التطوير بدأ قبل استقرار المتطلبات، ثم دخلنا في خلاف حول معيار الإنجاز.»

«أبرمنا عقد صيانة شهري، لكن كان هناك اختلاف في فهم كلا الطرفين لحدود نطاق الصيانة.»

«عند طلب عرض سعر، قيل لنا إنّ «تعريف المتطلبات سيكون بعقد شبه تفويض»، لكننا لم نفهم لماذا يُفصَل العقد حسب المرحلة.»

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

في الواقع، لهذه المسألة «نموذج» رسمي. وهو العقد النموذجي لمعاملات نظم المعلومات الذي تنشره IPA (الهيئة المستقلة لترويج تقنية المعلومات).

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

ويُشار إلى أنّ هذا المقال شرح عام مبني على مواد منشورة من IPA، وليس استشارة قانونية. يُرجى استشارة محامٍ أو خبير مختص فيما يخص العقود الفردية.

1. الخلاصة أوّلاً

نلخّص أوّلاً الفكرة التي يطرحها العقد النموذجي الصادر عن IPA بشأن عقود تطوير الأنظمة والتشغيل والصيانة.

  • عدم تجميع كامل مراحل التطوير في عقد واحد، بل فصل العقد حسب كل مرحلة (التعاقد متعدد المراحل)
  • جعل مرحلتَي التخطيط وتعريف المتطلبات، اللتين لم يتحدد فيهما بعد «ما الذي سيُصنَع»، عقداً من نوع شبه التفويض
  • جعل مراحل ما بعد تحديد «ما الذي سيُصنَع»، من التصميم الداخلي إلى التطوير والاختبار، عقداً أساسه المقاولة (أمّا التصميم الخارجي فيمكن أن يكون من أيّ من النوعين بحسب الحالة)
  • جعل الأعمال المستمرة مثل التشغيل والصيانة عقداً أساسه شبه التفويض
  • وجود واجب تعاون على عاتق الجانب الطالب أيضاً، مثل تحديد المتطلبات وتقديم المعلومات
  • عدم التعامل مع تغييرات المواصفات شفهياً، بل معالجتها عبر إجراء إدارة تغيير موثَّق

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

2. ما هو «العقد النموذجي لمعاملات نظم المعلومات» الصادر عن IPA

العقد النموذجي لمعاملات نظم المعلومات هو وثيقة رسمية تجمع نموذجاً لعقد إسناد تطوير الأنظمة مع شرح له.

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

بعد ذلك، تولّت IPA مراجعة الوثيقة، ونُشِر الإصدار الثاني في 22 ديسمبر 2020 المتوافق مع القانون المدني المعدَّل الذي دخل حيز التنفيذ في أبريل 2020. في الإصدار الثاني، جرى تنظيم المسؤولية عن عدم مطابقة العمل للعقد التي سنأتي على ذكرها لاحقاً، وكذلك موقع عقد شبه التفويض القائم على إنجاز النتيجة.

وتجدر ملاحظة أنّ نطاق التطبيق يحتاج إلى انتباه. صُمِّم الإصدار الأوّل والثاني في الأصل مع افتراض تطوير مخصَّص كبير الحجم نسبياً (على نمط الشلال) لأنظمة أساسية للشركات، وتعاملات بين شركات تمتلك أقساماً لنظم المعلومات والشؤون القانونية. أمّا للتعاملات الصغيرة والمتوسطة الحجم أو الحالات التي تستخدم حزماً برمجية أو خدمات SaaS/ASP، فقد أُعِدَّت على حدة سلسلة من العقود النموذجية التكميلية تستهدف «استخدام الحزم البرمجية وSaaS/ASP والتشغيل والصيانة». بعد التحقّق من أيّ منها أقرب إلى تعاملات شركتك، فإنّ المسافة الصحيحة للتعامل معها هي استخدامها كأساس فكري، لا نقل بنودها كما هي. وما نعرضه في هذا المقال هو أيضاً ذلك الجزء «الفكري» المفيد بصرف النظر عن حجم التعامل.

يتميّز هذا العقد النموذجي بالسمات التالية:

  • أُعِدَّ بنقاش بين الشركات المستخدمة وموردي تقنية المعلومات والاتحادات القطاعية والخبراء القانونيين، وصُمِّم بحياد بحيث لا يميل محتواه لصالح أيّ من الطرفين
  • نموذج العقد منشور بصيغة Word، ويمكن تعديله ليلائم تعاملات شركتك
  • لا يقتصر على البنود فحسب، بل يُرفَق بها شرح لـ«لماذا نص عليها بهذا الشكل»
  • تُنشَر أيضاً وثائق مرافقة، مثل الإرشادات الخاصة بتحديد مواصفات الأمان في عقد التطوير

بمعنى آخر، هذه وثيقة يمكن استخدامها كمسودة أولية عند إعداد عقد جديد، وكمعيار مقارنة عند مراجعة عقد مقدَّم من الطرف الآخر.

3. جوهر الفكرة هو «التعاقد متعدد المراحل» ── لماذا يُفصَل العقد حسب كل مرحلة

جوهر فكرة العقد النموذجي هو التعاقد متعدد المراحل.

يتقدّم تطوير الأنظمة تقريباً وفق المراحل التالية.

التخطيط وتعريف المتطلبات (تحديد ما الذي سيُصنَع)
        ↓
التصميم والتطوير والاختبار (صنع ما تم تحديده)
        ↓
القبول ودعم التطبيق (إدخال ما تم صنعه في العمل الفعلي)
        ↓
التشغيل والصيانة (الاستمرار في تشغيله)

التعاقد متعدد المراحل هو أسلوب يفصل هذه المراحل، بدل تجميعها في عقد واحد، ويُبرِم عقداً مستقلاً لكل مرحلة (أو لمجموعة من المراحل).

لماذا يُفصَل العقد؟ السبب بسيط: «ما يمكن الالتزام به» يختلف باختلاف المرحلة.

في المرحلة السابقة لانتهاء تعريف المتطلبات، لم يتحدد بعد محتوى ما سيُصنَع ولا حجمه. فإذا حُدِّد المبلغ الإجمالي وموعد التسليم لكامل التطوير في هذه المرحلة، فسيحدث أحد أمرين:

  • يعرض الجانب المتعاقد مبلغاً أكبر يأخذ في الحسبان المخاطر غير المؤكدة
  • يزعم الجانب المتعاقد الذي قَبِل العمل بسعر منخفض لاحقاً أنّ «هذا خارج النطاق»، فينشب خلاف مع الجانب الطالب

في المقابل، إذا انتهى تعريف المتطلبات، يكون ما سيُصنَع قد تحدَّد، فيستطيع الجانب المتعاقد تقديم تقدير والتزام بالإنجاز بدقة واقعية.

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

4. شبه التفويض والمقاولة ── الفرق بين نوعَي العقد

في التعاقد متعدد المراحل، يُستخدَم عقد شبه التفويض وعقد المقاولة كلٌّ في مكانه المناسب حسب المرحلة. والفرق بين هذين النوعين هو أهم نقطة في هذا المقال.

  عقد المقاولة عقد شبه التفويض
مقابل ماذا يُدفَع الأجر إتمام المُخرَج أداء العمل (وفي النمط القائم على إنجاز النتيجة، النتيجة المتّفق عليها)
مسؤولية الإنجاز موجودة غير موجودة
الالتزام الرئيسي على الجانب المتعاقد إتمام مُخرَج مطابق للعقد واجب العناية الواجبة (أداء العمل بحرص متوقَّع من خبير محترف)
عند وجود مشكلة في المُخرَج المسؤولية عن عدم مطابقة العقد (طلب الإصلاح وغيره؛ التعويض عن الضرر إذا كان الخلل يُعزى إلى الجانب المتعاقد) مسؤولية الإخلال بالالتزام إذا وُجِد إخلال بواجب العناية الواجبة
المرحلة المناسبة لها التصميم والتطوير حين يكون ما سيُصنَع محدَّداً تعريف المتطلبات الذي يحدَّد فيه ما سيُصنَع، والتشغيل والصيانة المستمران

عقد المقاولة ── عقد يلتزم بالإنجاز

المقاولة هي عقد يَعِد فيه الطرف المتعاقد بـ«إتمام هذا المُخرَج». ويتحمّل الجانب المتعاقد مسؤولية الإنجاز، وإن لم يُنجَز العمل فلا يستطيع من حيث المبدأ المطالبة بالأجر (مع ذلك، وحتى لو انتهى المشروع في منتصفه، فقد يُعترَف بأجر بنسبة الجزء المنجَز إذا أمكن فصله وكان يعود بالنفع على الجانب الطالب).

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

بما أنّه عقد يتحمّل مسؤولية قوية مقابل الإنجاز، فإنّ استخدامه مناسب في المراحل التي يمكن فيها تحديد «ما الذي يُعدّ إنجازاً» بوضوح.

عقد شبه التفويض ── عقد يلتزم بأداء عمل بصفة خبير

شبه التفويض هو عقد يَعِد فيه الطرف المتعاقد بـ«أداء العمل بصفة خبير». وبدلاً من تحمّل مسؤولية الإنجاز، يتحمّل الجانب المتعاقد واجب العناية الواجبة، أي واجب أداء العمل بالحرص المتوقَّع عادة من خبير محترف.

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

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

الاستخدام المناسب حسب كل مرحلة

في العقد النموذجي لمعاملات نظم المعلومات، يُفتَرَض تقريباً التوزيع التالي:

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

المهم هنا ألا يُختزَل الأمر في مقولة بسيطة من نوع «المقاولة أفضل للجانب الطالب» أو «شبه التفويض أفضل للجانب المتعاقد».

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

5. ما ينبغي تحديده في عقد التشغيل والصيانة

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

وحين يُقال «التشغيل والصيانة»، فإنّ محتواه في الواقع مجموعة من أعمال مختلفة الطبيعة.

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

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

عند التعاقد، يُنصَح بتحديد النقاط التالية كتابياً على الأقل:

  • الخط الفاصل بين الأعمال المشمولة ضمن النطاق الشهري (الثابت) والأعمال غير المشمولة
  • أوقات استقبال الاستفسارات والأعطال، والوقت التقريبي حتى بدء التعامل معها
  • تصنيف درجات أهمية الأعطال، وسياسة التعامل مع كل تصنيف
  • إجراءات التقدير والطلب في حال ظهور عمل يتجاوز النطاق الثابت
  • العلاقة بين المسؤولية عن عدم مطابقة العقد أثناء التطوير (المشمولة بالإصلاح المجاني) وعقد الصيانة (التعامل المدفوع)

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

6. الجانب الطالب أيضاً عليه واجبات ── واجب التعاون وواجب إدارة المشروع

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

  • يتحمّل الجانب المورّد، بصفته خبيراً، واجب إدارة المشروع بشكل مناسب وشرح المخاطر عند وجودها (واجب إدارة المشروع)
  • يتحمّل الجانب الطالب واجب التعاون، مثل تحديد المتطلبات وتقديم معلومات محتوى العمل واتخاذ القرارات اللازمة في الوقت المحدد

بمعنى آخر، إذا اكتفى الجانب الطالب بترك كل شيء للمورّد بحجة «لا نفهم الأمور التقنية»، أي التفويض الكامل، فلن تستقر المتطلبات، وقد تُساءَل مسؤولية واجب تعاون الجانب الطالب أيضاً عند فشل المشروع.

يتضمن العقد النموذجي آلية لتوثيق توزيع الأدوار بين الطرفين ومشاركة التقدم والمشكلات في لجنة تنسيق (اجتماع دوري). وإذا قُرِئ لا كنموذج عقد فحسب، بل كدليل قواعد لإدارة المشروع بشكل مشترك، فسيكون مورداً يستفيد منه الجانب الطالب أيضاً استفادة كبيرة.

7. تُعالَج تغييرات المواصفات عبر «إجراء إدارة التغيير»

ظهور طلب من نوع «نريد تغيير هذه الشاشة على هذا النحو رغم كل شيء» أثناء التطوير أمر لا مفر منه. المشكلة ليست في ظهور التغيير نفسه، بل في المضي في التغيير عبر تبادل شفهي أو عبر البريد الإلكتروني فقط.

  • الجانب الطالب يقول: «كنت أظن أنّه تغيير بسيط»
  • الجانب المتعاقد يقول: «تعاملنا معه، لكن حجم العمل تضخّم، لذا نريد المطالبة بتكلفة إضافية»

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

يحدد العقد النموذجي إجراء إدارة التغيير. والتدفق العام له كالتالي:

اقتراح التغيير (من أيّ من الطرفين)
        ↓
تقديم المحتوى ونطاق الأثر والتكلفة وأثره على موعد التسليم كتابياً (مقترح تغيير)
        ↓
تشاور بين الطرفين
        ↓
عند الاتفاق: توثيقه وتنفيذ التغيير / وعند عدم الاتفاق: الاستمرار على الوضع الحالي

النقطة المهمة هي الاتفاق على أثر التغيير في التكلفة وموعد التسليم، وليس محتوى التغيير فقط، قبل البدء بالتنفيذ. هذه خطوة إضافية من ناحية الإجراء، لكنها الخطوة الإضافية التي تمنع الجدال حول «هل قلت هذا أم لا».

8. توجد نماذج عقد مخصصة لحالة التطوير الرشيق (Agile)

كل ما شُرِح حتى الآن يفترض التطوير على نمط الشلال الذي يحدَّد فيه المتطلبات قبل الصنع.

في المقابل، بالنسبة للتطوير الرشيق (Agile) الذي يُعاد فيه النظر في المتطلبات أثناء الصنع، نُشِر في 31 مارس 2020 عقد نموذجي مخصص هو العقد النموذجي لمعاملات نظم المعلومات (إصدار التطوير الرشيق).

سمات إصدار التطوير الرشيق كالتالي:

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

الفكرة الكامنة هنا ليست «بما أنّه تطوير رشيق فلا بأس بأن يكون العقد غامضاً»، بل «لأنّه تطوير يتعامل مع التغيير، ينبغي بالتحديد أن يُحدَّد توزيع الأدوار وطريقة التقدّم بوضوح في العقد».

الخلاصة

نلخّص فكرة عقود التطوير الخارجي والتشغيل والصيانة التي يمكن تعلّمها من العقد النموذجي لمعاملات نظم المعلومات الصادر عن IPA.

  • عدم تجميع كامل التطوير في عقد واحد، بل فصل العقد حسب كل مرحلة (التعاقد متعدد المراحل)
  • التخطيط وتعريف المتطلبات، اللذان يحدِّدان «ما الذي سيُصنَع»، أساسهما شبه التفويض، والتطوير من التصميم الداخلي فصاعداً بعد أن يتحدد ما سيُصنَع أساسه المقاولة (والتصميم الخارجي يمكن أن يكون من أيّ من النوعين)
  • المقاولة تحمل مسؤولية الإنجاز والمسؤولية عن عدم مطابقة العقد، وشبه التفويض يحمل واجب العناية الواجبة؛ طبيعة المسؤولية التي يتحملها الجانب المتعاقد تختلف بينهما
  • التشغيل والصيانة أساسهما شبه التفويض، مع توثيق الخط الفاصل بين النطاق الثابت والتقدير المنفصل عند التعاقد
  • على الجانب الطالب أيضاً واجب تعاون، والتفويض الكامل يُفشِل المشروع
  • تُعالَج تغييرات المواصفات عبر إجراء إدارة التغيير، مع الاتفاق عليها مقروناً بأثرها في التكلفة وموعد التسليم
  • للتطوير الرشيق عقد نموذجي مخصص يفترض شبه التفويض

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

لمن يفكر في إسناد تطوير الأنظمة وصيانتها

لاختيار شكل العقد المناسب، لا بد أوّلاً من تنظيم «ما الذي سيُصنَع» و«إلى أيّ مدى يُسنَد» و«كيف يُوزَّع الدور بين الجانب الطالب والجانب المتعاقد».

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

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

لكي لا تنسى تحديد «كم ثانية يجب أن يستغرق التشغيل حتى يكون مُرضياً» ── تنظيم المتطلبات غير الوظيفية باستخدام «درجة المتطلبات غير الوظيفية» الصادرة عن IPA

كثير من أسباب الخلاف حول «السرعة بطيئة» أو «التعامل مع الأعطال لم يكن متوقَّعاً» يعود إلى نسيان تحديد المتطلبات غير الوظيفية. نشرح للجانب...

من أين تبدأ الشركات الصغيرة والمتوسطة في تدابير الأمان؟ ── كيفيّة قراءة الإصدار 4.0 من «الدليل الإرشادي لتدابير أمن المعلومات للشركات الصغيرة والمتوسطة» الصادر عن IPA

من أين ينبغي أن تبدأ الشركات الصغيرة والمتوسطة في تدابير الأمان؟ استناداً إلى الإصدار 4.0 من «الدليل الإرشادي لتدابير أمن المعلومات للشرك...

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

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

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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

روابط عامة

العودة إلى المدونة