الدين التقني في سيلزفورس: كيف تكتشفه وكيف تسدده

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

ما هو الدين التقني في سيلزفورس؟

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

ويأتي في أربعة أشكال:

• دين الأتمتة. Workflow Rules وProcess Builder وFlows تؤدي أعمالا متداخلة، بترتيب تنفيذ لا يستطيع أحد رسمه على السبورة.
• دين الإعداد. حقول لم يملأها أحد منذ سنتين، وتخطيطات صفحات لأدوار لم تعد موجودة، وprofiles تحمل صلاحيات مكانها الصحيح permission sets.
• دين الكود. أكثر من trigger واحد لكل كائن، واختبارات كُتبت لبلوغ رقم التغطية لا للتحقق من السلوك، ومعرّفات مكتوبة يدويا داخل الكود.
• دين التكامل. أنظمة تنادي إصدارات API لم تعد المنصة تخدمها، وطبقات وسيطة غادر مسؤولها الشركة.

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

أين يختبئ الدين الآن؟

بندان لهما تواريخ محددة يستحقان الفحص هذا الأسبوع، لأن المنصة تحركت ومعظم المؤسسات لم تتحرك.

• Workflow Rules وProcess Builder تجاوزا نهاية الدعم. سيلزفورس حددت التاريخ في 31 ديسمبر 2025. ما زال يعمل ما بُني عليهما، لكن أخطاءه لن تُصلَح، ولا يمكنك إنشاء جديد. وأداة Migrate to Flow موجودة لهذا الغرض بالضبط.
• إصدارات الـ API القديمة اختفت. إصدارات Platform API من 21.0 حتى 30.0 في SOAP وREST وBulk أُعلن تقادمها في Summer '22 ثم أُوقفت مع Summer '25. المنادي يستقبل الآن 410 GONE في REST و500 UNSUPPORTED_API_VERSION في SOAP و400 InvalidVersion في Bulk. لو صمتت مهمة ليلية قديمة، ابدأ الفحص من هنا.

كيف تجرد الدين بدون أن توقف التسليم؟

1. شغّل Salesforce Optimizer وصدّر نتيجته. مجاني، وموجود في Setup، ويعطيك قائمة بداية بدلا من رأي شخصي.
2. اسحب metadata المؤسسة إلى نظام التحكم بالمصدر. حتى لو لم تنشر منه أبدا، صار عندك شيء يمكن البحث فيه ومقارنته وعدّه.
3. اربط الجرد بالاستخدام. تاريخ الحقول، والاشتراكات في التقارير ولوحات المعلومات، ومشاهدات الصفحات، وسجلات Apex. الحقل بلا قراءة ولا كتابة طوال اثني عشر شهرا مرشح للحذف. ونفس الحقل على كائن يحمل 400 حقل آخر يصبح أولوية.
4. ارسم الاعتماديات قبل حذف أي شيء. سؤال أين يُستخدم هذا هو كل الفرق بين تنظيف وانقطاع خدمة.
5. عيّن مسؤولا لكل مجال. الدين بلا مسؤول لا يُسدَّد أبدا.

لمؤسسة متوسطة الحجم هذه مهمة أسبوعين تسير بالتوازي مع سبرنت عادي. وما تنتجه سجل، لا خطة مشروع.

كيف ترتب ما وجدته؟

هنا تحديدا تنحرف معظم برامج معالجة الدين التقني. الترتيب حسب الخطورة يعطيك قائمة مرتبة بحسب مدى سوء المنظر. والترتيب حسب الجهد يعطيك قائمة مرتبة بحسب السهولة. ولا واحدة منهما قائمة ستمولها إدارتك مرتين.

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

• معطّل. بند خارطة الطريق لا يمكن أن يُسلَّم قبل سداد الدين. نفّذ العمل داخل ذلك المشروع وبتمويله وبمبرره التجاري.
• مُثقِل. البند سيُسلَّم على أي حال، لكن بتكلفة أعلى أو بمخاطرة لا داعي لها. نفّذه في السبرنت السابق له وبنطاق ضيق.
• خامل. لا شيء في خارطة الطريق يمسه. سجّله وراقبه ولا تموّله.

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

لماذا يفشل التنظيف الشامل؟

ثلاثة أسباب، وقد رأيناها كلها.

1. لا نتيجة مرئية. التنظيف على مستوى المؤسسة كلها لا ينتج ميزة ولا رقما يشير إليه الراعي، فيخسر ميزانيته عند أول إعادة ترتيب للأولويات.
2. ضرر في نسب السبب. تحذف metadata لم يكن أحد يراقبها، فيقع عطل، ويُنسب العطل إلى مشروع التنظيف، ولا يُعتمَد مشروع مماثل بعده أبدا.
3. لا يصل إلى نهاية. المؤسسة التي سلّمت طوال العام يكون عندها دين جديد قبل أن تنتهي حملة التنظيف. أما السداد المربوط ببنود خارطة الطريق فينتهي بطبيعته، لأنه يتوقف عند تسليم البند.

الهدف ليس مؤسسة نظيفة. الهدف مؤسسة يمكن أن تُسلَّم فيها خارطة طريق الاثني عشر شهرا القادمة بتكلفة يمكن التنبؤ بها.

ما الإيقاع الذي ينجح فعلا؟

• كل سبرنت. نسبة ثابتة من الطاقة، غالبا من 10 إلى 20%، تُصرف على الدين المُثقِل في المناطق التي تلمسها القصص التالية.
• كل إصدار من سيلزفورس. ثلاث مرات في السنة: أعد تشغيل Optimizer، وأعد قراءة إشعارات إيقاف الخدمات، وأعد فحص إصدارات الـ API التي تطلبها تكاملاتك.
• كل سنة. جدّد الجرد وأعد ترتيبه في مواجهة خارطة الطريق الجديدة. البنود تنتقل بين الدرجات كلما تغيرت الخطط، والدين الخامل قد يصير معطّلا بين ليلة وضحاها.

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

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

FAQ

كيف أعرف أن مؤسستي تحمل دينا تقنيا زائدا؟

قِسه بالتسليم لا بالأعداد. لو صارت التغييرات الروتينية تتطلب اختبارات انحدار في مناطق لا علاقة لها بالموضوع، أو لم يعد أحد يتوقع ما الذي سيكسره التغيير، فالدين مكلف بالفعل.

هل نحذف الحقول غير المستخدمة؟

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

هل يكفي Salesforce Optimizer؟

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

هل يجب أن ننتقل عن Workflow Rules وProcess Builder الآن؟

ما زالا يعملان، لكن الدعم انتهى في 31 ديسمبر 2025، فأي خلل فيهما سيبقى بلا إصلاح. رحّل أولا الأتمتة التي تلمسها خارطة طريقك، لا كل شيء دفعة واحدة.