من “مش عارف” إلى “يلا نتعلم”: كيف أنقذت السلامة النفسية فريقي من كارثة صامتة؟

بتذكرها زي كأنها مبارح. كانت الساعة حوالي 10 بالليل، قبل يوم واحد من إطلاق تحديث كبير لتطبيقنا. فجأة، انفجرت قنوات السلاك (Slack) برسائل الخطأ من نظام المراقبة. في “بَغْ” (Bug) خطير و”عويص” ظهر من العدم، وكان يضرب في قلب النظام المالي للتطبيق. الكارثة كانت وشيكة.

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

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

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

ما هي “السلامة النفسية” في الشغل؟ (مش مجرد إنك تكون لطيف)

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

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

• تسأل سؤال “غبي” بدون ما حدا يضحك عليك.
• تعترف بخطأ ارتكبته بدون ما تخاف من اللوم أو العقاب.
• تقترح فكرة مجنونة بدون ما حدا يتهمك بالسطحية.
• تنتقد فكرة (حتى لو كانت فكرة المدير) بشكل بنّاء بدون ما يعتبروك “مشاغب”.

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

جحيم الأخطاء الصامتة: أعراض غياب السلامة النفسية

قبل ما نبدأ رحلة التغيير، كان فريقنا يعاني من أعراض واضحة لغياب السلامة النفسية. لو شفت هاي الأعراض في فريقك، اعتبره ضوء أحمر.

صمت “المش عارف”

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

ثقافة اللوم (The Blame Game)

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

اجتماعات المونولوج (المدير يحكي والكل يسمع)

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

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

الفريق كان متمسك بالتقنيات القديمة اللي “شغالة ومجربة”. أي اقتراح لاستخدام مكتبة جديدة، أو تجربة أسلوب مختلف في كتابة الكود (Architecture)، كان يقابل بمقاومة شديدة. مش لأن الأفكار الجديدة سيئة، بل لأن الفشل في تجربتها كان يعني اللوم والعقاب. شعار “الشي اللي شغال لا تلمسه” تحول من حكمة إلى سجن للخوف.

كيف بنينا جسور الثقة؟ خطوات عملية لخلق السلامة النفسية

التغيير ما صار بيوم وليلة. كان عملية بناء يومية، حجر فوق حجر. وهاي هي الخطوات العملية اللي اتبعناها وغيرت كل شيء.

أولاً: القدوة تبدأ من القائد (Lead by Example)

ما بنفع أطلب من فريقي يكونوا صريحين وضعاف وأنا لابس قناع “البطل الخارق” اللي ما بغلط. كان لازم أكون أول واحد يكسر حاجز الخوف. صرت أتعمد في الاجتماعات أقول جمل زي:

“والله يا جماعة، أنا قرأت عن تقنية X، بس بصراحة مش فاهمها منيح. مين عنده فكرة عنها أو ممكن يشرحلنا إياها؟”

والأهم، لما كنت أرتكب خطأ، كنت أعترف فيه بشكل علني وواضح في القناة العامة للفريق:

“يا جماعة، البَغْ اللي ظهر مبارح في نظام الإشعارات، طلع سببه كود أنا كتبته الأسبوع الماضي. أنا آسف على المشكلة اللي سببها، وهاي هي الدروس اللي تعلمتها…”

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

ثانياً: غيّر السؤال من “من؟” إلى “كيف؟”

هاي كانت قاعدة ذهبية. لما تحدث مشكلة، منعنا تمامًا سؤال “مين السبب؟”. بدلًا من ذلك، صار سؤالنا الدائم هو:

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

تبنينا مفهوم اسمه “Blameless Postmortems” (تحليل ما بعد الحادثة بدون لوم). بعد كل مشكلة كبيرة، بنعمل اجتماع مش عشان نجلد حدا، بل عشان نحلل تسلسل الأحداث اللي أدت للمشكلة ونطلع بتوصيات عملية لتحسين النظام. التركيز صار على “النظام” مش على “الشخص”.

ثالثاً: شجع الأسئلة “الغبية”

أعلنتها قاعدة رسمية في الفريق: “لا يوجد سؤال غبي، يوجد فقط سؤال لم يُسأل”. وصرت أكافئ اللي بيسألوا. لما مبرمج مبتدئ يسأل سؤال أساسي في اجتماع، كنت أوقفه وأقول:

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

هذا التشجيع البسيط بخلي الناس تحس إن فضولها موضع تقدير، مش مصدر إحراج.

رابعاً: الكود ريفيو (Code Review) كأداة بناء لا هدم

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

التعليق السيئ (يهدم الثقة):

// هذا الأسلوب خاطئ تمامًا. لا تستخدم for loop هنا، استخدم map.
// This is completely wrong. Don't use a for loop here, use map.

التعليق الجيد (يبني الثقة):

// أرى أنك استخدمت for loop هنا. فكرة جيدة!
// عندي سؤال: هل فكرت في استخدام array.map()؟ قد يجعل الكود أقصر وأسهل في القراءة في هذه الحالة.
// ما رأيك في تجربة شيء مثل: const newArray = oldArray.map(item => ...);
// يمكننا أن نتحدث في الموضوع أكثر لو أحببت!

// I see you've used a for loop here. Good thinking!
// I have a question: have you considered using array.map()? It might make the code a bit shorter and more readable in this case.
// What do you think about trying something like: const newArray = oldArray.map(item => ...);
// Happy to jump on a call to discuss it more if you like!

الأسلوب الثاني فضولي، محترم، ويفتح باب الحوار بدل من إغلاقه. يعلّم الشخص بدلاً من أن يهاجمه.

النتائج: من فريق خائف إلى خلية نحل مبدعة

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

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

خلاصة أبو عمر 💡

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

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

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