كيفية إنقاذ مشروع Salesforce متعثر؟ منهجية التشخيص والإنقاذ

الإجابة المختصرة

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

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

علامات التعثر: كيف تعرف أن المشروع لم يعد على المسار الصحيح

هناك فرق بين مشروع يتقدم ببطء ومشروع توقف تماماً. تتكرر العلامات التالية في كل عملية إنقاذ تقريباً قمنا بها:

• تحول اجتماعات الحالة إلى اجتماعات تبرير: اجتماع حالة أسبوعي يتحول إلى تقديم مبررات لعدم جاهزية شيء ما حتى الآن، دون تحديد موعد نهائي جديد وموثوق.
• نمو قائمة الأعمال المتراكمة (Backlog) أسرع من معدل الإغلاق: تتم إضافة عناصر جديدة كل أسبوع، لكن عدد العناصر المغلقة يظل ثابتاً أو يتناقص.
• عدم وجود إصدار تم اختباره مع مستخدم حقيقي في الشهر الأخير: عرض توضيحي داخلي فقط من قبل الفريق التقني، دون أي تواصل مع من سيعملون فعلياً على النظام.
• تغيير متكرر للمتطلبات دون توثيق: كل محادثة تولّد "تعديلاً صغيراً آخر" لا يتم إدخاله في وثيقة نطاق عمل (Scope Document) منظمة.
• فقدان الثقة العلني: يبدأ المستخدمون في إنشاء جداول بيانات Excel موازية "للاحتياط"، وهذه علامة على أنهم فقدوا الثقة في أن النظام سيعمل في الوقت المناسب.

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

تشخيص في 10 أيام: ماذا تفحص وبأي ترتيب

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

الأيام 1-2: مقابلات ورسم خرائط مبدئي. محادثات قصيرة مع الراعي (Sponsor)، ومالك العملية، واثنان إلى ثلاثة من المستخدمين النهائيين، ورئيس فريق التطوير. الهدف هو جمع روايات مختلفة عن "ماذا حدث خطأ"، وليس الوصول إلى استنتاج بعد.

الأيام 3-5: فحص تقني مباشر. المراجعة الفعلية لمنصة Salesforce (Org): هيكل البيانات، الأتمتة الحالية، الصلاحيات، سجلات الأخطاء، والاستعلامات البطيئة. هنا يتم التحقق مما إذا كانت المشكلة معمارية أم تشغيلية.

الأيام 6-7: مقارنة ما تم الوعد به بما تم بناؤه. قراءة المستندات الأصلية (SOW, User Stories, Design Docs إن وجدت) مقابل الوضع الفعلي في بيئة الاختبار (Sandbox) أو بيئة الإنتاج (Production).

الأيام 8-10: بلورة النتائج واتخاذ قرار مبدئي. مستند قصير يصنف كل مشكلة تم العثور عليها على أنها مشكلة نطاق عمل (Scope)، أو بنية معمارية (Architecture)، أو ثقة (Trust)، ويقدم توصية أولية: إعادة تعيين (Reset)، أو إعادة هيكلة (Refactor)، أو الاستمرار بوتيرة معدلة.

ثلاث طبقات للمشكلة: النطاق، البنية المعمارية، والثقة

الخطأ الأكثر شيوعاً هو معالجة كل تعثر وكأنه مشكلة واحدة. في الواقع، يكاد يكون دائماً مزيجاً من ثلاث طبقات مختلفة، تتطلب كل منها نهجاً مختلفاً.

تظهر مشكلة النطاق (Scope) في أن لا أحد يعرف حقاً ما الذي يدخل في الإصدار الأول. يحدث هذا عندما يكون التعريف الأصلي عاماً جداً ("إدارة عملية المبيعات بأكملها في Salesforce") ولم يتم تقسيمه إلى سيناريوهات ملموسة. الحل ليس اجتماع تخطيط آخر، بل كتابة قائمة حادة من المهام التي "يجب/ ينبغي/ لاحقاً" (Must/Should/Later)، مع تحديد مسؤول (Owner) لكل بند.

تظهر مشكلة البنية المعمارية (Architecture) في الاختيارات التقنية التي لا تصمد على نطاق واسع: نموذج بيانات لا يدعم حجم السجلات، أتمتة تعمل بترتيب غير صحيح، تكاملات تتعطل بصمت. هنا يتطلب الأمر فحصاً تقنياً معمقاً، وأحياناً تدخل ترقية نظام Salesforce كبنية تحتية موازية للإصلاح.

مشكلة الثقة (Trust) غالباً ما تكون نتيجة المشكلتين الأوليين، لكنها تكتسب حياة خاصة بها: يتوقف المستخدمون عن الإبلاغ عن المشكلات لأن "إصلاحها غير مجدٍ على أي حال"، وتتوقف الإدارة عن تمويل التغييرات لأن "لقد جربنا بالفعل". مشكلة الثقة لا تُحل بالتصريحات، بل بالأدلة الصغيرة والمتكررة فقط.

جدول التشخيص: العرض، السبب الجذري، والخطوة الأولى

إعادة التعيين (Reset) مقابل إعادة الهيكلة (Refactor): كيف تتخذ القرار

