الفرق بين الخطأ البرمجي والطلب الجديد
الخطأ البرمجي (Bug) هو أن النظام لا يعمل كما اتُّفق عليه في العقد أو نطاق العمل، وإصلاحه عادة ضمن الضمان أو عقد الصيانة دون تكلفة إضافية. أما الطلب الجديد (Change Request) فهو إضافة ميزة أو تعديل سلوك لم يكن موجوداً في الاتفاق الأصلي، ويُقدَّر له وقت وتكلفة منفصلة. التمييز الدقيق بينهما يحمي العميل من فوجئة الفواتير، ويحمي مزود الخدمة من العمل المجاني غير المحدود.
لماذا يهم هذا التمييز في السوق السعودي؟
كثير من الخلافات بين أصحاب الأعمال في الرياض وجدة والدمام ومزودي البرمجة لا تنشأ من سوء نية، بل من غياب تعريف واضح لكلمة "خطأ" داخل العقد. صاحب المشروع يرى أن أي طلب تعديل هو "إصلاح"، بينما يرى المطوّر أن أي طلب خارج الاتفاق الأصلي هو عمل إضافي يستحق مقابلاً.
عندما يكون التعريف غامضاً، تتحول كل مكالمة دعم فني إلى نقاش حول من يدفع، وهذا يبطئ المشروع ويستهلك الثقة بين الطرفين. الحل ليس في النية الحسنة فقط، بل في صياغة عقدية واضحة منذ البداية عند التعاقد على برمجة الأنظمة أو تطبيقات الجوال أو أي مشروع تقني.
ما هو الخطأ البرمجي (Bug)؟
الخطأ البرمجي هو انحراف النظام عن السلوك المتفق عليه كتابياً في وثيقة نطاق العمل أو المواصفات الوظيفية. بمعنى آخر: إذا كان العقد ينص على أن الفاتورة تُحسب بضريبة القيمة المضافة 15%، وظهرت الفاتورة بدون ضريبة، فهذا خطأ برمجي يجب إصلاحه دون تكلفة إضافية.
من أمثلة الأخطاء الشائعة في المتاجر الإلكترونية: عدم إرسال إشعار تأكيد الطلب، أو تكرار خصم المبلغ من بطاقة العميل، أو ظهور الأسعار بعملة خاطئة. هذه كلها حالات لم يعمل فيها النظام كما وُعد به، لا كما يتمناه العميل حديثاً.
ما هو الطلب الجديد (Change Request)؟
الطلب الجديد هو أي إضافة أو تعديل لم يكن مذكوراً في نطاق العمل الأصلي، حتى لو بدا "بسيطاً" من وجهة نظر العميل. مثال: عيادة تعاقدت على نظام حجز مواعيد بسيط، ثم طلبت لاحقاً إضافة تذكير تلقائي عبر واتساب وربط النظام بتقارير مالية شهرية — هذا تطوير جديد وليس إصلاح خلل.
حتى لو كان الطلب صغيراً في الوقت، فإنه يُصنَّف تغييراً في النطاق (Scope Change) لأنه يضيف قيمة جديدة لم يُتفق عليها ولم تُحسب في السعر الأصلي.
| المعيار | خطأ برمجي (Bug) | طلب جديد (Change Request) |
|---|---|---|
| التعريف | النظام لا يطابق ما اتُّفق عليه كتابياً | ميزة أو سلوك غير موجود في الاتفاق الأصلي |
| من يدفع؟ | مزود الخدمة، ضمن الضمان أو عقد الصيانة | العميل، بتسعير إضافي منفصل |
| الأولوية | عاجلة، خصوصاً إن أثرت على المبيعات أو البيانات | تُجدول ضمن خطة تطوير لاحقة |
| مثال عملي | فشل تسجيل الدخول لبعض المستخدمين | إضافة تطبيق جوال لنظام كان موقعاً فقط |
| المرجع العقدي | وثيقة المواصفات أو نطاق العمل الموقّع | ملحق تعديل نطاق (Scope Addendum) جديد |
كيف تفرّق بين الحالتين عملياً؟
- ارجع لوثيقة النطاق: اقرأ ما هو مكتوب حرفياً في العقد أو المواصفات الأولية، وليس ما تتذكره من نقاش شفهي.
- اسأل: هل كان هذا السلوك موجوداً ثم توقف؟ إن كانت الميزة تعمل سابقاً وتوقفت فجأة، فهذا خلل تقني وليس طلباً جديداً.
- قيّم الأثر على الوظيفة الأساسية: إن كان الخلل يمنع إتمام عملية أساسية (دفع، تسجيل، حجز) فهو خطأ حرج يستحق أولوية فورية.
- وثّق الطلب كتابياً: أرسل وصفاً مكتوباً بالمشكلة مع صور أو تسجيل شاشة، فهذا يسرّع تصنيفها ويمنع الجدال لاحقاً.
- اطلب تصنيفاً رسمياً من مزود الخدمة: شركة محترفة تُصنّف كل تذكرة دعم فوراً كـ"خطأ" أو "تطوير جديد" مع سبب واضح.
بعض الحالات تقع في منطقة رمادية، مثل تحسين الأداء أو تعديل تصميم واجهة لتوضيح رسالة خطأ. في هذه الحالات، يفضَّل أن يحدد العقد آلية تحكيم بسيطة، مثل الرجوع لمواصفات المشروع الأصلية أو رأي طرف ثالث محايد.
لماذا يفضَّل توثيق هذا الفرق في العقد من البداية؟
الشركات التي تطلب من تصميم وتطوير المواقع أو المتاجر الإلكترونية عقداً واضحاً منذ اليوم الأول توفر على نفسها أسابيع من الجدل لاحقاً. العقد الجيد يحدد:
أولاً: قائمة المواصفات الوظيفية الدقيقة (ما الذي يفعله النظام تحديداً). ثانياً: مدة ضمان ما بعد التسليم (عادة 30 إلى 90 يوماً حسب حجم المشروع). ثالثاً: آلية تسعير الطلبات الجديدة بعد انتهاء الضمان، سواء بالساعة أو بحزمة شهرية ضمن خدمة الصيانة الدورية.
عند التعاقد على نظام إدارة علاقات العملاء CRM (نظام لإدارة بيانات العملاء ومتابعة المبيعات) أو نظام الموارد البشرية، اطلب أن يتضمن العقد جدول أسعار واضح لأنواع طلبات التطوير المستقبلية، بدلاً من ترك التسعير مفتوحاً لكل طلب.
دور عقد الدعم الفني في تقليل الخلافات
الاشتراك في خدمة الدعم الفني الشهرية أو السنوية يمنح العميل أولوية في الاستجابة للأخطاء، مع تحديد مسبق لعدد ساعات التطوير الجديد المشمولة ضمن الباقة شهرياً. هذا يحوّل النقاش من "من يدفع؟" إلى "كم ساعة تبقّت من رصيدنا هذا الشهر؟" وهو نقاش أسهل بكثير وأكثر شفافية.
احذر من مزودي خدمة يصنّفون كل طلب "خطأ" على أنه تطوير جديد لتحصيل رسوم إضافية متكررة. اطلب دائماً تبريراً مكتوباً مرتبطاً بوثيقة المواصفات الأصلية قبل الموافقة على أي فاتورة إضافية.
ماذا لو كان النظام قديماً وبلا وثائق واضحة؟
كثير من المنشآت في السوق السعودي ورثت أنظمة قديمة بلا عقد موثّق أو مواصفات مكتوبة، خصوصاً في القطاعات الصحية والتعليمية. في هذه الحالة، يُنصح بإجراء مراجعة فنية أولية (Audit) لتوثيق السلوك الحالي كخط أساس، بحيث يصبح أي انحراف مستقبلي عنه "خطأ" واضحاً، وأي إضافة عليه "تطوير جديد" واضحاً أيضاً. هذه الخطوة مفيدة خصوصاً لعملاء أنظمة العيادات والتعليم التي تُدار عليها بيانات حساسة وعمليات يومية متكررة.
- الخطأ البرمجي هو انحراف عن المتفق عليه كتابياً، وإصلاحه ضمن الضمان أو الصيانة دون تكلفة.
- الطلب الجديد هو إضافة قيمة أو ميزة لم تكن في الاتفاق الأصلي، ويُسعَّر بشكل منفصل.
- الرجوع لوثيقة نطاق العمل هو المرجع الحاسم عند أي خلاف حول التصنيف.
- عقد صيانة أو دعم فني واضح يقلل الخلافات ويسرّع الاستجابة للمشاكل الحرجة.
- توثيق كل طلب كتابياً منذ البداية يحمي الطرفين ويوفر وقتاً وماللاً.
أسئلة شائعة
نعم عادة، طالما أن الخلل يمثل انحرافاً عن المواصفات المتفق عليها كتابياً وضمن فترة الضمان المحددة في العقد، والتي تتراوح غالباً بين 30 و90 يوماً بعد التسليم حسب حجم المشروع.
إذا كانت الميزة أو السلوك المطلوب غير مذكور أصلاً في وثيقة المواصفات أو نطاق العمل الموقّع، فهذا يُصنَّف طلباً جديداً حتى لو بدا تعديلاً بسيطاً من الناحية التقنية.
الرجوع لوثيقة النطاق أو المواصفات الأصلية هو الفيصل. إن لم توجد وثيقة واضحة، يُنصح بإجراء مراجعة فنية توثّق السلوك الحالي كمرجع لأي خلاف مستقبلي.
غالباً يشمل عقد الصيانة إصلاح الأخطاء وعدداً محدداً من ساعات التطوير الجديد شهرياً، وما يتجاوز ذلك يُحتسب بشكل منفصل حسب جدول أسعار متفق عليه مسبقاً.
إذا كنت تخطط لمشروع تقني جديد أو تواجه خلافاً حول تصنيف طلب معين في نظامك الحالي، فريق بوابة الحلول التقنية يساعدك على صياغة نطاق عمل واضح وعقد صيانة عادل يحمي مشروعك من المفاجآت. اطلب عرض سعر أو استشارة مجانية الآن وسنراجع وضعك الحالي معك خطوة بخطوة.