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