عند التفاوض على أسعار مشروع برمجيات مخصصة، فإن الوحدة الأكثر شيوعًا التي يتوافق عليها الطرفان أ و ب هي«الإنسان والسماء»: كم عدد المهندسين، وكم يومًا من العمل، وكم تبلغ التكلفة لكل وحدة. هذا النموذج ينجح فقط عندما تكون المتطلبات مستقرة وحدود التسليم واضحة؛ لكن ما إن تتغير قواعد العمل في الموقع بشكل متكرر، وتُرفع كفاءة البرمجة بفضل أدوات الذكاء الاصطناعي، بينما يواصل العميل المُتَلَقِّي اعتماد نهج «تكديس الأعداد» في عملية القبول، حتى تندلع التناقضات—حيث يشعر الطرف الثاني بأن المتطلبات تتوسع، بينما يرى الطرف الأول أن «عدد الأشخاص لم يزد، لكن المنتج لم يزد أيضًا».
إشارة سياسية: من بيع الأرواح إلى بيع النتائج
في سبتمبر 2026، أصدرت وزارة الصناعة وتكنولوجيا المعلومات خطة تنفيذية للحملة الخاصة بـ«الذكاء الاصطناعي + البرمجيات»، والتي تطرقت مرارًا إلى دفع التحول في نماذج إنتاج البرمجيات وتطوير «النموذج كخدمة» و«الكيان الذكي كخدمة»، كما حددت بوضوح أنه بحلول عام 2028 سيتم إنشاء تطبيقات نموذجية لبرمجيات الكيانات الذكية في القطاعات الرئيسية. ولم يُلغِ الوثيقة التطوير المخصص، لكنها أوصلت رسالة واضحة:عند تقييم قيمة البرمجيات، يزداد التركيز على الفعالية العملية بدلاً من الاقتصار على حساب عدد أيام العمل المبذولة.。
بالنسبة للشركات التي تعمل على أنظمة ERP وMES وCRM وأنظمة إدارة القطاعات، فهذا يعني أنه إذا ظل العقد ينص فقط على «XX شخصًا × XX يومًا»، فسيكون من السهل بعد التشغيل أن تقع في جدل حول «انتهاء كتابة الكود، لكن لا يمكن استخدام النظام في الأعمال». أما الصياغة الأكثر استدامة، فهي تقسيم التسليم إلىنتائج الأعمال القابلة للاستلام。
منطق الأعمال: يجب أن تكون المعالم أكثر تحديداً من الأيام البشرية
قم بترقية المشروع من «الدفع حسب المرحلة» إلى «الدفع حسب المحطة الرئيسية»، ويجب أن يستوفي كل محطة رئيسية أربعة شروط في الوقت نفسه:
- سيناريوهات الأعمال: من يستخدمها، وما هي العمليات التي تحلها (على سبيل المثال، «مسجّل المخزون يمسح الباركود لتسجيل الدخول» بدلاً من «إكمال وحدة تسجيل الدخول»).
- نطاق البيانات: ما هي البيانات الرئيسية وحقول الحالة ونطاق الأذونات المعنية، وما هي قواعد أخذ العينات؟
- سكريبت التحقق من الاستلام: بناءً على بيانات الاختبار المُعطاة، أيّ العمليات يتم تنفيذها، وما هي المستندات أو التقارير الناتجة.
- معالجة الاستثناءات: كيف يُظهر النظام تنبيهات عند الفشل، ومن له صلاحية التعديل، وهل يتم تسجيل الأثر.
لا ينبغي أن يتجاوز عدد المراحل الرئيسية2–4 أسابيعواحد؛ أما إذا كان طويلًا جدًا فسيُعاد إلى «التطوير في الصندوق الأسود». مثال نموذجي للتقسيم: البيانات الرئيسية والصلاحيات → الدورة المغلقة للمستندات الأساسية → التقارير والتسوية → الواجهات وتبديل التشغيل.
منطق التصميم: نطاق التغييرات و«المساعدة الذكية» مُدرجان في العقد
الترميز بمساعدة الذكاء الاصطناعي، والإنشاء التلقائي لحالات الاختبار، والملء الذكي للوثائق، ستغيّر استهلاك الأيام البشرية لنفس الوظيفة، لكنلا يغيّر تعقيد الأعمال تلقائيًا. يُقترح إدراجها بشكل منفصل في العقد ومواصفات المتطلبات:
- خط الأساس (Baseline): قائمة الميزات + قائمة العناصر خارج النطاق (Out of Scope)، يجب أن تُقدَّم طلبات التغيير عبر نموذج طلب التغيير.
- تغيير قواعد التسعير: تُضاف معالم جديدة بناءً على تقدير «السيناريو + نصوص التحقق»، بدلاً من إضافة أيام العمل بشكل مؤقت.
- الحدود المساعدة الذكية: أيّ المراحل يمكن تحسين كفاءتها باستخدام الذكاء الاصطناعي (توليد الكود، مسودات الوثائق)، وأيّها يجب أن يُوقّع عليها يدويًا (الأمن، الامتثال، الالتزامات الخارجية).
- 归属 لترسيخ المعرفة: من يحتفظ بوثائق العملية والتكوينات والسكريبتات، لتجنب انقطاع الصيانة بعد التسليم.
التطوير والتنفيذ: أتمتة القبول والقابلية للمراقبة
لجعل «التوجه نحو النتائج» قابلاً للتنفيذ، يتعين على الجانب التقني التعاون في ثلاث أمور:
- إدراج حالة اختبار القبول في المخزون: يتوافق كل معلم رئيسي مع مجموعة من حالات الاستخدام الآلية أو شبه الآلية، ويمكن إعادة تشغيل الاختبارات بشكل متكرر.
- البيئة والعزلة البياناتية: يمكن إعادة تهيئة بيانات بيئة UAT لتجنب مشكلة «العمل فقط في بيئة العرض».
- سجلات قابلة للمراقبة: تتوفر سجلات تدقيق للعمليات الرئيسية، مما يتيح إمكانية تتبع من قام بتعديل أي شيء في حال وجود نزاع.
إذا كان المشروع يحتوي على عامل ذكي أو محرك قواعد، فيجب إضافة ذلك إلى عملية القبول.آلية الفحص العشوائي: إدخال حالات حدودية عشوائية، والتحقق من أن رفض الإجابة، ورفع القضية إلى فريق العمل البشري، وحجب الصلاحيات تتماشى مع التصميم، بدلاً من الاكتفاء بالنظر إلى «إمكانية الدردشة».
ثلاثة أنواع شائعة من النزاعات والوقاية منها
الجدل الأول: «تم تنفيذ جميع الوظائف، فلماذا لا تستخدمها الأعمال؟»——الوقاية: ربط المراحل الرئيسية بعمليات المناصب وتسجيل الحضور في التدريب، والقيام بجولات ميدانية أثناء عملية القبول، وليس الاكتفاء بعرض عرض تقديمي على الـ PPT.
الجدل الثاني: «لماذا يُطلب دفع مبلغ إضافي لإضافة طلب صغير؟»——الوقاية: يُكتب في طلب التغيير مراحل الإنجاز المتأثرة، والسكربتات، ومدة التنفيذ، ثم يُوقع الطرفان قبل البدء بالتطوير.
الجدل الثالث: «هل يمكن تقليل عدد أيام العمل بعد أن زادت كفاءة الذكاء الاصطناعي؟»——الوقاية: يميّز العقد بين «تكلفة التنفيذ» و«درجة تعقيد الأعمال»؛ ويمكن إظهار عوائد تحسين الكفاءة في التكلفة الإجمالية أو المدة، لكن معايير القبول لا تُخفَّض.
اقتراح تجريبي: ابدأ بوحدة مغلقة الحلقة
لا داعي لانتظار إعادة كتابة العقد للنظام بأكمله. اختر واحدًا2–3 أسابيع كافية لإغلاق الحلقةالوحدات (مثل الوارد والصادر، تسجيل الأعمال، واعتماد النفقات)، يتم إعداد اتفاقية تكميلية باستخدام القالب الجديد: مع ذكر السيناريوهات، والسكربتات، والاستثناءات، ومرحلة الدفع. وبعد التأكد من سير العملية بشكل صحيح، يتم تعميمها على جميع المشاريع. ولقياس النجاح، يُنظر إلىهل يقلل نموذج التغيير من وقت النزاعات؟、هل ارتفع معدل النجاح في اختبار UAT من المرة الأولى؟، وليس من خلال النظر إلى عدد الأيام التي قلّل الطرف الثاني من تقريرها.
لن يختفي الإنسان بين ليلة وضحاها، لكنه يتحول تدريجياً من «وحدة التسعير الوحيدة» إلى «مرجع لتقدير التكاليف». إن تضمين المراحل الرئيسية ونصوص التحقق في العقد هو الأساس الذي يتيح للبرمجيات المخصصة، في ظل سياق «الذكاء الاصطناعي + البرمجيات»، تقديم نتائج موثوقة.
بالتنسيق مع السعر الإجمالي الثابت والتكرار الرشيق
لا يُعدّ قبول المراحل الرئيسية متعارضًا مع الأجايل: فلا يزال بإمكان كل سبرينت تسليم زيادة قابلة للعرض، لكنالدفع والقبول الرسميمعلّق على معلم رئيسي أكبر. يجب في عقود السعر الثابت بشكل خاص تحديد «نقطة تجميد النطاق» بوضوح — أي أن أي متطلبات جديدة تُضاف بعد مراجعة معينة تُعالج عبر طلب تغيير، لتجنب إضافة الميزات شفهياً. وبالنسبة للموديول الذي يحتوي على كيانات ذكية، يُنصح باعتماد معلم رئيسي منفصل للتحقق من «إصدار القاعدة + نسبة نجاح الفحص العشوائي»، وعدم ربطه بشكل جامد بإطلاق الموقع بأكمله.
تشير بيانات الصناعة إلى أن مشاريع البرمجيات تفشل بنحوثلثينبع ذلك من عدم وضوح معايير المتطلبات والقبول، وليس من طبيعة التنفيذ التقني بحد ذاته. إن تدوين «ما المقصود بالانتهاء» في العقد أولاً يُعد أكثر قيمة من الجدال حول عدد المبرمجين الذين استبدلهم الذكاء الاصطناعي. عند مراجعة مشروع التأسيس المقبلة، يمكن بدايةً طرح سؤال واحد: إذا أخذ جميع أفراد الجهة الثانية إجازة غداً، فهل نستطيع، بالاعتماد على النص البرمجي، تحديد ما إذا كان المعلم المرحلي الحالي قد استوفى المتطلبات أم لا؟ وإذا تعذر الإجابة، فهذا يعني أن معايير القبول لم تُوضَّح بشكل كافٍ بعد.