لماذا تتكرر المشكلة بعد إصلاحها؟ كيف تفرق بين علاج العَرَض وحل السبب الحقيقي؟

هناك نوع من الأعطال يجعلك تشعر أنك تدور في دائرة مغلقة.

الهاتف يتوقف عن الشحن، تنظف منفذ الشحن، فيعود للعمل… ثم تتكرر المشكلة بعد أسبوع.

الحاسوب يصبح بطيئًا، تحذف الملفات المؤقتة، فيتحسن… ثم يعود البطء.

الإنترنت يتقطع، تعيد تشغيل الراوتر، فيعمل بشكل ممتاز… وبعد ساعات تبدأ المشكلة من جديد.

التطبيق ينهار، تحذفه وتعيد تثبيته، فيعمل… ثم يعود إلى الانهيار.

وفي كل مرة تقول لنفسك: "لقد أصلحت المشكلة."

لماذا تتكرر المشكلة بعد إصلاحها؟ كيف تفرق بين علاج العَرَض وحل السبب الحقيقي؟

لكن إذا عادت المشكلة بعد فترة، فهناك سؤال يجب أن تطرحه:

هل أصلحت المشكلة فعلًا، أم أنك فقط أوقفت العَرَض مؤقتًا؟

هذا الفرق هو جوهر التشخيص التقني الجيد. فـTroubleshooting قد ينجح في إعادة الجهاز إلى العمل، بينما Root Cause Analysis يبحث عن السبب الأساسي الذي جعل المشكلة تحدث من الأصل، بهدف منع تكرارها.

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

المشكلة ليست دائمًا هي الشيء الذي تراه أمامك

لنبدأ بمثال بسيط.

تخيل أن حاسوبك يتجمد.

التجمّد هو ما تراه.

لكن هل التجمّد هو المشكلة الحقيقية؟

قد يكون نتيجة:

ارتفاع حرارة المعالج.

مشكلة في الذاكرة.

خلل في وحدة التخزين.

تعريف غير مستقر.

برنامج يستهلك الموارد بشكل غير طبيعي.

مشكلة في الطاقة.

أو حتى خلل في النظام.

إذن عبارة:

"الحاسوب يتجمد"

تصف العَرَض، لكنها لا تخبرك بالضرورة عن السبب.

وهذه أول قاعدة:

العَرَض هو ما يحدث، أما السبب فهو لماذا يحدث.

إذا أوقفت التجمّد بإعادة تشغيل الجهاز، فقد عالجت النتيجة، وليس بالضرورة المصدر.

لماذا ينجح الحل المؤقت ثم تفشل المشكلة في العودة؟

لأنك قد تكون أزلت الظروف التي جعلت المشكلة تظهر للحظات فقط.

إعادة التشغيل، مثلًا، تغلق العمليات والخدمات الحالية وتعيد النظام إلى حالة تشغيل جديدة.

هذا قد يزيل العملية التي كانت تسبب البطء.

لكن إذا كانت العملية ستعمل مجددًا بعد ساعة، فالمشكلة ستعود.

وبالمثل، حذف الملفات المؤقتة قد يحرر مساحة ويجعل الجهاز أسرع.

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

وتنظيف منفذ الشحن قد يعيد الاتصال.

لكن إذا كان الكابل تالفًا أو المنفذ يعاني من مشكلة ميكانيكية، فسوف تعود الأعراض.

إذن:

اختفاء العَرَض لا يساوي اختفاء السبب.

كيف تعرف أنك عالجت العَرَض فقط؟

هناك علامات واضحة جدًا.

أهمها أن المشكلة تعود بنفس الشكل أو بشكل قريب من الشكل السابق.

إذا احتجت إلى تنفيذ الحل نفسه عدة مرات، فتوقف واسأل نفسك:

لماذا أحتاج إلى إصلاح الشيء نفسه كل مرة؟

إذا كنت تعيد تشغيل الراوتر يوميًا، فأنت لا تملك حلًا نهائيًا.

إذا كنت تمسح ذاكرة التخزين المؤقت كل يومين، فأنت لا تملك حلًا نهائيًا.

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

إذا كنت تشحن الهاتف بطريقة معينة حتى لا ينطفئ، فأنت تتعامل مع العَرَض.

التكرار نفسه أصبح دليلًا تشخيصيًا.

المشكلة التي تعود بعد الإصلاح تستحق أن تبحث عن سبب أعمق بدل تكرار نفس الإجراء.

العَرَض والسبب والسبب المساهم ليست الشيء نفسه

