فريقي كان يخشى الاعتراف بالخطأ: كيف أنقذتنا ‘ثقافة استعراض الأخطاء بلا لوم’ من جحيم المشاكل الخفية؟

أذكر ذلك اليوم جيدًا، كان يوم خميس، وكما جرت العادة، كنا على وشك إطلاق تحديث جديد ومهم للتطبيق. الأجواء كانت مشحونة بالترقب، “القهوة شغّالة” والكل على أعصابه. ضغطت زر النشر (Deploy)، وخلال دقائق، بدأت الكارثة. انهالت علينا التنبيهات من نظام المراقبة كالمطر، الخوادم تستغيث، والمستخدمون يشتكون من توقف الخدمة بالكامل. حالة من الفوضى العارمة سادت المكتب، والكل يركض في كل اتجاه.

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

بعد انتهاء الأزمة، جلست مع نفسي وأنا أحتسي كوبًا من الميرمية لأهدئ أعصابي، وأدركت أن المشكلة الحقيقية لم تكن في الكود الخاطئ، فهذا جزء طبيعي من عملنا، بل كانت في ثقافتنا. لقد بنينا بيئة عمل سامة، يخشى فيها المهندس من الاعتراف بخطئه خوفًا من العقاب أو التوبيخ. هنا كانت نقطة التحول، حيث قررت أن هذا الجحيم من المشاكل الخفية ولعبة الاختباء يجب أن ينتهي. وكان الحل هو تبني ما يُعرف بـ “ثقافة استعراض الأخطاء بلا لوم” أو الـ Blameless Postmortems.

لماذا تفشل ثقافة “البحث عن كبش فداء”؟

قبل أن نغوص في الحل، دعونا نشخّص المرض. عندما تكون ثقافة الفريق مبنية على اللوم، تحدث الكوارث التالية:

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

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

الحل السحري: ثقافة استعراض الأخطاء بلا لوم (Blameless Postmortems)

الـ Postmortem هو مصطلح طبي يعني “تشريح الجثة بعد الوفاة” لمعرفة سبب الموت. في عالم التقنية، هو اجتماع أو وثيقة تُكتب بعد وقوع حادث (Incident) مثل توقف الخدمة، لتحليل ما حدث ومنع تكراره. أما إضافة كلمة “Blameless” (بلا لوم) فهي التي تصنع كل الفرق.

الفلسفة الأساسية بسيطة لكنها ثورية:

“نحن نفترض أن كل شخص شارك في الحادث كانت لديه نوايا حسنة، وبذل قصارى جهده بناءً على المعلومات والأدوات التي كانت متاحة له في ذلك الوقت.”

هذا يعني أننا ننتقل من سؤال “من السبب؟” إلى سؤال “ما السبب؟”. نحن لا نبحث عن شخص لنعاقبه، بل نبحث عن نقاط ضعف في أنظمتنا، عملياتنا، وأدواتنا لنقوم بتقويتها.

كيف تبني هذه الثقافة خطوة بخطوة؟

التغيير ليس سهلاً، ويتطلب التزامًا من الإدارة العليا قبل أي شخص آخر. إليكم الخطوات العملية التي اتبعناها في فريقنا والتي يمكنك تطبيقها فورًا.

الخطوة الأولى: تغيير العقلية (من القائد أولاً)

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

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

الخطوة الثانية: عقد اجتماع “التشريح” (The Postmortem Meeting)

بعد كل حادث تقني (كبيرًا كان أم صغيرًا)، وبعد أن تعود الأمور إلى طبيعتها، نعقد اجتماعًا خاصًا. هذا الاجتماع له قواعد صارمة:

• الحضور: كل من له علاقة بالحادث، من المبرمج إلى مهندس الأنظمة وحتى مسؤول المنتج.
• الميسّر (Facilitator): يجب أن يكون هناك شخص يدير الجلسة، وظيفته الأساسية هي الحفاظ على “انعدام اللوم”. إذا بدأ أحدهم بالقول “لو أن فلان فعل كذا…”، يتدخل الميسّر فورًا ويقول: “دعونا نركز على العملية. كيف يمكن لنظامنا أن يمنع حدوث هذا في المستقبل بغض النظر عمن كان يقوم بالمهمة؟”.
• التركيز على الحقائق: نبدأ بسرد تسلسل زمني دقيق للأحداث (Timeline) بدون أي آراء شخصية. “في الساعة 10:05 تم نشر الكود X. في الساعة 10:08 بدأت التنبيهات بالوصول…”.

الخطوة الثالثة: وثيقة العِبَر (The Postmortem Document)

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

# عنوان التقرير: [مثال: توقف خدمة تسجيل الدخول لمدة 15 دقيقة]

**تاريخ الحادث:** 2023-10-26

