بتذكر منيح هذاك اليوم، كنا في اجتماع عصف ذهني لمشروع جديد ومهم. الغرفة مليانة شباب وصبايا، كلهم أذكياء وشاطرين. طرحت أنا، بصفتي قائد الفريق التقني، المشكلة وطلبت منهم أفكار “خارج الصندوق”.
لكن اللي صار هو صمت… صمت ثقيل ومحرج. الكل كان يطلع في الثاني أو في شاشة اللابتوب تبعته. حاولت ألطّف الجو، حكيت نكتة، بس ما حدا ضحك. حسيت حالي بحكي مع حيطان.
بعد الاجتماع، إجا لعندي “خليل”، مبرمج جديد معنا، شب صغير بس عقله ألماظ. قلي بصوت واطي: “يا أبو عمر، بصراحة كانت عندي فكرة بس خفت أحكيها… خفت تطلع غبية أو حدا يضحك عليّ”.
هاي الجملة ضربتني زي الصاعقة. مش لأن خليل خاف، بس لأني أدركت إن أنا وفريقي بنينا، بدون ما نحس، بيئة بتقتل الأفكار قبل ما تنولد. بيئة فيها الخوف من الخطأ أكبر من الرغبة في الإبداع. هون كانت بداية رحلتي مع مفهوم “السلامة النفسية” (Psychological Safety)، المفهوم اللي أنقذنا من جحيم الأفكار الميتة.
ما هي “السلامة النفسية” وليش هي “إشي” مهم؟
ببساطة يا جماعة، السلامة النفسية هي الإيمان المشترك بين أعضاء الفريق بأنهم بيقدروا ياخدوا مخاطر شخصية بدون ما يتعرضوا للإحراج أو العقاب. يعني، بتقدر تسأل سؤال “غبي”، أو تعترف إنك مش فاهم شغلة، أو تقترح فكرة مجنونة، أو حتى تنتقد فكرة المدير (بطريقة محترمة طبعاً)، وانت متطمن إنه ما حدا راح “يستلمك” أو يعتبرك غير كفؤ.
هاي مش رفاهية أو “دلع”. حسب أبحاث جوجل في مشروع أرسطو (Project Aristotle)، السلامة النفسية كانت العامل رقم واحد في تحديد نجاح الفرق عالية الأداء. ليش؟
- تشجع على الابتكار: لما الناس ما تخاف من الفشل، بتبدأ تجرب أشياء جديدة ومجنونة، ومن هاي التجارب بتطلع أفضل الحلول.
- تسرّع حل المشاكل: المبرمج ما بخاف يعترف إنه عمل bug، فبينكشف الخطأ وبيتصلح بسرعة قبل ما يعمل كارثة.
- تحسن التعلم: الكل بسأل وبجاوب وبشارك معرفته بحرية، فمستوى الفريق كله بيرتفع.
- تقلل من دوران الموظفين: مين بحب يشتغل في بيئة كلها توتر وخوف؟ لما الموظف يحس بالأمان، بيزيد انتمائه للفريق وللشركة.
علامات الخطر: كيف تعرف إن فريقك يفتقر للسلامة النفسية؟
قبل ما نعالج المشكلة، لازم نشخصها. إذا شفت هاي الأعراض في فريقك، فهذا ضوء أحمر كبير:
- صمت القبور في الاجتماعات: نفس الموقف اللي صار معي. الأسئلة الوحيدة اللي بتنسأل هي “متى الديدلاين؟”.
- ظاهرة “كله تمام يا ريس”: ما حدا بعترف بوجود مشكلة. كل تقارير الحالة خضراء ووردية، وفجأة المشروع بتفجر في وجهك.
- لعبة إلقاء اللوم: لما تصير مشكلة، أول سؤال بينسأل هو “مين عمل هيك؟” بدل “كيف صار هيك وكيف نمنعه المرة الجاي؟”.
- غياب الأفكار “الغريبة”: كل الأفكار المقترحة آمنة ومكررة. ما حدا عنده الجرأة يقترح حل جذري أو مختلف.
- كثرة “الحكي من ورا الظهر”: أعضاء الفريق بشتكوا لبعضهم البعض بدلاً من مواجهة المشاكل بشكل مباشر وبنّاء.
خطوات عملية لبناء ثقافة السلامة النفسية (من دفتر أبو عمر)
طيب يا أبو عمر، حكيت كثير ونظّرت علينا، أعطينا الزبدة. تكرم عينك، هاي هي الخطوات العملية اللي طبقتها بنفسي وغيرت فريقي 180 درجة.
1. القائد هو القدوة: اعترف بأخطائك أولاً
ما بتقدر تطلب من فريقك يكونوا ضعفاء وصريحين إذا أنت نفسك لابس قناع “البطل الخارق الذي لا يخطئ”. لازم تكون أنت أول واحد يعترف بالخطأ.
قصة من الواقع: مرة كنت مسؤول عن دمج كود جديد أدى لبطء شديد في لوحة تحكم المستخدمين. في اجتماع الصباح اليومي (Daily Stand-up)، بدل ما أرمي اللوم على النظام أو أي شي ثاني، وقفت وحكيت: “يا جماعة، أنا بعتذر. الكود اللي دمجته مبارح هو سبب المشكلة، ما انتبهت لتأثيره على أداء قاعدة البيانات. أنا المسؤول وراح أشتغل اليوم على حلها. أي حدا عنده اقتراح يساعدني؟”
في هذيك اللحظة، حسيت نظرات الفريق تغيرت. ما كانت نظرات لوم، كانت نظرات احترام. ومن يومها، صار أسهل على أي حدا في الفريق يحكي “أنا غلطت”.
2. استقبل الأسئلة بفضول، وليس بحكم
لما حدا يسأل سؤال، حتى لو كان بسيط جداً، إياك ثم إياك تجاوب بطريقة فيها استعلاء أو تلميح بأنه سؤال “بديهي”.
- لا تقل: “طبعاً لازم نعمل هيك، هاي أساسيات!”
- بل قل: “هذا سؤال ممتاز. خلينا نوضح هاي النقطة للجميع لأنها مهمة جداً…”
شجع الأسئلة “الغبية”. أنا دايماً بحكي لفريقي: “ما في سؤال غبي، في بس فرصة ضايعة للتعلم”. لما تشكر الشخص على سؤاله، أنت بتشجع 10 غيره كانوا خايفين يسألوا.
3. أسس لعملية “تشريح الأخطاء بدون لوم” (Blameless Postmortems)
هاي من أقوى الأدوات. لما تصير كارثة (سيرفر يوقع، بيانات تضيع…)، بنعمل اجتماع مش عشان نلاقي “كبش فداء”، بس عشان نفهم شو اللي صار بالضبط ونتعلم منه. هيكلية الاجتماع بتكون كالتالي:
- الجدول الزمني للأحداث (Timeline): شو صار ومتى صار، بالدقيقة والثانية.
- التأثير (Impact): مين اتأثر وكيف؟ (مثال: 50% من المستخدمين ما قدروا يسجلوا دخول لمدة 15 دقيقة).
- الأسباب الجذرية (Root Causes): هون بنستخدم تقنية اسمها “لماذا الخمسة” (5 Whys). بنضل نسأل “ليش؟” لحد ما نوصل للسبب الجذري الحقيقي.
- الإجراءات التصحيحية (Action Items): شو هي الخطوات المحددة اللي راح نعملها عشان نمنع هاي المشكلة من الحدوث مرة ثانية؟ كل إجراء لازم يكون له مسؤول وتاريخ إنجاز.
التركيز دائماً على “العملية” و”النظام”، مش على “الشخص”. بدل ما نقول “خليل نسى يضيف test”، بنقول “عمليتنا الحالية لمراجعة الكود لا تضمن وجود تغطية اختبار كافية للحالات الحرجة”.
4. السلامة النفسية في عالم الكود: مثال عملي
خلينا نرجع لمثال مراجعة الكود (Code Review). لنفترض أن مبرمجاً مبتدئاً (Junior) يراجع كوداً لمبرمج خبير (Senior) ولاحظ شيئاً قد يكون خاطئاً.
في بيئة تفتقر للسلامة النفسية: المبرمج المبتدئ سيتجاهل الأمر خوفاً من إحراج الخبير أو الظهور بمظهر الغبي.
في بيئة تتمتع بالسلامة النفسية: المبرمج المبتدئ سيشعر بالراحة لكتابة تعليق بنّاء. الطريقة مهمة جداً:
// تعليق سيء (يخلق عداوة):
// "هذا الكود سيء جداً وبطيء. لا تستخدم استعلامات قاعدة البيانات داخل حلقة تكرار!"
// تعليق جيد (يبني سلامة نفسية):
/*
مرحباً يا كبير، يعطيك العافية على الشغل الرائع.
عندي سؤال بسيط بخصوص هذه الجزئية:
`users.forEach(user => { await db.query('UPDATE ...', user.id); });`
هل فكرنا في سيناريو لو كانت مصفوفة `users` تحتوي على آلاف المستخدمين؟
أعتقد أن تنفيذ استعلام منفصل لكل مستخدم قد يضع ضغطاً كبيراً على قاعدة البيانات.
ما رأيك لو استكشفنا طريقة لتجميع التحديثات في استعلام واحد أو transaction واحد؟
مثلاً، ممكن نستخدم `UPDATE ... WHERE id IN (...)`.
مجرد فكرة، وقد أكون مخطئاً أو هناك سبب معين لهذا التصميم لم أفهمه. أحب أن أسمع رأيك.
*/
لاحظ الفرق: التعليق الثاني يظهر الاحترام، يطرح المشكلة كسؤال، يقترح حلاً، ويعترف باحتمالية أنه قد يكون مخطئاً. هذا يفتح باب النقاش بدلاً من إغلاقه.
الخلاصة يا جماعة الخير 🚀
السلامة النفسية مش مجرد شعور “لطيف” في مكان العمل. إنها المحرك الأساسي للابتكار والجودة والأداء العالي. إنها الفرق بين فريق ينتج حلولاً عادية وفريق يغير قواعد اللعبة.
بناء هذه الثقافة يتطلب وقتاً وجهداً، وهو ليس مسؤولية المدير وحده، بل مسؤولية كل فرد في الفريق. لكن القائد هو من يجب أن يزرع البذرة الأولى من خلال كونه القدوة.
نصيحة أخيرة من أبو عمر: ابدأ بنفسك اليوم. في اجتماعك القادم، كن أول من يطرح سؤالاً “جريئاً”. في مراجعة الكود القادمة، كن أول من يعطي ملاحظة بناءة ولطيفة. كن أنت الشخص الذي كنت تتمنى وجوده في فريقك عندما كنت مبتدئاً. ستتفاجأ من الأثر الذي يمكن أن تحدثه خطوة صغيرة واحدة.