هنا تبدأ الصورة في التعقيد قليلًا.

لنفترض أن هاتفك يسخن.

قد تكون:

الحرارة هي العَرَض.

لكن ما الذي يسببها؟

قد يكون تطبيقًا يستهلك المعالج.

لكن لماذا يستهلك التطبيق المعالج؟

ربما لأنه يحاول تنفيذ عملية باستمرار.

ولماذا تتكرر العملية؟

ربما بسبب فشل في المزامنة.

ولماذا تفشل المزامنة؟

ربما بسبب إعداد أو مشكلة اتصال أو خلل في التطبيق.

لاحظ كيف انتقلنا من:

هاتف ساخن

إلى سلسلة كاملة من الأسباب المحتملة.

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

مثال: البطارية تفرغ بسرعة

لنفترض أن بطارية هاتفك تنخفض بسرعة.

يمكنك تغيير البطارية.

وقد يتحسن الهاتف.

لكن ماذا لو كان هناك تطبيق يعمل في الخلفية باستمرار؟

أو أن الهاتف يعاني من ضعف تغطية في مكان معين، فيستهلك طاقة أكبر للحفاظ على الاتصال؟

أو أن الحرارة مرتفعة؟

أو أن الشاشة تعمل بإعدادات استهلاك مرتفعة؟

في هذه الحالة، قد تكون البطارية القديمة بالفعل متضررة، لكن سبب تدهورها السريع قد يظل موجودًا.

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

هنا يجب أن تفرق بين:

المكوّن المتضرر

و

السبب الذي أدى إلى تضرره.

وهذا فرق بالغ الأهمية في الصيانة.

إذا استبدلت القطعة ولم يتغير النمط، توقف

هذه قاعدة مفيدة جدًا.

إذا استبدلت مكوّنًا لأنك اعتقدت أنه السبب، ثم ظهرت المشكلة نفسها، فلا تفترض مباشرة أن القطعة الجديدة تالفة أيضًا.

ربما كان التشخيص الأصلي خاطئًا.

مثلًا:

الحاسوب يتوقف فجأة.

تستبدل وحدة التخزين.

ثم يتوقف مجددًا.

هنا لا تقل فورًا:

"وحدة التخزين الجديدة سيئة."

ربما المشكلة في الطاقة.

أو الحرارة.

أو الذاكرة.

أو تعريف معين.

أو اللوحة الأم.

فشل الإصلاح نفسه معلومة جديدة.

لا تتجاهلها.

اسأل: ما الذي أزاله الإصلاح؟

كل إصلاح يجب أن يكون له تفسير.

إذا أعدت تشغيل الجهاز، ما الذي تغير؟

إذا حذفت تطبيقًا، ما الذي تغير؟

إذا استبدلت الكابل، ما الذي تغير؟

إذا حدثت النظام، ما الذي تغير؟

إذا نظفت مساحة التخزين، ما الذي تغير؟

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

أما عندما تعرف ما الذي تغير، فيمكنك استخدام الإصلاح كاختبار.

وهنا يتحول الإصلاح من "محاولة" إلى تجربة تشخيصية.

استخدم اختبار الإزالة بدل التخمين

واحدة من أقوى الطرق هي إزالة متغير واحد ثم مراقبة النتيجة.

لنفترض أن جهازك يتوقف.

لديك ثلاثة احتمالات:

حرارة.

تطبيق.

ملحق خارجي.

لا تغير الثلاثة في وقت واحد.

افصل الملحق.

اختبر.

إذا استمرت المشكلة، أعده وانتقل إلى المتغير التالي.

ثم اختبر الحرارة.

ثم التطبيق.

بهذه الطريقة تعرف أي تغيير أثّر فعلًا.

أما إذا فصلت الملحق، وحذفت التطبيق، وأعدت ضبط الإعدادات، وحدّثت النظام، ثم قلت:

"المشكلة اختفت."

فلن تعرف أي خطوة كانت السبب.

لماذا يجب أن تسجل التوقيت؟

لأن التوقيت يكشف العلاقات التي لا تراها العين مباشرة.

لنفترض أن الحاسوب يعمل بشكل ممتاز لمدة 30 دقيقة.

بعدها يبدأ البطء.

ثم ترتفع الحرارة.

ثم يتوقف برنامج معين.

هنا لديك سلسلة زمنية.

ربما المشكلة ليست في البرنامج نفسه.

قد يكون البرنامج هو أول شيء لاحظته فقط بعد أن أصبحت حرارة النظام مرتفعة.

