لماذا تتعثر مشاريع البرمجة في السعودية؟ سبعة أسباب واقعية وكيف تتجنبها

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

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

العَرَض المبكر: الاجتماعات ممتازة والتفاهم «واضح»، لكن لا يوجد مستند واحد يحدد ما سيُسلَّم.

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

لماذا يكلّف كثيراً؟ النطاق الغامض لا يخلق مشكلة واحدة بل مشكلتين متناقضتين: العميل يتوقع ما لم يُتفق عليه، والمنفّذ يبني ما فهمه. وفي النهاية يخسر الطرفان الوقت والمال والثقة.

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

العَرَض المبكر: ثلاثة عروض، والفارق بين أرخصها وأغلاها ضخم — ويُحسم القرار للسعر.

لماذا يحدث؟ لأن التكلفة أسهل شيء يمكن مقارنته حين لا تعرف كيف تقارن الجودة.

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

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

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

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

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

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

العَرَض المبكر: أحد يسأل في الأسبوع الأخير: «والفواتير؟ النظام يصدر فواتير؟»

لماذا يحدث؟ لأن المتطلبات التنظيمية لا تظهر في شاشات التصميم الجميلة، فلا يتذكرها أحد.

لماذا يكلّف كثيراً؟ التوافق ليس ميزة تُضاف في أسبوع؛ يغيّر بنية الفاتورة وتخزين البيانات وتدفق العمليات. تأجيله إلى ما قبل الإطلاق يعني إعادة عمل في جوهر النظام.

العلاج: اذكر المتطلبات النظامية صراحةً في طلب العرض من اليوم الأول، واسأل كل مزوّد: كيف تعالجونها في الأنظمة التي تبنونها؟ للمجال المالي دليل الفوترة الإلكترونية، وللمجال الطبي حماية بيانات المرضى.

العَرَض المبكر: «خلاص النظام جاهز، ننشره الأسبوع الجاري»، بلا بيئة تجريبية وبلا خطة لتدريب الموظفين.

لماذا يحدث؟ ضغط الموعد، ورغبة الجميع في رؤية النتيجة.

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

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

العَرَض المبكر: «البيانات في ملفات Excel، ننقلها بسيطة».

لماذا يحدث؟ لأن ترحيل البيانات غير مرئي: لا شاشة له في التصميم، فلا يُقدَّر حجمه.

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

العلاج: اعتبر ترحيل البيانات مرحلة مستقلة في المشروع لها وقتها ومسؤولها، وابدأ تنظيف البيانات قبل انتهاء التطوير لا بعده. التفاصيل في ترحيل النظام القديم دون توقف العمل.

العَرَض المبكر: لا أحد يعرف كلمة مرور الخادم، والكود عند المبرمج، والتعديل البسيط يحتاج أسبوعاً ومبلغاً.

لماذا يحدث؟ لأن العقد انتهى عند التسليم، ولم يُسأل أحد: من يملك هذا النظام غداً؟

لماذا يكلّف كثيراً؟ نظام بلا مالك يتوقف عن التطور عند لحظة إطلاقه، بينما عملك يتغير كل شهر. خلال سنة يصبح النظام عبئاً بدل أن يكون أصلاً.

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

إن كنت تقرأ هذا وأنت في مشروع متعثر فعلاً، فالترتيب التالي يعمل أسرع من تغيير المزوّد:

1. جمّد النطاق أسبوعاً، لا التطوير. أوقف إضافة الميزات، واكتب ما تم إنجازه وما تبقّى. كثير من المشاريع «المتعثرة» تكون في الحقيقة مشاريع مكتملة بنطاق متضخم.
2. حدّد أكبر عائق واحد. ليس كل المشاكل تحتاج حلاً متزامناً. اسأل: ما الشيء الذي إن حُلّ تحرّك كل شيء بعده؟
3. اطلب عرضاً مرئياً أسبوعياً. لا تقارير مكتوبة: شاشة تعمل، تراها بنفسك. الرؤية المباشرة تكشف الفجوة بين ما يُقال وما يُنجز.
4. أعد التفاوض على المراحل لا على السعر. تقليص النطاق مع تسليم مرحلة عاملة أفضل من مشروع كامل متأخر.
5. ثبّت ملكية ما أُنجز. احصل على الكود والحسابات والتوثيق مهما كانت حالة المشروع — فهذه أساس أي انتقال لاحق.

هل تغيير شركة التطوير في منتصف المشروع فكرة جيدة؟

أحياناً، لكنها مكلفة: ستدفع مقابل ما أُنجز مرتين، وسيفقد الفريق الجديد وقتاً في فهم ما بُني. جرّب أولاً تجميد النطاق وتحديد العائق الأكبر، ثم قرّر.

هل أوقف المشروع أم أكمله؟

أكمل إن كانت المشكلة إدارية (نطاق، تواصل، قرارات) — فهذه تُحل. وأوقف أو أعد التوجيه إن اكتشفت أن الافتراض الأساسي للمشروع نفسه كان خاطئاً.

كم مرة يجب أن أرى تقدّماً فعلياً؟

كل أسبوع إلى أسبوعين على الأكثر. غياب نتيجة مرئية لأكثر من ثلاثة أسابيع علامة تحتاج سؤالاً مباشراً.

من يتحمل مسؤولية المتطلبات النظامية؟

المزوّد مسؤول عن معرفتها وتطبيقها، لكن العميل مسؤول عن ذكر مجاله وطبيعة بياناته بوضوح. التوضيح في طلب العرض يحمي الطرفين.

ما أهم بند في العقد؟

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

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