متى تكون البرمجيات المخصّصة، ومتى يكون المنتج الجاهز؟
إذا لم تكن عمليتكم مختلفة عن الممارسة الشائعة في القطاع، ولم يُنتج هذا الاختلاف ميزة تنافسية، كان المنتج الجاهز هو الاختيار الصحيح. أمّا البرمجيات المخصّصة فتكون منطقية إذا كانت العملية مختلفة فعلًا، أو إذا بلغتم حدّ التخصيص في منتج جاهز، أو إذا لزم إبقاء البيانات وقواعد العمل في نظامكم. والقرار ليس مقارنة قوائم مزايا، بل تقييم أربعة معايير معًا.
معايير القرار الأربعة
- اختلاف العملية: هل سير العمل هذا مطابق لما لدى منافسيكم؟ فإن كان مطابقًا، لم يكن التطوير المخصّص إلّا إعادة إنتاج لحلّ مشترك.
- سرعة التغيّر: هل تتغيّر القاعدة مرّة في السنة أم مرّة في الشهر؟ فالقواعد كثيرة التغيّر تُنتج في المنتج الجاهز طلب تخصيص ومدّة انتظار في كلّ مرّة.
- ملكية البيانات: أين ستُحفظ البيانات، وبأيّ صيغة يمكن تصديرها وفي أيّ مدّة؟
- قابلية التسلّم: إذا تغيّر الفريق الذي طوّر البرنامج، هل يستطيع فريق آخر تسلّمه؟
وإذا لم يشر معياران على الأقلّ من الأربعة إلى البرمجيات المخصّصة، كان تخصيص منتج جاهز أقلّ تكلفة إجمالية في الغالب.
النموذج المختلط هو الجواب الصحيح غالبًا
البنية الأكثر نفعًا عمليًا هي استخدام منتج جاهز في المجالات القياسية كالمحاسبة والمخزون؛ وتطوير المجال المختلف تطويرًا مخصّصًا (بوابة الموزعين، وتطبيق الميدان، ومتابعة الإنتاج، وبوابة العملاء)، ثمّ ربط الطرفين بتدفّق بيانات عبر واجهة API. والنقطة الحرجة في هذا النموذج هي اتفاقية التكامل: أيّ سجلّ يُتحقّق منه في أيّ نظام، وأيّهما يفوز عند التعارض، وبأيّ مفتاح تجري مطابقة السجلّات.
اكتبوا قابلية التسلّم في العقد
أكبر خطر في البرمجيات المخصّصة ليس التقنية، بل احتكار المعرفة. فاطلبوا في مرحلة العقد ما يأتي:
- مستودع الشيفرة المصدرية وحقّ الوصول إليه؛ ويجب أن يكون متاحًا قبل انتهاء المشروع أيضًا
- وثيقة تنصيب مكتوب فيها خطوات تركيب عاملة
- مخطّط قاعدة البيانات ومعجم الحقول
- متغيّرات البيئة، وقائمة خدمات الأطراف الثالثة، وإصدارات التبعيات
- تجربة فعلية مرّة واحدة تثبت أنّ مطوّرًا جديدًا يستطيع تهيئة البيئة من الصفر وتشغيلها
والبند الأخير هو الأهمّ: فصحّة الوثيقة لا تتأكّد إلّا بتطبيقها مرّة واحدة.
ثلاثة قياسات تُبقي الدَّين التقني ظاهرًا
- زمن تهيئة البيئة: في كم من الوقت يُشغّل مطوّر جديد المشروع لأول مرّة؟
- زمن تسليم التغيير: في كم يومًا يخرج تغيير صغير في قاعدة عمل من الطلب إلى التشغيل الفعلي؟
- نسبة التراجع: كم من التغييرات المنشورة يُتراجَع عنها بسبب خطأ؟
فإذا كانت هذه الأرقام الثلاثة ترتفع، لم تكن المشكلة في سرعة الفريق، بل في المعمارية ونطاق الاختبار.
الطريق العملي لإبقاء النطاق صغيرًا
احصروا الإصدار الأول في مسار عمل واحد متكامل من طرفه إلى طرفه: سجلّ واحد يعمل من البداية إلى النهاية بمستخدم حقيقي وبيانات حقيقية. فإتمام مسار واحد رأسيًا بدل إضافة الوحدات أفقيًا يعطي ملاحظات مبكّرة ويُظهر مخاطر التكامل في بداية المشروع معًا.
الأسئلة الشائعة
لمن ينبغي أن تكون الشيفرة المصدرية في البرمجيات المخصّصة؟
هذا بند تعاقدي، لا أمر افتراضي. فيجب أن تُكتب ملكية الشيفرة وحقّ استخدامها وتراخيص مكوّنات الأطراف الثالثة كلٌّ على حدة. كما ينبغي إدراج أنواع تراخيص المكوّنات مفتوحة المصدر.
كيف يُتحقّق من الأمان في البرمجيات المخصّصة؟
أضيفوا إلى مرحلة القبول قائمة ضبط تشمل التحقّق من الهوية، والصلاحيات، وإدارة الجلسات، والتحقّق من المدخلات، وحفظ السجلّات. ويقدّم معيار OWASP للتحقّق من أمان التطبيقات هذه القائمة إطارًا جاهزًا، ويتيح لكم ضبط النطاق باختيار المستوى.
هل يستطيع فريق صغير الاستمرار في صيانة برمجيات مخصّصة؟
الاستدامة مرتبطة بالأتمتة أكثر من ارتباطها بحجم الفريق. فإذا وُجد اختبار آلي وتنصيب بأمر واحد ونشر قابل للتكرار، كفى الفريق الصغير؛ وإذا لم توجد، لم يكفِ الفريق الكبير.