وبالمثل، إذا كان الراوتر يعمل جيدًا ثم يتوقف الاتصال بعد عدد معين من الساعات، فلا تتعامل مع كل انقطاع كحادث مستقل.

سجل:

متى بدأ؟

ما الأجهزة المتصلة؟

ما حجم الاستخدام؟

هل الحرارة مرتفعة؟

هل المشكلة في Wi-Fi فقط أم في الاتصال الخارجي أيضًا؟

هذه البيانات تساعدك على الانتقال من الانطباع إلى النمط.

اسأل السؤال الشهير: لماذا؟

من أبسط أدوات تحليل السبب الجذري أسلوب "لماذا؟" المتكرر.

وليس المقصود أن تسأل "لماذا؟" خمس مرات حرفيًا في كل مشكلة، بل أن تستمر في النزول من النتيجة إلى السبب حتى تصل إلى تفسير يمكن اختباره.

مثلًا:

لماذا الجهاز بطيء؟

لأن المعالج يعمل بسرعة منخفضة.

لماذا يعمل بسرعة منخفضة؟

لأن الجهاز ساخن.

لماذا الجهاز ساخن؟

لأن هناك حملًا مرتفعًا مستمرًا.

لماذا يوجد حمل مرتفع؟

لأن عملية معينة تعمل باستمرار.

لماذا تعمل العملية باستمرار؟

لأن خدمة معينة تدخل في حلقة فشل وإعادة محاولة.

هنا أصبحت أقرب بكثير إلى السبب الحقيقي.

لكن انتبه:

لا تقبل كل إجابة باعتبارها حقيقة.

كل "لماذا" يجب أن تتحول إلى فرضية تحتاج دليلًا. وهذا مهم لأن السبب الذي يبدو منطقيًا قد يكون خاطئًا إذا لم تدعمه البيانات أو الاختبارات.

لا تجعل "التحديث" شماعة لكل مشكلة

من أكثر الحلول الشائعة:

"حدّث النظام."

أحيانًا يكون التحديث فعلًا هو الحل.

لكن إذا تحسن الجهاز بعد التحديث، لا يعني ذلك بالضرورة أن التحديث "أصلح كل شيء".

قد يكون التحديث قد:

أصلح خطأ معروفًا.

غير تعريفًا.

مسح حالة مؤقتة.

أعاد تشغيل خدمات.

غيّر سلوك تطبيق.

أو حتى غيّر طريقة إدارة الموارد.

إذا عادت المشكلة بعد فترة، فلا تعد التحديث بلا تفكير.

اسأل:

ما الذي تغير بعد التحديث؟

مثال: الراوتر الذي يحتاج إعادة تشغيل يوميًا

هذا مثال ممتاز على علاج العَرَض.

الراوتر يتوقف.

تضغط إعادة التشغيل.

يعود الإنترنت.

تكرر العملية في اليوم التالي.

بعد أسبوع تقول:

"الراوتر يحتاج إعادة تشغيل يومية."

لكن هذا ليس طبيعيًا كحل نهائي.

ابدأ بتحديد مكان المشكلة.

هل الإنترنت ينقطع عن جميع الأجهزة؟

هل Wi-Fi فقط هو الذي يتوقف؟

هل الاتصال السلكي يستمر؟

هل يمكن الوصول إلى صفحة إدارة الراوتر؟

هل يعود الاتصال فور إعادة تشغيل الراوتر؟

هل المشكلة تحدث في أوقات الاستخدام المرتفع؟

هل ترتفع حرارة الجهاز؟

هل هناك تحديث للبرامج الثابتة؟

هل المشكلة مرتبطة بمصدر الطاقة؟

الهدف هو معرفة لماذا يحتاج الراوتر إلى إعادة التشغيل، وليس فقط معرفة أن إعادة التشغيل تنجح.

مثال: الهاتف الذي يمتلئ تخزينه باستمرار

تقوم بحذف 10 جيجابايت.

تتنفس الصعداء.

بعد أسبوعين، تمتلئ المساحة من جديد.

إذن الحذف نجح، لكنه لم يحل المشكلة.

الحذف كان علاجًا للعرض:

"لا توجد مساحة كافية."

أما السؤال الحقيقي فهو:

"من الذي يعيد استهلاك المساحة؟"

افحص التطبيقات التي تنشئ البيانات.

راجع التنزيلات.

راجع الفيديوهات.

راجع التطبيقات التي تخزن ملفات مؤقتة ضخمة.

راجع سلة المحذوفات.