**ملخص (TL;DR):**
توقفت خدمة تسجيل الدخول لمدة 15 دقيقة بسبب استنفاد pool الاتصالات بقاعدة البيانات بعد تحديث مكتبة الاتصال (DB Connector). تم حل المشكلة عبر إعادة النظام للنسخة السابقة وزيادة عدد الاتصالات المسموح بها مؤقتًا.

**التأثير على المستخدمين:**
- حوالي 30% من المستخدمين لم يتمكنوا من تسجيل الدخول.
- زيادة في معدل الأخطاء (HTTP 503) بنسبة 80%.

**الجدول الزمني للأحداث (بتوقيت UTC):**
- 14:00 - بدء نشر الإصدار الجديد v2.5.
- 14:05 - اكتمال النشر بنجاح.
- 14:07 - أول تنبيه من نظام المراقبة عن ارتفاع أخطاء 5xx.
- 14:10 - إعلان حالة الطوارئ (Incident) وبدء التحقيق.
- 14:18 - الشكوك تحوم حول تحديث قاعدة البيانات.
- 14:22 - اتخاذ قرار العودة للإصدار السابق v2.4.
- 14:25 - عودة الخدمة إلى طبيعتها.

**تحليل السبب الجذري (Root Cause Analysis - 5 Whys):**
1.  **لماذا توقفت الخدمة؟** لأن الخادم لم يستطع إنشاء اتصالات جديدة مع قاعدة البيانات.
2.  **لماذا؟** لأن pool الاتصالات وصل إلى حده الأقصى.
3.  **لماذا؟** لأن مكتبة الاتصال الجديدة (v3.0) التي قمنا بتحديثها تتطلب إعدادات مختلفة للـ pool لم نكن على علم بها.
4.  **لماذا؟** لأن توثيق المكتبة لم يذكر هذا التغيير بوضوح في قسم "Breaking Changes"، وعملية المراجعة (Code Review) لم تلتقط هذه المشكلة.
5.  **لماذا؟** لأننا لا نملك بيئة اختبار (Staging Environment) تحاكي ضغط المستخدمين الحقيقي، ولا يوجد لدينا قائمة تدقيق (Checklist) للمراجعة عند تحديث المكتبات الحساسة.
    **(لاحظ: السبب الجذري هو مشكلة في العملية والنظام، وليس خطأ المبرمج الذي قام بالتحديث).**

**الإجراءات التصحيحية (Action Items):**
- [ ] (عاجل) تحديث توثيقنا الداخلي ليشمل قائمة تدقيق عند تحديث أي مكتبة أساسية. (المسؤول: أحمد، تاريخ التسليم: 2023-11-02)
- [ ] (متوسط) بناء بيئة اختبار أداء (Load Testing) تحاكي 50% من ضغط الإنتاج. (المسؤول: فريق DevOps، تاريخ التسليم: 2023-12-15)
- [ ] (طويل الأمد) إعداد نظام تنبيه مخصص لمراقبة عدد الاتصالات المتاحة في pool قاعدة البيانات. (المسؤول: سارة، تاريخ التسليم: 2024-01-10)

**الدروس المستفادة:**
- لا يجب الوثوق بشكل أعمى بتحديثات المكتبات الخارجية.
- الحاجة الماسة لاختبارات الأداء قبل النشر أصبحت واضحة.

ثمار ثقافة “استعراض الأخطاء بلا لوم”

بعد تطبيق هذه المنهجية بصرامة لعدة أشهر، بدأت أرى تغييرات مذهلة في فريقي:

• السلامة النفسية (Psychological Safety): أصبح المهندسون يشاركون أفكارهم الجريئة ويجربون تقنيات جديدة دون خوف. أحدهم قال لي مرة: “أبو عمر، لأول مرة أشعر أنني أستطيع أن أقول ‘لا أعرف’ أو ‘لقد أخطأت’ دون أن أشعر بالخجل”.
• سرعة حل المشاكل: عند وقوع أي حادث الآن، الجميع يهب للمساعدة. لم يعد هناك وقت ضائع. نرى تعاونًا حقيقيًا لأن الهدف واحد: حل المشكلة.
• نظام أكثر صلابة: كل “وثيقة عِبَر” نكتبها هي بمثابة تطعيم لنظامنا ضد أخطاء المستقبل. أصبح نظامنا أقوى وأكثر موثوقية لأننا نعالج الأسباب الجذرية، لا الأعراض.
• فريق أكثر سعادة وإنتاجية: انخفض التوتر بشكل ملحوظ، وزادت الروح المعنوية. أصبح الفريق مكانًا للتعلم والنمو، وليس ساحة للمعركة.

الخلاصة يا جماعة الخير 🙏

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

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