كيف تختار شركة تطوير برمجيات في السعودية

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

١. من يملك الكود عند انتهاء المشروع؟

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

٢. هل تفهم المتطلبات التنظيمية السعودية تحديداً؟

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

٣. ماذا يحدث عندما يتعطل شيء ما في الثالثة فجراً؟

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

٤. هل منهجيتهم واضحة، أم مجرد شريحة عرض؟

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

٥. هل يمكنهم أن يُروك التقنية المستخدمة فعلياً، لا العرض التوضيحي فقط؟

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

٦. هل نموذج التسعير شيء توقّعه دون الحاجة لمحامٍ يقرأه مرتين؟

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

الخلاصة

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

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