حين تختار شركة تطوير برمجيات في الخليج، احكم عليها بالأدلة قبل العرض التقديمي. اطلب رؤية أعمال ذات صلة، والتقِ بالأشخاص الذين سيبنون مشروعك بأيديهم، واتفق على نطاق يسمّي المخرجات ومعايير القبول، وحدّد شروط التسليم والدعم قبل التوقيع. فالعرض المصقول يخبرك بمهارة الشركة في البيع، أما الأسئلة التالية فتكشف كيف تنفّذ، ومن يجيب حين يتعثر شيء، وما الذي ستملكه في النهاية.
وقبل البدء، تأكد أن التطوير المخصص هو الطريق الصحيح؛ إذ تساعدك الأسئلة التسعة للمفاضلة بين SaaS والبرمجيات المخصصة في هذا القرار.
لن تستطيع المقارنة بين الموردين إلا إذا ردّوا على الوصف نفسه، فاجعله قصيرًا ومحددًا:
- المشكلة، والمستخدمون، والنتيجة التي تحتاجها؛
- الميزات الأساسية، مع ذكر متطلبات العربية والإنجليزية بوضوح؛
- الأنظمة التي يجب التكامل معها، والبيانات المعنية، ومنها البيانات الشخصية؛
- القيود، مثل المواعيد ونطاق الميزانية ومتطلبات الاستضافة أو التنظيم؛
- ما تتوقع امتلاكه في النهاية: الكود والتصاميم والوثائق والحسابات.
واطلب من كل شركة في القائمة المختصرة كتابة افتراضاتها. فالفروق بين العروض ترجع في الغالب إلى افتراضات مختلفة عن النطاق، ومقارنتها على الورق أهون عليك من اكتشافها في منتصف المشروع.
كل شركة تستطيع القول إن لديها خبرة عميقة، فاطلب منها أن تُريك:
- أعمالًا ذات صلة يمكنك رؤيتها: منتجات قائمة أو مواد تفصيلية في مجال مشابه، مع توضيح ما أنجزته الشركة بنفسها فيها. اقبل مواد مصرحًا بها أو منقّحة، ولا تطلب معلومات سرية لعميل آخر.
- مراجع تختارها أنت: اطلب عدة مراجع، واتصل بالأقرب إلى مشروعك، واسأل عمّا تعثّر وكيف تصرفت الشركة، إلى جانب ما نجح.
- الفريق المسمّى: التقِ بمن سيقودون التصميم والهندسة والجودة في مشروعك، وثبّت أدوارهم كتابةً، واتفقوا على ما يحدث إن غادر أحدهم.
- طريقة العمل: نموذج من وثائقهم، وكيف يراجعون الكود ويختبرونه، وكيف يتعاملون مع الثغرات الأمنية والحوادث.
- عمل صغير مدفوع: مرحلة استكشاف قصيرة أو تجربة على مشكلة تمثيلية ببيانات اصطناعية أو مسموح بها ومحدودة تكشف لك عن أسلوب العمل والتواصل والجودة أكثر مما يكشفه أي عرض تقديمي.
شكل 1: التقِ بفريق التنفيذ. واطلب أدلة مصرحًا بعرضها.
يكون النطاق قابلًا للمساءلة حين يستطيع الطرفان معرفة هل سلّمته الشركة أم لا. فاكتب:
- المخرجات ومعايير القبول: معنى «مكتمل» لكل ميزة، بما في ذلك اللغتان وإمكانية الوصول وفحوص الأداء المتفق عليها.
- مراحل مرتبطة ببرمجيات عاملة يمكنك مراجعتها، لا بنسب من الجهد المبذول.
- ضبط التغيير: كيف يطلب أي طرف تغييرًا، ومن يقدّره ويعتمده ويوثّقه، ومن يملك صلاحية الاعتماد في كل طرف.
- الأدوار والقرارات: من يجيب عن الأسئلة ويعتمد المخرجات من جهتك وبأي سرعة، فالتأخر من جهة العميل يبطئ المشاريع أيضًا.
- المخاطر والافتراضات، وتُراجع في كل مرحلة.
والعرض الذي يقل كثيرًا عن غيره يستحق الأسئلة لا الريبة: اسأل أي الافتراضات جعلته منخفضًا، وهل تطابق وصف مشروعك.
اسأل كيف ستصمم الشركة نظامك وتشغّله وتحميه. ويقدّم إطار AWS Well-Architected ستة مجالات مفيدة لهذا الحوار: التميز التشغيلي، والأمان، والموثوقية، وكفاءة الأداء، وتحسين التكلفة، والاستدامة. وتنتقل مبادئه إلى بيئات أخرى، أما إرشادات التنفيذ الخاصة بخدمات AWS فتحتاج إلى تكييف. والقائمة تنظّم المراجعة لكنها لن تلتقط كل شيء. ويعرض دليلنا عن قرارات المعمارية من المنتج الأولي إلى التوسع القرارات المبكرة التي تستحق النقاش المفصل.
وإمكانية الوصول تحتاج الاهتمام نفسه. فمعايير WCAG 2.2 من W3C تغطي الوصول بلوحة المفاتيح، والبدائل النصية، والتركيز المرئي، والتباين. اسأل الشركة كيف تختبرها بالعربية والإنجليزية، بما في ذلك التخطيط من اليمين إلى اليسار، وتذكّر أن نجاح الفحص الآلي لا يشهد بإمكانية الوصول. وإن ولّدت أدوات الذكاء الاصطناعي أجزاء من الواجهة، فلا بد أن يراجع إنسان إمكانية الوصول والنص العربي، كما يوضح مقالنا عن أنظمة التصميم بمساعدة الذكاء الاصطناعي.
ينبغي أن تستطيع المتابعة دون الشركة الأصلية، باختيارك أو اضطرارًا. فاتفق من البداية على:
- الملكية: اتفق على الملكية أو حقوق الاستخدام المستمر للكود والتصاميم والمخرجات المخصصة. وحدّد الأدوات السابقة والمكوّنات مفتوحة المصدر وتراخيص الأطراف الأخرى منفصلةً؛ فقد لا تنتقل ملكيتها إليك.
- حساباتك: مستودعات الكود، والاستضافة السحابية، والنطاقات، والتحليلات، والخدمات الخارجية، كلها في حسابات تتحكم بها، مع منح موظفي الشركة صلاحيات مسماة بالحد الأدنى. اختبر البناء والنشر والاستعادة مع الفريق المستلم، وألغِ الوصول السابق ودوّر بيانات الاعتماد المتأثرة عند الانتقال.
- الوثائق: نظرة عامة على المعمارية، وتعليمات الإعداد والنشر، وأدلة تشغيل للحوادث الشائعة، وسجل للقرارات الرئيسية.
- نقل المعرفة: جلسات مع فريقك أو مع شريك جديد قبل انتهاء التعاقد، وفترة انتقالية مكتوبة في العقد.
شكل 2: خطط للتسليم. اتفق على الحقوق واختبر الانتقال.
الإطلاق هو بداية الدعم، فحدّده قبل التوقيع:
- ساعات الدعم وأهداف الاستجابة حسب درجة الخطورة، مع فصلها عن أهداف الاستعادة أو الحل؛
- من يراقب النظام ومن يتولى المناوبة؛
- نطاق الصيانة ورسومها، ومنها الإصلاحات الأمنية العاجلة وترقيات الاعتماديات وتغييرات المنصات؛
- فترة ضمان لإصلاح العيوب بعد الإطلاق، وطريقة تقدير الطلبات الجديدة وترتيب أولوياتها.
واكتب ذلك في اتفاقية خدمة بتقارير واضحة وجهات تصعيد وشروط خروج تشمل تصدير البيانات والاحتفاظ بها وحذفها، حتى يرى كل طرف هل يفي الآخر بالتزاماته.
لا تثبت أيٌّ منها أن الشركة غير مناسبة لك، لكن كلًّا منها يستحق سؤالًا مباشرًا: التردد في العمل وفق وصف مكتوب، أو عدم إتاحة الأشخاص الذين سينفذون العمل، أو إجابات غامضة عن ملكية الكود والحسابات، أو غياب منهج اختبار واضح، أو عرض سعر بلا افتراضات معلنة.
وإن كنت تختار شريكًا لموقع أو منصة ويب، فقيّمنا بالطريقة نفسها؛ وصفحة خدمة تصميم وتطوير المواقع نقطة بداية لهذا الحوار.
- Amazon Web Services. AWS Well-Architected Framework: ست ركائز لمراجعة المعمارية المقترحة.
- W3C. WCAG 2.2 quick reference: معايير نجاح إمكانية الوصول، ومنها الوصول بلوحة المفاتيح والبدائل النصية والتركيز والتباين.
هذه القائمة إرشادات عامة من تكنوستاك، لا استشارة قانونية؛ فاعرض العقود على مستشار قانوني مؤهل.
