هناك شعور مريح يأتي بعد حل مشكلة مزعجة.
الخدمة عادت.
الخطأ اختفى.
المهمة اكتملت.
يمكن إغلاق التذكرة والانتقال إلى شيء آخر.
لكن في هذه اللحظة تحديدًا قد نكون على وشك خسارة أهم جزء من المشكلة.
لأن إصلاح العطل يعيدنا إلى النقطة التي كنا عندها قبل وقوعه.
أما فهمه وتحويل ما تعلمناه إلى تغيير دائم، فهو ما يجعل النظام أفضل مما كان قبل العطل.
وهنا يوجد فرق كبير بين نظام يحل المشكلات، ونظام يتعلم منها.
ليس كل إصلاح تحسينًا
تخيل أن مشكلة ظهرت بسبب خطوة يدوية نسي أحدهم تنفيذها.
الحل السريع بسيط:
نفذ الخطوة الآن.
انتهت المشكلة.
لكن ماذا عن المرة القادمة؟
إذا بقيت العملية كما هي، فنحن لم نحل السبب الذي سمح للمشكلة بالظهور. نحن فقط أصلحنا النتيجة.
ولهذا من المفيد بعد كل مشكلة مهمة أن نفصل بين سؤالين:
كيف نعيد العمل الآن؟
ثم:
ما الذي يجب تغييره حتى تصبح هذه المشكلة أصعب في الحدوث مرة أخرى؟
السؤال الأول هو الاستجابة.
والثاني هو التحسين.
نحتاج الاثنين.
ابحث عن السبب الذي يمكن تغييره
مصطلح "السبب الجذري" قد يجعل الأمر يبدو وكأن لكل حادثة سببًا واحدًا عميقًا ينتظر أن نكتشفه.
الواقع غالبًا أكثر تعقيدًا.
قد تجتمع عدة عوامل:
تعليمات غير واضحة.
واجهة تسمح بخطأ.
اختبار ناقص.
اعتماد على الذاكرة.
معلومة لم تصل إلى الشخص الصحيح.
وضغط وقت جعل الخطأ أكثر احتمالًا.
لذلك لا نحتاج دائمًا إلى العثور على "السبب النهائي".
يكفينا أحيانًا أن نجد سببًا يمكن تغييره وله أثر حقيقي.
إذا كان تعديل واجهة صغيرة يمنع الخطأ، فهذا تقدم.
إذا كانت إضافة تحقق تلقائي تمنعه، فهذا أفضل.
إذا كانت ملاحظة واضحة في مكان التنفيذ تمنع تكراره، فهي أيضًا تحسين مشروع.
الهدف ليس حل اللغز فلسفيًا.
الهدف أن نجعل المسار القادم أكثر أمانًا.
لا تكتب "انتبه أكثر" كإجراء تصحيحي
من أضعف نتائج تحليل المشكلات أن ننتهي إلى:
يجب أن نكون أكثر حذرًا.
يجب ألا ننسى.
يجب مراجعة العمل جيدًا.
هذه النصائح قد تكون صحيحة، لكنها لا تغير النظام كثيرًا.
إذا كان الخطأ ممكنًا بالأمس، سيظل ممكنًا غدًا.
الإجراء الأقوى يغيّر البيئة نفسها.
بدل:
تذكّر إدخال القيمة.
اجعل الحقل مطلوبًا.
بدل:
لا تستخدم النسخة القديمة.
اجعل النسخة الصحيحة واضحة افتراضيًا.
بدل:
تأكد يدويًا من الشرط قبل النشر.
أضف فحصًا يمنع النشر إذا لم يتحقق الشرط.
كلما نقلنا المعرفة من «ما ينبغي للإنسان أن يتذكره» إلى «ما يساعده النظام على فعله»، قل اعتمادنا على الانتباه المثالي.
صنّف التحسين حسب قوته
ليست كل الإجراءات التصحيحية متساوية.
يمكن التفكير فيها كسلم بسيط.
في أضعف مستوى:
التذكير.
اكتب ملاحظة أو أرسل تنبيهًا.
فوقه:
قائمة تحقق.
اجعل الخطوة جزءًا ثابتًا من العملية.
ثم:
تحقق آلي.
دع النظام يكتشف الحالة الخطرة.
ثم:
منع الخطأ.
اجعل المسار غير الصحيح صعبًا أو مستحيلًا أصلًا.
ليس مطلوبًا الوصول دائمًا إلى المستوى الأخير.
لكن هذا السلم يساعدنا على طرح سؤال مفيد:
هل نعالج المشكلة بأقوى طريقة معقولة، أم نكتفي بتذكير الناس ألا يكرروا الخطأ؟
المشكلة المتكررة ليست المشكلة نفسها
إذا ظهرت المشكلة مرة، قد تكون حادثة.
إذا عادت للمرة الثانية، أصبحت لدينا معلومة جديدة:
الإصلاح السابق لم يكن كافيًا.
وهذه نقطة مهمة.
بدل أن نقول:
حدث الخطأ مرة أخرى.
الأفضل أن نقول:
النظام سمح للخطأ نفسه بالعودة رغم معرفتنا السابقة به.
هذا يغيّر طريقة التفكير.
المشكلة لم تعد في الواقعة فقط.
بل في أن المعرفة الناتجة من الواقعة السابقة لم تصبح جزءًا من النظام.
وهذا يربط مباشرة بثيمة هذا الأسبوع:
الخبرة التي لا تغيّر طريقة العمل قد تتبخر، حتى لو وثقناها جيدًا.
احتفظ بسجل صغير للمشكلات المتكررة
لا تحتاج إلى نظام ضخم لإدارة هذا النوع من التعلم.
يمكن أن يكفي لكل حادثة مهمة أربعة أسطر:
ماذا حدث؟
ما السبب الذي استطعنا معالجته؟
ما التغيير الذي أضفناه؟
كيف سنعرف إن نجح؟
مثلًا:
المشكلة: تم نشر سجل دون قيمة ضرورية.
السبب: الحقل اختياري في الواجهة رغم أنه مطلوب فعليًا.
التحسين: جعله إلزاميًا مع تحقق قبل الحفظ.
القياس: عدم ظهور الحالة نفسها خلال الشهر التالي.
هذه الملاحظة لا تحفظ التاريخ فقط.
هي تربط المشكلة بالتحسين وبطريقة معرفة ما إذا كان التحسين نجح.
لا تصلح كل شيء أثناء الأزمة
هناك خطأ معاكس أيضًا.
أثناء حدوث مشكلة حرجة، قد ننجرف إلى إعادة تصميم النظام كله.
لكن لحظة الأزمة ليست دائمًا أفضل وقت للتحسين العميق.
عندما يكون المستخدمون متوقفين، الأولوية هي استعادة الخدمة بأمان.
بعد الاستقرار، يمكن العودة إلى السبب وتحسين العملية.
لهذا من المفيد فصل مرحلتين:
الاحتواء الآن.
ثم:
التحسين بعد الاستقرار.
هذا يمنعنا من إجراء تغييرات كبيرة تحت الضغط، لكنه يضمن أيضًا ألا ننسى الدرس بمجرد عودة الأمور إلى طبيعتها.
اجعل المشكلات الصغيرة إشارات مبكرة
ليس علينا انتظار حادثة ضخمة حتى نتعلم.
الخطأ الذي كاد يحدث مهم أيضًا.
المستخدم الذي توقف وسأل قبل تنفيذ خطوة خاطئة أعطاك إشارة.
المهمة التي احتاجت تدخل شخص خبير في اللحظة الأخيرة أعطتك إشارة.
العملية التي نجحت لكن بصعوبة أعطتك إشارة.
هذه الحالات تكشف مناطق الهشاشة قبل أن تتحول إلى أزمات حقيقية.
أحيانًا أفضل وقت لإصلاح مشكلة هو قبل أن تصبح مشكلة.
راقب ما يتكرر، لا ما يزعجك فقط
بعض المشكلات مزعجة جدًا لكنها نادرة.
وبعضها صغير لكنه يحدث كل أسبوع.
المشكلة الصغيرة المتكررة قد تستهلك موارد أكثر على المدى الطويل.
لذلك من المفيد النظر إلى ثلاث قيم:
كم يحدث الخطأ؟
ما كلفة كل مرة؟
كم تكلف معالجته جذريًا؟
إذا كانت المشكلة تستغرق عشر دقائق لكنها تحدث عشرات المرات، فقد تستحق التحسين أكثر من حادثة كبيرة وقعت مرة واحدة.
التراكم يعمل في الاتجاهين.
الأخطاء الصغيرة تتراكم أيضًا.
اجعل كل إصلاح يترك النظام أقوى قليلًا
هناك طريقة بسيطة لقياس نضج العمل.
اسأل بعد مرور سنة:
هل ما زلنا نواجه المشكلات نفسها بالطريقة نفسها؟
إذا كانت الإجابة نعم، فنحن ربما نعمل بجد، لكن الخبرة لا تتراكم.
أما إذا كانت مشكلات العام الماضي أصبحت اليوم:
تحققًا تلقائيًا،
أو قالبًا،
أو قاعدة،
أو اختبارًا،
أو إجراءً أوضح،
فهذا يعني أن النظام يحتفظ بما تعلمناه.
ومع الوقت يحدث شيء جميل:
حتى الأيام السيئة تبدأ بإنتاج قيمة طويلة الأجل.
فالعطل لا يبقى خسارة خالصة.
يصبح ثمنًا دفعناه مقابل معرفة جديدة، ثم حرصنا ألا ندفع الثمن نفسه مرة أخرى.
لهذا، عندما تحل مشكلة اليوم، لا تسأل فقط:
هل انتهت؟
اسأل أيضًا:
ما الذي أصبح أفضل بسبب حدوثها؟
إذا وجدت إجابة واضحة، فالمشكلة لم تمر عبثًا.
لقد تحولت إلى جزء من نظام يعرف كيف يتعلم.