كان الصمت يصم الآذان: كيف أنقذت ‘السلامة النفسية’ فريقنا من جحيم الأخطاء المدفونة؟

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

كنتُ قائد الفريق وقتها، وأرى الوجوه أمامي مطأطئة، والعيون تتجنب النظر في عيني مباشرة. سألت سؤالي المعتاد: “شباب، صبايا، كيف الأمور؟ في أي مشاكل؟ أي عوائق؟”. والجواب كان… صمت. همهمات خفيفة، “كله تمام”، “ماشي الحال”. لكني كنت أعرف، بحدسي وخبرتي، أن “كله مش تمام بالمرة”. كان هناك “บั그” (Bug) لعين يظهر ويختفي في النظام، يعبث بالنتائج ويجعلنا نبدو كمن يحلل بيانات الطقس بدلاً من الصور الطبية.

استمر هذا الوضع لأسبوعين كاملين. أسبوعان من الجحيم الصامت. كل يوم نفس الاجتماع، نفس الصمت، ونفس “البَغ” اللعين الذي لا نعرف مصدره. إلى أن انفجرت في أحد الأيام وقلت على بلاطة: “يا جماعة، شو القصة؟ الصمت هذا رح يغرقنا كلنا. حدا يحكي! حدا يغلط! حدا يقول ‘أنا خبصت الدنيا’! أي إشي أحسن من هالمقبرة اللي قاعدين فيها!”.

بعد لحظة من الصدمة، رفع يده مبرمج شاب، دعنا نسميه “خالد”. بصوت متردد قال: “أبو عمر، يمكن… يمكن أنا السبب. قبل أسبوعين، غيّرت إعدادات الـ Caching في المكتبة الفلانية عشان أسرّع النظام، وما خبرت حدا لأني ما كنت متأكد إذا صح أو لأ… وخفت تحكوا إني بلعب بالنار”.

في تلك اللحظة، لم أشعر بالغضب، بل بالراحة. وأدركت أن المشكلة لم تكن في كود خالد، بل في “كود” الفريق نفسه. المشكلة كانت في انعدام ما يُعرف اليوم بـ “السلامة النفسية”.

ما هي “السلامة النفسية” (Psychological Safety) على أرض الواقع؟

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

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

علامات الخطر: كيف تعرف أن فريقك في “المنطقة الحمراء”؟

قبل أن نصل للحل، عليك أن تعرف كيف تشخص المشكلة. فريقك يفتقر للسلامة النفسية إذا لاحظت هذه الأعراض:

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

من الجحيم إلى النعيم: خطوات عملية لبناء السلامة النفسية

طيب يا أبو عمر، شخصنا المشكلة، كيف الحل؟ الحل ليس عصا سحرية، بل هو بناء ثقافة، وهذا يأخذ وقتاً وجهداً. وهذه هي الخطوات التي اتخذتها شخصياً وغيرت فريقي 180 درجة:

1. القائد يبدأ بنفسه: اعترف بأخطائك أولاً وبشكل علني

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

نصيحة من القلب: في المرة القادمة التي ترتكب فيها خطأً، ولو كان صغيراً، لا تحاول إخفاءه. اذهب إلى قناتكم العامة على Slack وقل: “يا جماعة، للتو قمت بعمل `push` لكود فيه مشكلة عن طريق الخطأ، وأنا أعمل على إصلاحه الآن. أعتذر عن أي إزعاج”. سترى كيف سيغير هذا التصرف البسيط الديناميكية كلها.

2. أتقن فن “التشريح بلا لوم” (Blameless Postmortems)

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

لقد قمنا بتبني قالب بسيط ومباشر لمثل هذه الجلسات، يمكنك استخدامه كنقطة بداية:

# تقرير ما بعد الحادثة (Postmortem) - [اسم المشكلة]

## ملخص الحادثة (Timeline)
- **[تاريخ ووقت الاكتشاف]:** تم اكتشاف المشكلة بواسطة [شخص/نظام].
- **[تاريخ ووقت التأثير]:** بدأ التأثير الفعلي على المستخدمين/النظام.
- **[تاريخ ووقت الحل]:** تم حل المشكلة وعاد النظام للعمل.
- **المدة الإجمالية للتوقف/التأثير:** [XX ساعة/دقيقة].

## الأسباب الجذرية (Root Causes)
- **السبب التقني 1:** (مثال: انتهاء صلاحية شهادة SSL لم يتم تجديدها تلقائياً).
- **السبب العملياتي 2:** (مثال: لم يكن هناك تنبيه لمراقبة صلاحية الشهادات).
- **السبب التنظيمي 3:** (مثال: لم تكن مسؤولية تجديد الشهادات واضحة ومسندة لشخص معين).

## الإجراءات التصحيحية (Action Items)
- [ ] **الإجراء 1:** كتابة سكربت لمراقبة صلاحية الشهادات وإرسال تنبيه قبل 30 يوماً (المسؤول: فلان، الموعد: DD/MM/YYYY).
- [ ] **الإجراء 2:** توثيق عملية تجديد الشهادات في دليل الفريق (المسؤول: علان، الموعد: DD/MM/YYYY).

## ما الذي سار بشكل جيد؟
- (مثال: كان فريق الدعم سريعاً في تحديد المشكلة).

## ما الذي يمكننا تحسينه؟
- (مثال: نحتاج إلى قناة تواصل أوضح عند حدوث أزمات).

هذا الأسلوب يحوّل الحوادث من مصدر للخوف واللوم إلى فرصة ذهبية للتعلم وتحصين النظام.

3. شجع الفضول واقتل مفهوم “السؤال الغبي”

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

4. افصل بين الأداء والنقاش

في عالمنا التقني، مراجعة الكود (Code Review) هي ساحة معركة محتملة. غيّر قواعد اللعبة. بدلاً من أن تكون التعليقات عبارة عن أوامر (“غيّر هذا”)، اجعلها أسئلة (“ما رأيك لو جربنا هذه الطريقة؟ هل فكرت في حالة كذا وكذا؟”).

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

5. احتفل بالمحاولات، وليس فقط بالنجاحات

عندما يجرب أحد أعضاء الفريق مكتبة جديدة وتفشل، أو يقترح بنية معمارية للنظام ثم يكتشف الجميع أنها غير مناسبة، لا تعاقبوه! بل احتفلوا بالدرس المستفاد. قلوا بصوت عالٍ: “شكراً يا فلان لأنك خضت هذه التجربة، الآن كلنا نعرف أن هذا الطريق ليس مناسباً لنا، وقد وفرت علينا شهوراً من العمل في الاتجاه الخاطئ”. هذا هو تعريف “الفشل الذكي” (Intelligent Failure)، وهو محرك الابتكار الحقيقي.

الخلاصة على بلاطة 📝

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

البيئة التي تشجع على الصراحة والشفافية ستكتشف “บั그” خالد في خمس دقائق، وليس في أسبوعين. وستوفر عليك الوقت، والمال، والكثير من التوتر والشعر الأبيض.

ابدأ اليوم. ابدأ بنفسك. اعترف بخطأ صغير، اشكر شخصاً على سؤال “بسيط”، وحوّل جلسة اللوم القادمة إلى جلسة تعلم. ازرع بذرة السلامة النفسية اليوم، وستحصد فريقاً لا يقهر غداً. 🌱