راقب مساحة التخزين بعد عدة أيام.

إذا وجدت تطبيقًا يزيد حجمه باستمرار، أصبحت لديك فرضية قابلة للاختبار.

مثال: تطبيق يتوقف باستمرار

إعادة تثبيت التطبيق قد تجعله يعمل.

لكن إذا عاد العطل، لا تعيد تثبيته مرة ثالثة بشكل آلي.

اسأل:

هل يحدث الانهيار عند وظيفة محددة؟

هل يحدث بعد تسجيل الدخول؟

هل يحدث عند فتح ملف معين؟

هل يحدث مع حساب واحد فقط؟

هل يحدث على جهاز آخر؟

هل يحدث مع نسخة مختلفة من التطبيق؟

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

إذا كان ينهار على جهازك فقط، فابحث في بيئة الجهاز.

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

وهكذا يتحول "التطبيق ينهار" من عَرَض غامض إلى مشكلة يمكن تفكيكها.

الفرق بين الحل المؤقت والحل الدائم يظهر في الاختبار بعد الإصلاح

هذه نقطة يغفل عنها كثيرون.

بعد تنفيذ الإصلاح، لا تقل:

"اشتغل، انتهينا."

بل قل:

"الآن يجب أن أثبت أن المشكلة لن تعود في الظروف نفسها."

إذا كانت المشكلة تحدث أثناء تشغيل لعبة ثقيلة، اختبر اللعبة مرة أخرى.

إذا كانت تحدث أثناء الشحن، اختبر الشحن.

إذا كانت تحدث عند استخدام شبكة معينة، أعد السيناريو.

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

يجب أن يكون الاختبار قريبًا من الظروف التي سببت المشكلة.

أنشئ خط أساس قبل الإصلاح

إذا أردت معرفة ما إذا كان الإصلاح حقيقيًا، يجب أن تعرف كيف كان الجهاز قبل المشكلة.

سجل:

درجة الحرارة التقريبية.

استهلاك البطارية.

مدة تشغيل التطبيقات.

سرعة الإقلاع.

عدد مرات التوقف.

سلوك الشبكة.

المساحة المتاحة.

أي رسائل خطأ.

لا تحتاج إلى قياس كل شيء بشكل احترافي.

حتى ملاحظة بسيطة مثل:

"يتجمد بعد 20 دقيقة من تشغيل اللعبة"

أفضل بكثير من:

"كان يعلق."

بعد الإصلاح، إذا أصبح يعمل ساعتين دون التجمّد في الظروف نفسها، لديك دليل أقوى على نجاح الحل.

راقب ما إذا كانت المشكلة انتقلت بدل أن تختفي

أحيانًا يبدو أنك أصلحت المشكلة، لكنها انتقلت إلى مكان آخر.

مثلًا، كان التطبيق يتجمد.

بعد تغيير إعداد معين لم يعد يتجمد، لكن أصبح استهلاك البطارية مرتفعًا جدًا.

هنا لا تقل:

"تم الحل."

ربما غيرت السلوك بدل إزالة السبب.

في الأنظمة المعقدة، قد يؤدي حل سريع إلى خلق أثر جانبي.

لذلك اسأل:

هل اختفى العَرَض دون أن يظهر أثر جديد؟

لا تخلط بين السبب المباشر والسبب الجذري

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

مثلًا:

الحاسوب توقف لأن المعالج ارتفعت حرارته.

هذا تفسير مباشر.

لكن لماذا ارتفعت الحرارة؟

قد يكون نظام التبريد متعطلًا.

ولماذا تعطل؟

قد يكون هناك مروحة لا تعمل.

وهكذا.

لذلك هناك فرق بين:

ما أشعل المشكلة الآن

و

ما سمح للمشكلة أن تحدث أصلًا.

وهذا التفريق مهم خصوصًا عندما تتكرر الأعطال.

متى يكون تغيير القطعة هو الحل الحقيقي؟

ليس كل شيء برمجيًا.

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

إذا كانت وحدة التخزين تتدهور، فاستبدالها قد يكون ضروريًا.

إذا كان الكابل تالفًا، تغييره منطقي.

إذا كان الشاحن غير مناسب أو معيبًا، تغييره هو الحل.

لكن حتى هنا اسأل:

هل القطعة هي السبب أم أنها أصبحت ضحية لسبب آخر؟

إذا استبدلت بطارية تالفة، فهذا حل.

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

كيف تعرف أن السبب الذي وجدته هو السبب الحقيقي؟

هناك اختبار عملي قوي جدًا:

