معظم الطلبات التي تصل بصيغة «نحتاج إلى تطوير هذه الميزة» ليست طلبات تطوير أصلاً. هي طلبات إعداد وتهيئة ترتدي ثوب البرمجة. فـ Odoo القياسي يغطي قدراً أكبر بكثير مما تتوقعه الفرق الجديدة، والفرق بين تعديل إعداد وبين طلب كود مخصص هو الفرق بين ساعتين ومشروع كامل.
اتخاذ هذا القرار بشكل صحيح قبل أن يكتب أحد سطراً واحداً من أكثر العادات فائدة لأي فريق ERP. وفيما يلي طريقة عملية لاتخاذه بوعي بدلاً من الاعتماد على الحدس.
ما الذي يغطيه الإعداد فعلاً
الإعداد هو كل ما يمكنك تغييره من داخل واجهة Odoo نفسها دون المساس بأي وحدة برمجية، وهي مساحة أوسع بكثير مما يظنه كثيرون:
- صلاحيات الوصول ومجموعات المستخدمين وقواعد السجلات التي تحدد من يرى ماذا
- تصميم المستندات وقوالب البريد وصياغة عروض الأسعار والفواتير
- قوائم الأسعار والضرائب وشروط الدفع وسياسات الخصم
- مسارات المستودعات وأنواع العمليات والاستلام أو التسليم متعدد الخطوات
- حدود الاعتماد والموافقة المزدوجة وتعريف المراحل في المشاريع وخطوط البيع
- قواعد الأتمتة التي تُشغَّل عند تغيّر حقل أو حلول تاريخ أو انتقال مرحلة
- حقول إضافية تُنشأ بأدوات Odoo نفسها وتُوضع على النماذج والقوائم القائمة
إذا كان مطلبك ضمن هذه القائمة فأنت لا تحتاج إلى مطوّر، بل إلى شخص يعرف أين يوجد الإعداد.
متى يكون التخصيص هو الجواب الصحيح
التخصيص مبرَّر حين يكون السلوك المطلوب غير موجود في أي وحدة قياسية ولا يمكن تركيبه منها. عملياً يعني ذلك واحداً من أربعة: حساب لا يجريه Odoo، أو نوع مستند أو عملية غير موجود أساساً، أو تكامل مع نظام ليس له موصّل جاهز، أو قرار تريد من النظام أن يتخذه لا مجرد خطوة تريد منه أن يسجلها.
هذه أسباب مشروعة للبناء. والمنطق الخاص بكل قطاع تحديداً يكون حقيقياً في الغالب: جدول محتجزات في المقاولات، أو دورة فوترة إيجارية، أو نموذج عمولات لا يستخدمه أحد غيرك. وهذا بالضبط ما يتولاه فريقنا ضمن التطوير المخصص على Odoo، ويستحق أن يُنفَّذ بشكل صحيح متى كان المطلب حقيقياً.
أربعة أسئلة تحسم الأمر عادة
هل تستطيع تسمية الميزة القياسية التي يحل هذا محلها؟ إذا كانت هناك وحدة قياسية تفعل شيئاً قريباً، فأنت في منطقة الإعداد على الأرجح. الفجوة عادة 20% من المطلب لا 100%.
هل المسألة بيانات أم سلوك؟ الرغبة في رؤية رقم يخزّنه Odoo أصلاً هي تقرير أو عرض. أما الرغبة في أن يتصرف النظام بشكل مختلف فهي كود.
هل كنت ستقبل المسار القياسي لو شُرح لك جيداً؟ نسبة معتبرة من طلبات التخصيص هي تفضيلات إجرائية موروثة من النظام السابق، تبدو كمتطلبات لأن الفريق اعتاد عليها لسنوات، وليست دائماً جديرة بأن تُنقل معك.
هل يصمد المطلب أمام ثلاث دورات من سؤال «لماذا»؟ اسأل لماذا نحتاج هذا الحقل، ولماذا هذه القيمة، ولماذا في هذه اللحظة. المتطلبات التي تتبخر بعد ثلاثة أسئلة كانت حلولاً متنكرة في هيئة متطلبات.
التكلفة التي لا تراها في اليوم الأول
كل تخصيص هو عبء تحمله معك في كل ترقية إصدار لاحقة. الإعداد ينتقل معك في الغالب، أما الكود المخصص فيجب مراجعته مع كل إصدار جديد واختباره وأحياناً إعادة كتابته حين يتغير النموذج الأساسي تحته. هذه ليست حجة ضد التخصيص، بل حجة للتخصيص عن قصد وبفهم واضح لما يشتريه لك التغيير.
قاعدة مفيدة: إذا أوصلك الإعداد إلى 80% من النتيجة، فسعّر الـ 20% المتبقية بصدق، بما في ذلك ذيلها في الترقيات، قبل أن تطلبها.
أين تُحسم المنطقة الرمادية
كثير من الطلبات يقع في المنتصف: نصفها تفضيل إجرائي ونصفها فجوة حقيقية، ولا أحد يستطيع التمييز قبل أن يُكتب المطلب بدقة.
وهذا هو الجزء الذي بُني حوله Plemo. تبدأ الطلبات كمحادثة، وتطرح المنصة أسئلة توضيحية بدل أن تقبل الصياغة الأولى كما وردت، والطلبات المفرطة في الاتساع تُضبط حدودها بدل أن تتوسع بصمت. وقبل أن يبدأ التطوير تعتمد أنت مواصفات مكتوبة تحدد بالضبط ما الذي سيُبنى، وهي آخر لحظة رخيصة تنظر فيها إلى المطلب وتقول «هذا إعداد وليس ميزة». وقبل أن يصل أي شيء إلى النظام المباشر، يظهر التغيير في بيئة تجريبية تفتحها وتجربها بنفسك.
لا شيء من هذا بديل عن التفكير، لكنه بنية تجعل التفكير يحدث في النقطة التي ما زال تغيير رأيك فيها مجانياً.
ترتيب عملي للخطوات
- اكتب النتيجة لا الحل. «المالية تحتاج إلى رؤية الالتزامات المرصودة لكل مشروع» أفضل من «أضف حقلاً إلى نموذج أمر الشراء».
- ابحث في Odoo القياسي أولاً، بما في ذلك الوحدات التي لم تثبّتها بعد.
- إذا أوصلك الإعداد إلى معظم الطريق، فقرّر هل يستحق الباقي كوداً والتزاماً في الترقيات.
- وإذا استحق، فاكتب المواصفات واعتمدها بوعي وراجعها في بيئة تجريبية قبل أن تنتقل إلى الإنتاج.
الفرق التي تحصل على أكبر عائد من Odoo ليست الأقل تخصيصاً، بل تلك القادرة على أن تشرح، لكل تخصيص تملكه، لماذا لم يكن النظام القياسي كافياً بالضبط.