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

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

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

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

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

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

ما هي “السلامة النفسية” في فريق العمل؟ وليش هي مهمة؟

السلامة النفسية (Psychological Safety) مش مجرد مصطلح رنان من كتب الإدارة، ولا تعني أن الكل لطيف مع الكل طول الوقت. ببساطة، هي الإيمان المشترك بين أعضاء الفريق بأنهم لن يتعرضوا للعقاب أو الإهانة عند التعبير عن أفكارهم، أو طرح الأسئلة، أو الاعتراف بالأخطاء، أو اقتراح تحسينات حتى لو بدت غريبة.

في بيئة العمل الآمنة نفسياً، يشعر المبرمج بالراحة ليقول:

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

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

أعراض ثقافة اللوم: كيف تعرف أن فريقك في خطر؟

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

1. الصمت القاتل في الاجتماعات

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

2. لعبة “إصبع الاتهام” بعد كل مشكلة

عندما يحدث خطأ في الإنتاج (Production bug)، ما هو السؤال الأول الذي يُطرح؟

• في ثقافة اللوم: “من الذي كتب هذا الكود؟”
• في ثقافة السلامة النفسية: “ماذا حدث؟ وكيف يمكننا إصلاحه ومنع تكراره؟”

التركيز على “من” يقتل روح المبادرة، بينما التركيز على “ماذا وكيف” يبني نظاماً أقوى.

3. الخوف من التجربة والابتكار

الابتكار يتطلب التجربة، والتجربة تحتمل الفشل. إذا كان الفشل يُقابل بالعقاب، سيتوقف الفريق عن تجربة أي شيء جديد. سيلجأون إلى الحلول الآمنة والمجربة فقط، حتى لو لم تكن الأفضل، مما يؤدي إلى ركود تقني وقتل للإبداع.

4. “تسييح” المسؤولية وتجنبها

تسمع جملاً مثل “تم اختبار الميزة” بدلاً من “أنا اختبرت الميزة”. أو “الكود يبدو سليماً” بدلاً من “لقد راجعت الكود وهو سليم”. هذا التهرب من المسؤولية الشخصية هو آلية دفاعية في بيئة غير آمنة.

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

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

الخطوة الأولى: القيادة بالقدوة (Lead by Example)

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

الخطوة الثانية: تغيير لغة الحوار: من “لماذا؟” إلى “كيف؟”

الكلمات لها قوة هائلة. استبدل الأسئلة التي تبدو اتهامية بأسئلة استكشافية:

بدلاً من أن تسأل: “لماذا لم تكتشف هذا الخطأ أثناء الاختبار؟”

اسأل: “يبدو أن عملية الاختبار الحالية لم تكن كافية لاكتشاف هذا النوع من الأخطاء. كيف يمكننا تحسينها؟ هل نحتاج إلى إضافة حالات اختبار (test cases) جديدة؟”

هذا التحول ينقل التركيز من لوم الفرد إلى تحسين النظام والعمليات، وهو جوهر الهندسة الحقيقية.

الخطوة الثالثة: تطبيق جلسات “Blameless Postmortems”

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

# === Blameless Postmortem Template ===

## 1. Summary
- موجز للمشكلة، التأثير، والحل.

## 2. Timeline of Events
- سجل زمني دقيق للأحداث من لحظة اكتشاف المشكلة حتى حلها.
- مثال: 10:05 AM: بدأ رصد زيادة في أخطاء 500.
- مثال: 10:15 AM: تم إعلام الفريق المسؤول.

## 3. Root Cause Analysis (The 5 Whys)
- هنا لا نسأل "من"، بل نسأل "لماذا" بشكل متكرر للوصول إلى السبب الجذري.
- المشكلة: توقف النظام عن العمل.
- لماذا؟ لأن قاعدة البيانات استهلكت كل الاتصالات.
- لماذا؟ لأن هناك استعلاماً (query) بطيئاً يتم تشغيله بكثرة.
- لماذا؟ لأن التحديث الأخير أضاف هذه الميزة دون فهرسة (indexing) مناسبة.
- لماذا؟ لأن عملية مراجعة الكود لم تتضمن مراجعة أداء الاستعلامات.
- لماذا؟ لأنه لا توجد لدينا قائمة تحقق (checklist) لمراجعة الكود تشمل الأداء.
- **النتيجة: السبب الجذري ليس خطأ المبرمج، بل غياب عملية مراجعة أداء في الـ checklist.**

## 4. Action Items (What we will do to prevent this)
- مهام واضحة مع تحديد المسؤول والموعد النهائي.
- مثال: [مهمة] إضافة بند "مراجعة أداء استعلامات قاعدة البيانات" إلى checklist مراجعة الكود. [المسؤول: أبو عمر] [الموعد: نهاية الأسبوع]

## 5. What Went Well?
- دائماً هناك شيء إيجابي، مثل سرعة اكتشاف المشكلة أو تعاون الفريق في حلها.

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

الخطوة الرابعة: تشجيع الأسئلة “الغبية” والاحتفاء بها

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

نصيحة من قلب “أبو عمر”

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

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

الخلاصة: فريق آمن = منتج قوي 🚀

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

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