إذا أزلت السبب، هل تختفي المشكلة وتبقى مختفية عند إعادة الظروف السابقة؟

لنفترض أنك تعتقد أن تطبيقًا معينًا هو السبب.

أزل التطبيق.

اختبر الجهاز.

إذا اختفت المشكلة، هذا دليل.

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

إذا عادت بوضوح، أصبحت العلاقة أقوى.

هذه الفكرة تسمى عمليًا اختبار الفرضية من خلال تغيير السبب ومراقبة النتيجة.

والقاعدة المهمة هنا:

الارتباط بين شيئين لا يثبت وحده أن أحدهما سبب الآخر.

لا تتوقف عند أول سبب يبدو مقنعًا

قد تجد أن الجهاز يسخن.

وتقول:

"إذن الحرارة هي السبب."

لكن الحرارة قد تكون نتيجة وليست سببًا.

وقد تجد أن التطبيق يستهلك المعالج.

لكن ربما هو يفعل ذلك لأنه ينتظر خدمة أخرى وتدخل في حلقة إعادة محاولة.

وقد تجد أن التخزين ممتلئ.

لكن ربما هناك تطبيق يعيد تنزيل الملفات باستمرار.

التشخيص الجيد لا يبحث عن أول إجابة.

بل يبحث عن الإجابة التي تفسر أكبر عدد من الأدلة.

اجمع الأعراض التي تظهر معًا

إذا كان لديك:

بطء + حرارة + استنزاف بطارية + توقف تطبيقات،

فلا تبدأ بأربع عمليات إصلاح.

ابحث عن الرابط المشترك.

ربما عملية واحدة تستهلك المعالج.

إذا كان لديك:

تأخر إقلاع + أخطاء ملفات + بطء قراءة + تجمد أثناء نقل البيانات،

فكر في التخزين.

إذا كان لديك:

انقطاع اتصال + مشاكل Wi-Fi + استمرار الاتصال السلكي،

فركز على طبقة الاتصال اللاسلكي بدل الجهاز كله.

عندما تتجمع عدة أعراض حول سبب واحد، تصبح فرصة الوصول إلى السبب الجذري أعلى.

متى تستخدم أدوات مثل Fishbone أو Fault Tree؟

إذا كانت المشكلة بسيطة، قد لا تحتاج إلى أدوات رسمية.

لكن عندما يصبح الجهاز أو النظام معقدًا، يمكنك بناء خريطة للأسباب المحتملة.

يمكن تقسيم الاحتمالات مثلًا إلى:

الطاقة.

الحرارة.

البرمجيات.

الشبكة.

التخزين.

الذاكرة.

الملحقات.

الإعدادات.

المستخدم أو طريقة الاستخدام.

ثم تبدأ باستبعاد الفروع التي لا تتفق مع الأدلة.

هذه الفكرة قريبة من أساليب تحليل السبب الجذري مثل Fishbone وFault Tree وFive Whys، وهي أدوات مختلفة تساعد على تنظيم البحث بدل الاعتماد على التخمين.

استخدم قاعدة: ماذا سيحدث إذا لم أفعل شيئًا؟

هذا سؤال ذكي جدًا.

إذا حذفت الملفات المؤقتة، هل ستعود؟

إذا أعدت تشغيل الراوتر، هل سينقطع غدًا؟

إذا أعدت تثبيت التطبيق، هل سيعود الانهيار؟

إذا استبدلت البطارية، هل سيستمر الجهاز في السخونة؟

إذا كانت الإجابة نعم، فأنت تعرف أن الحل الحالي ليس كافيًا.

اسأل بعدها:

ما الذي يجب أن يتغير حتى لا أضطر إلى تنفيذ هذا الإصلاح مرة أخرى؟

ضع معيارًا واضحًا لنجاح الإصلاح

لا تجعل "الجهاز يعمل الآن" معيار النجاح الوحيد.

ضع معيارًا قابلًا للملاحظة.

مثلًا:

"لن يتوقف الجهاز خلال ساعتين من الاستخدام نفسه."

أو:

"لن تمتلئ المساحة بمعدل غير طبيعي خلال أسبوع."

أو:

"لن ينقطع الاتصال عند استخدام الشبكة في الظروف نفسها."

أو:

"لن يعود التطبيق إلى الانهيار بعد تنفيذ العملية نفسها."

هذا يحول الصيانة من شعور إلى قياس.

إذا عادت المشكلة، لا تبدأ من الصفر

عندما تتكرر المشكلة، لديك ميزة مهمة:

