منصة جاهزة أم نظام مخصص؟ اختبر طريقة العمل أولًا.

اسم البرنامج لا يشرح الاحتياج

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

فرّق بين قاعدة ضرورية وعادة قديمة

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

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

هناك ثلاثة مسارات يمكن الجمع بينها

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

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

اجعل المورّد يعمل على مثال منك

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

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

ناقش التشغيل قبل الانشغال بالمزايا

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

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

ابدأ بإصدار يتيح اتخاذ قرار

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

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