كان الخطأ يعني الإعدام: كيف أنقذتنا ‘مراجعات ما بعد الحادثة بلا لوم’ من ثقافة الخوف؟

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

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

ما هي “مراجعات ما بعد الحادثة” (Postmortems)؟ ولماذا “بلا لوم”؟

ببساطة، “مراجعة ما بعد الحادثة” أو كما نسميها “Postmortem” هي جلسة منظمة نعقدها بعد وقوع أي حادث تقني كبير (مثل توقف خادم، خطأ فادح في البيانات، ثغرة أمنية). الهدف هو تحليل ما حدث بشكل منهجي لفهم الأسباب الجذرية ومنع تكراره في المستقبل.

لكن الكلمة السحرية هنا هي “بلا لوم” (Blameless). هذه ليست مجرد إضافة لطيفة، بل هي جوهر العملية كلها. فكرة “بلا لوم” تقوم على مبدأ أساسي غير قابل للتفاوض:

نحن نؤمن بأن كل فرد في الفريق قام بأفضل ما يمكنه بناءً على المعلومات والمهارات والأدوات التي كانت متاحة له في ذلك الوقت.

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

التحول من “من فعلها؟” إلى “لماذا حدثت؟”

هذا التحول في التفكير هو الفرق بين فريق ينمو وفريق يتآكل. دعونا نقارن بين الثقافتين.

ثقافة اللوم: وصفة جاهزة للفشل

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

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

ثقافة السلامة النفسية: أرض خصبة للنمو

على النقيض تمامًا، عندما نتبنى نهج “بلا لوم”، فإننا نبني ما يسمى بـ “السلامة النفسية” (Psychological Safety). هذه البيئة تسمح بما يلي:

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

كيف ندير جلسة مراجعة ما بعد الحادثة بلا لوم؟ (دليل أبو عمر العملي)

الكلام النظري جميل، لكن “كيف بنطبق هالحكي على أرض الواقع؟”. إليكم الخطوات العملية التي نتبعها في فريقنا.

الخطوة 1: الإعداد والتحضير (قبل الجلسة)

هذه المرحلة حاسمة لنجاح الجلسة.

• تعيين مُيسّر (Facilitator): نختار شخصًا (ليس بالضرورة المدير) ليكون مسؤولاً عن إدارة الجلسة. يجب أن يكون محايدًا ومهمته هي الحفاظ على سير النقاش بشكل بنّاء ومنع الانزلاق نحو اللوم.
• جمع الحقائق، لا الآراء: قبل الجلسة، يقوم المُيسّر بجمع كل البيانات الموضوعية المتاحة: سجلات النظام (logs)، الرسوم البيانية للمراقبة (monitoring graphs)، التنبيهات (alerts)، سجل تغييرات الكود (commit history)، محادثات الفريق على Slack/Teams أثناء الحادثة.
• بناء الخط الزمني للحادثة: يتم ترتيب كل هذه البيانات في خط زمني دقيق وموضوعي. مثال:
  • 10:00 صباحًا: تم دمج طلب السحب (Pull Request #542) ونشره على البيئة الإنتاجية.
  • 10:05 صباحًا: بدأ مؤشر أخطاء الخادم (Server Error Rate) بالارتفاع من 0.1% إلى 15%.
  • 10:07 صباحًا: أطلق نظام المراقبة تنبيه PagerDuty.
  • 10:15 صباحًا: تم التراجع عن النشر (rollback) إلى الإصدار السابق.
  • 10:17 صباحًا: عادت مؤشرات النظام إلى وضعها الطبيعي.

الخطوة 2: سير الجلسة (أثناء الاجتماع)

هنا يحدث السحر الحقيقي.

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

الخطوة 3: المخرجات والإجراءات التصحيحية (بعد الجلسة)

الجلسة لا قيمة لها بدون مخرجات عملية.

• تحديد الأسباب الجذرية: لا نكتفي بالسبب السطحي. مثال: “السبب ليس أن المطور ‘سالم’ أضاف كودًا خاطئًا، بل السبب الجذري هو أن مكتبة الاختبارات لدينا لا تغطي هذا النوع من الحالات، وعملية النشر لم تتضمن خطوة تراجع آلي عند ارتفاع معدل الأخطاء”.
• إنشاء مهام قابلة للتنفيذ (Action Items): لكل سبب جذري، ننشئ مهمة واضحة، قابلة للقياس، ومسندة لشخص ما (أو فريق)، مع موعد نهائي.
  • مثال سيء: “على سالم أن يكون أكثر انتباهًا”. (لوم وغير قابل للتنفيذ)
  • مثال جيد: “مهمة: إضافة اختبارات تكامل (integration tests) لتغطية سيناريو [X]. المالك: فريق الجودة. الموعد: نهاية الأسبوع”.
  • مثال ممتاز: “مهمة: تعديل مسار النشر (CI/CD pipeline) ليقوم بالتراجع التلقائي (automatic rollback) إذا تجاوز معدل الأخطاء 5% خلال الدقيقة الأولى من النشر. المالك: فريق DevOps. الموعد: 15 يومًا”.
• مشاركة التقرير: نكتب ملخصًا للجلسة (الخط الزمني، الأسباب، والإجراءات التصحيحية) ونشاركه مع كل الفرق الهندسية. الشفافية تعمم الفائدة وتمنع تكرار نفس الأخطاء في فرق أخرى.

خلاصة أبو عمر ونصيحة من القلب 🧡

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

نصيحتي لك: ابدأ صغيرًا. في المرة القادمة التي تحدث فيها مشكلة في فريقك، مهما كانت صغيرة، قاوم غريزة البحث عن “المُذنب”. بدلًا من ذلك، اجمع المعنيين في غرفة (أو في اجتماع افتراضي)، وقل لهم: “يا جماعة، خلينا نفهم شو اللي صار عشان ما يصير مرة ثانية، بدون ما نلوم حدا”.

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