لديك تاريخ سابق.

أنت تعرف ماذا جربت.

وتعرف ما الذي لم ينجح.

وتعرف كم استمر التحسن.

وتعرف ما الذي تغير قبل عودة المشكلة.

لا تهدر هذه المعلومات.

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

ماذا حدث خلال هذه الأيام؟

هل ثبت تطبيق؟

هل حدث النظام؟

هل زاد الحمل؟

هل تغيرت الشبكة؟

هل امتلأت المساحة؟

هل ارتفعت الحرارة؟

ابحث عن المتغير الجديد الذي ظهر قبل عودة المشكلة.

الفرق الحقيقي بين الفني الذي يطفئ المشكلة والفني الذي يحلها

يمكنك رؤية الفرق بسهولة.

الفني الذي يطارد الأعراض يقول:

"جرّب إعادة التشغيل."

ثم:

"غيّر الإعداد."

ثم:

"أعد تثبيت البرنامج."

ثم:

"بدّل القطعة."

أما منهج التشخيص الحقيقي فيسأل:

متى بدأت؟

ما الذي تغير؟

ما الذي يتكرر؟

ما الأعراض المصاحبة؟

ما الذي يمكن استبعاده؟

ما الفرضية الأقوى؟

كيف أختبرها؟

وماذا أتوقع أن يحدث إذا كانت صحيحة؟

هذا التفكير هو الذي يحول عملية الإصلاح من سلسلة تجارب عشوائية إلى تحقيق تقني منظم.

اختبار سريع: هل أنت تعالج العَرَض أم السبب؟

قبل أن تعتبر المشكلة محلولة، اسأل نفسك:

هل أستطيع شرح لماذا حدثت المشكلة؟

إذا كانت الإجابة لا، فأنت ربما لم تصل إلى السبب.

هل المشكلة اختفت لأنني أزلت سببها أم لأنني أعدت تشغيل الجهاز فقط؟

إذا كان الثاني، فاستمر في البحث.

هل اختبرت الجهاز في الظروف التي كانت تسبب المشكلة؟

إذا لم تفعل، لم تختبر الإصلاح بالكامل.

هل ظهرت المشكلة نفسها من جديد؟

إذا نعم، فالتحقيق لم ينته.

هل استبدلت قطعة دون إثبات أنها سبب المشكلة؟

إذا نعم، فقد تحتاج إلى مراجعة التشخيص.

هل يوجد متغير مشترك يفسر أكثر من عرض؟

إذا نعم، ابدأ منه.

هل لديك دليل أم مجرد احتمال؟

إذا كان مجرد احتمال، لا تبنِ عليه إصلاحًا مكلفًا قبل اختباره.

الخلاصة: الإصلاح الحقيقي هو الذي يمنعك من تنفيذ الإصلاح نفسه مرة أخرى

عندما تتكرر المشكلة بعد إصلاحها، لا تعتبر ذلك مجرد سوء حظ.

في كثير من الحالات، عودة العطل هي رسالة واضحة تقول لك:

"لقد عالجت ما تراه، لكنك لم تصل بعد إلى ما يسببه."

إعادة التشغيل قد توقف العَرَض.

حذف الملفات قد يوفر مساحة.

إعادة تثبيت التطبيق قد تعيد تشغيله.

استبدال البطارية قد يحسن الأداء.

تغيير الكابل قد يعيد الشحن.

لكن السؤال الأهم دائمًا هو:

لماذا حدثت المشكلة أصلًا؟

ابدأ بتحديد العَرَض بدقة، ثم سجل التوقيت والظروف، واجمع الأعراض المرتبطة، وابحث عن التغييرات التي سبقت المشكلة، ثم ضع فرضيات واختبرها واحدة تلو الأخرى.

لا تعتبر أول تفسير صحيحًا لمجرد أنه يبدو منطقيًا.

ولا تعتبر الإصلاح ناجحًا لمجرد أن الجهاز عاد للعمل لدقائق.

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

وهنا يصبح لديك معيار بسيط جدًا:

إذا كنت تحتاج إلى تنفيذ الحل نفسه مرة بعد مرة، فغالبًا أنت لم تصل إلى السبب بعد.

أما عندما تجد السبب وتزيله، فلا تحتاج إلى مطاردة العَرَض كل أسبوع.

الجهاز يعمل، والمشكلة لا تعود، وأنت تعرف لماذا.

وهذه هي اللحظة التي يمكنك فيها القول فعلًا:

تم إصلاح العطل.