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

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

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

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

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

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

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

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

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

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

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

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

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 27، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

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

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

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

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

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

لهذا العقد النموذجي السمات التالية.

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

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

أي طبعة ينبغي النظر إليها

في صفحة IPA تتوالى عدة طبعات، لذا حدّدوا أولاً أيّها أقرب إلى تعاملات شركتكم ثم افتحوا الصفحة حتى لا يختلط الأمر.

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

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

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

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

企画・要件定義(何を作るかを決める)
        ↓
設計・開発・テスト(決めたものを作る)
        ↓
受入・導入支援(作ったものを業務に載せる)
        ↓
運用・保守(動かし続ける)

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

البنية الوثائقية الفعلية ── طبقتان: العقد الأساسي والعقد الفردي

عند سماع «فصل العقد حسب المرحلة» قد يُظن أنكم ستصنعون عقداً مستقلاً بعدد المراحل، لكن ما يتّخذه العقد النموذجي هو بنية ذات طبقتين: عقد أساسي وعقود فردية. نثبّت البنية أولاً حتى لا يختلط الأمر عند فتح النموذج.

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

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

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

وثائق العقود المدرَجة في متن الطبعة الثانية هي التالية.

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

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

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

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

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

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

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

نلخّص أولاً باختصار المصطلحات التي تظهر في هذا الفصل.

بعد ذلك نعرض الفرق بين المقاولة وشبه التفويض في قائمة.

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

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

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

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

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

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

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

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

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

يفترض العقد النموذجي تقريباً التمييز التالي.

المهم هنا أن الأمر ليس حديثاً بسيطاً من نوع «المقاولة أنفع للجانب الطالب» أو «شبه التفويض أنفع للجانب المتعاقد».

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

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

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

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

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

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

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

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

عند التعاقد، نوصي بتحديد النقاط التالية على الأقل كتابة.

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

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

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

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

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

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

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

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

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

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

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

ينص العقد النموذجي على إجراء إدارة التغيير. التدفق تقريباً كما يلي.

変更の提案(どちらからでも)
        ↓
書面(変更提案書)で内容・影響範囲・費用・納期への影響を提示
        ↓
両者で協議
        ↓
合意したら書面に残して変更を実施 / 合意できなければ現行どおり

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

8. للتطوير الرشيق عقد نموذجي مخصص

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

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

سمات نسخة التطوير الرشيق كما يلي.

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

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

الخلاصة

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

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

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

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

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

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

مقالات ذات صلة

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

أين يتصل هذا الموضوع

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

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

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

ما الفرق بين عقد المقاولة وعقد شبه التفويض؟

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

لماذا يُنصَح بعقد شبه التفويض لمرحلة تعريف المتطلبات؟

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

هل من الأفضل أن يكون عقد التشغيل والصيانة مقاولة أم شبه تفويض؟

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

هل يمكن استخدام العقد النموذجي الصادر عن IPA كما هو؟

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

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

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

غو كومورا

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

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