هذا هو القرار المركزي والأكثر تكلفة، لذلك يجب أن يعتمد على معايير وليس على الحدس. تساعد ثلاثة اختبارات:

1. مدى الدين التقني مقابل حجم ما يعمل بالفعل. إذا كانت 70% من الوظائف تعمل بشكل معقول وفقط أجزاء معينة تفشل، فهذه إعادة هيكلة (Refactor). إذا كانت المشكلة تكمن في نموذج البيانات الأساسي، فإن إعادة التعيين الجزئي (Partial Reset) تكون دائماً تقريباً هي الأفضل.
2. تكلفة الشرح مقابل تكلفة إعادة البناء. إذا استغرق الفريق الجديد أكثر من أسبوع لفهم سبب بناء شيء بطريقة معينة، فمن المحتمل أن تتجاوز تكلفة الصيانة المستقبلية تكلفة البناء النظيف.
3. حالة ثقة المستخدمين. عندما تكون الثقة منخفضة جداً، فإن إعادة التعيين الموجهة والعلنية (مع الإعلان "نحن نبدأ إصداراً جديداً ومصححاً") تحقق أحياناً تعاوناً أكبر من الإصلاح الصامت الذي لا يلاحظه المستخدمون.

في الواقع، معظم عمليات الإنقاذ الناجحة هي هجينة: إعادة تعيين (Reset) للمكون الأساسي المشكل (مثل نموذج الفرص Opportunity model أو عملية الموافقات)، إلى جانب إعادة هيكلة (Refactor) لبقية النظام. تظهر مقارنة منظمة بين الأساليب في إعادة بناء Salesforce، والتي توضح المعايير لكل سيناريو.

خطة إنقاذ لمدة 90 يوماً

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

استعادة الثقة مع المستخدمين

الثقة لا تعود بسبب عرض تقديمي، بل تعود بسبب نمط ثابت من الوفاء بوعد صغير. بعض المبادئ التي نجحت على أرض الواقع:

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

غالباً ما تستغرق عملية استعادة الثقة وقتاً أطول من الإصلاح التقني نفسه، لذا ينبغي التخطيط لها كمسار موازٍ لخطة 90 يوماً وليس كنتيجة تلقائية لها. يمكن للمنظمات التي ترغب في دعم منظم لهذه العملية، بما في ذلك الدعم الوثيق للفريق والإدارة، الاستفادة من خدمة Salesforce Health Check كإطار عمل كامل.

مثال على سيناريو مؤسسي

أدارت شركة خدمات مالية مشروع Salesforce لمدة تسعة أشهر دون تشغيل مباشر (Go Live). أظهر الفحص أن النطاق (Scope) تضخم ثلاثة أضعاف التخطيط الأصلي، وأن الفريق التقني بنى ثلاث نسخ مختلفة لنفس عملية الموافقات دون توثيق السبب، وأن المستخدمين الرئيسيين (Key Users) انتقلوا بالفعل إلى إدارة التقرير الشهري في جدول بيانات منفصل.

كشفت خطة التشخيص لمدة عشرة أيام أن المشكلة الرئيسية لم تكن تقنية: فقد تلقى الفريق التقني متطلبات متضاربة من مديرين مختلفين دون تنسيق بينهما. كان القرار إعادة هيكلة جزئية (Refactor)، وليس إعادة تعيين كاملة (Full Reset)، لأن معظم التعليمات البرمجية كانت سليمة. ركزت المرحلة الأولى على عملية الموافقات فقط، التي كانت مصدر الإحباط الرئيسي، وفي غضون خمسة أسابيع، تم إطلاق إصدار مستقر وافق عليه المديرون بشكل مشترك. فقط بعد ذلك استمروا في توسيع بقية العمليات.

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

قائمة المراجعة قبل اتخاذ قرار بالإنقاذ

• ☐ تم إجراء تشخيص لمدة 10 أيام يتضمن مقابلات، فحص منصة Salesforce (Org)، ومقارنة بالوثائق الأصلية.
• ☐ تم تصنيف المشكلات بوضوح إلى نطاق (Scope)، أو بنية معمارية (Architecture)، أو ثقة (Trust).
• ☐ تم اتخاذ قرار إعادة تعيين/إعادة هيكلة موثق مع المبررات.
• ☐ تم اختيار عملية واحدة للموجة الأولى بناءً على معاناة حقيقية للمستخدمين.
• ☐ تم تحديد تجميد للتغييرات (Change Freeze) خلال فترة التشخيص والقرار.
• ☐ تم تحديد مقاييس خط الأساس (Baseline) قبل بدء الإصلاح.
• ☐ توجد خطة اتصال مستمرة للمستخدمين والإدارة.
• ☐ تم تعيين مالك (Owner) وحيد يحتفظ بخريطة القرارات بأكملها.
• ☐ تتضمن خطة الـ 90 يوماً مراحل قابلة للقياس وليست مجرد تاريخ انتهاء.
• ☐ تم تحديد عملية لتسليم الحوكمة (Governance) والصيانة عند الانتهاء من عملية الإنقاذ.

مصادر احترافية

• Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
• HPI Pro – Salesforce Health Check — https://hpi.pro/salesforce-health-check
• HPI Pro – الدعم والإرشاد — https://hpi.pro/support