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