لو كان النظام سليمًا وأردت أن أنتج هذا العَرَض تحديدًا، فما الذي سيتعين أن يتعطل؟
هذا نموذج ذهني لاختبار الفرضيات، وليس دعوة لإحداث عطل في نظام رصد عامل.
التصنيف: منهج ميداني · استكشاف أعطال · طريقة تفكير
هناك نوع من الفشل أحبه.
أن تغيّر قطعة…
ولا تُحل المشكلة.
أن تعيد تشغيل النظام…
ولا يتغير شيء.
أن تختبر فرضية…
وتكتشف أنها كانت خطأ.
لأن استكشاف الأعطال ليس مسابقة لإيجاد الحل من المحاولة الأولى.
هو عملية لتقليل مساحة الاحتمالات.
اختبار الفرضيات
إذا كان لدينا خمس فرضيات، واختبار جيد استبعد واحدة منها، فقد أصبحنا نعرف أكثر مما كنا نعرف قبل الاختبار.
الاختبار الجيد لا يحتاج أن يصلح النظام.
يحتاج أن يغير معرفتنا عنه.
مثلًا:
إذا استبدلت الحساس واستمرت المشكلة، فهذا لا يحل العطل.
لكنه يجعل فرضية “الحساس هو السبب” أضعف.
وهذا تقدم.
تغيير واحد يمكن تفسيره
إذا بدأنا بتغيير كل شيء في الوقت نفسه:
- حساس؛
- كابل؛
- مودم؛
- إعدادات؛
- Firmware؛
ثم عمل النظام…
فقد أصلحناه.
لكننا ربما لم نتعلم شيئًا.
وأصبح من الصعب معرفة ما الذي كان السبب أصلًا.
غيّر شيئًا يمكن أن يختبر فرضية. ثم راقب ما الذي تغير.
هذه الطريقة أبطأ أحيانًا في أول خمس دقائق.
لكنها أسرع بكثير عندما تصبح المشكلة معقدة.
لأن نفس المنطق يمتد إلى تفسير البيانات.
الفرضية البيئية أيضًا يجب أن تكون قابلة للاختبار.
وإذا ظهرت أدلة لا تدعمها، يجب أن نسمح لها بأن تضعف.
الفشل المفيد ليس:
“لم أجد الحل.”
بل:
“هذا الاحتمال لم يعد يفسر الأدلة كما كنت أظن.”
وهذه معرفة جديدة.