الخلاصة
السرد الفعال في Salesforce يصف بوضوح من هو المستخدم، وماذا يسعى لتحقيقه، وما هو الوضع الصحيح بعد الإجراء – لا يحدد أي حقل يظهر في أية شاشة. الاختبار البسيط: إذا أمكن كتابة معايير القبول دون معرفة ما إذا كان التنفيذ سيكون عبر Flow أو Validation Rule أو Apex، فإن السرد قد صيغ بشكل صحيح.
الفشل الشائع هو السرد الذي يتضمن الحل بالفعل. بمجرد كتابة "أضف حقل Picklist إلى شاشة الفرصة"، يُغلق النقاش حول العملية قبل أن يبدأ.
هيكل فعال
| المكون | وظيفته | معيار الجودة |
|---|---|---|
| السياق | من هو المستخدم ومتى يكون موجودًا | دور حقيقي، وليس مجرد "مستخدم" |
| القصد | ما الذي يحاول تحقيقه | يُصاغ بلغة العمل |
| معايير القبول | ما الذي يتم اختباره | يمكن تنفيذه كسيناريو ببيانات اختبار |
| حالات الحافة | ما الذي يفشل عن قصد | على الأقل حالة سلبية واحدة |
| خارج النطاق | ما هو غير متضمن صراحة | يمنع الجدل عند القبول |
السطر الأخير يوفر معظم النزاعات. تصريح صريح بأن ما لم يتم تضمينه غير متضمن يساوي أكثر من ثلاث فقرات وصفية.
التفكيك: شريحة عمودية وليس طبقات
الإغراء في مشاريع CRM هو التفكيك بناءً على المكونات التقنية – أولاً نموذج البيانات، ثم الأتمتات، وأخيراً التقارير. النتيجة هي أنه لا يوجد شيء لعرضه حتى النهاية، ولا أحد يعرف ما إذا كانت العملية تعمل.
التفكيك الصحيح هو عمودي: سيناريو كامل واحد، من البداية إلى النهاية، لملف تعريف مستخدم واحد. فرصة واحدة تُفتح، تتقدم، تُغلق، وتظهر في تقرير – تساوي أكثر من عشرة كائنات محددة بدون عملية. لاحقًا، تُضاف ملفات تعريف وسيناريوهات حول نفس الهيكل.
تحديد الأولويات عندما يكون كل شيء عاجلاً
ثلاثة معايير كافية، بهذا الترتيب:
- هل يمنع الإطلاق؟ – بدونه، العملية ليست كاملة. لا يوجد مجال للمساومة.
- كم عدد المستخدمين يوميًا؟ – التكرار يتجاوز شدة الشكوى. بند يؤثر على 80 مندوبًا يوميًا يسبق طلب مدير واحد.
- ما هي تكلفة التأجيل؟ – هل تزيد تكلفة التنفيذ إذا قمنا به بعد الإطلاق؟ تغيير في نموذج البيانات نعم، تغيير في تقرير لا.
ما لا يجتاز هذه المعايير الثلاثة ينتقل إلى Waiting List. هذا الفصل يمنع تراكم المهام الذي يتحول إلى أرشيف للأمنيات. المزيد حول إدارة تغيير النطاق متاح في دليل Scope Creep وضبط التغييرات.
دين المتطلبات: الفشل الصامت
يتكون دين المتطلبات عندما يتم إغلاق قصة دون اتخاذ قرار بشأن ما يحدث في حالة الحافة – يظل "سنتعامل مع ذلك لاحقًا". بعد الإطلاق، تصبح حالات الحافة هذه هي غالبية طلبات الدعم.
الضابط البسيط: لا يُغلق بند دون قرار موثق لكل سؤال مفتوح مسجل فيه، حتى لو كان القرار هو "لا تتم معالجته عن عمد". توثيق التنازل يساوي أكثر من عدم وجود توثيق.
العلاقة مع الاختبارات
معايير القبول المكتوبة بشكل صحيح هي في الواقع سيناريوهات UAT. عندما تُكتب بعد التطوير، يتحول UAT إلى عرض لما تم بناؤه بدلاً من اختبار ما هو مطلوب. التسلسل مفصل في دليل UAT.
الملخص
قائمة المهام المتراكمة (Backlog) عالية الجودة ليست طويلة بل واضحة: كل بند يحدد لمن هو مخصص، وما الذي سيُقاس كنجاح، وما الذي لم يتضمن صراحة. هذه الأسئلة الثلاثة، التي تُطرح قبل البناء لا بعده، تحدد تقريبًا كل جودة القبول في نهاية المشروع.