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

بتذكرها زي كأنها مبارح. كنت شغال في شركة قبل سنوات، وكان عنا “اجتماع الكارثة” الأسبوعي. هيك كنا نسميه بيننا. هو بالأساس اجتماع لمناقشة المشاكل التقنية (Post-mortem)، لكنه كان أشبه بمحكمة تفتيش. المدير، الله يسهل عليه، كان يبدأ الاجتماع بسؤال واحد: “مين اللي عملها؟”.

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

ما هي “السلامة النفسية” (Psychological Safety)؟ وليش هي أهم إشي في فريقك؟

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

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

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

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

إذا شفت هاي العلامات في فريقك، اعرف إنه في عندك مشكلة حقيقية في السلامة النفسية:

• صمت القبور في الاجتماعات: الكل ساكت، ولما المدير يسأل “في حدا عنده أسئلة؟”، بتسمع صوت صرصور الحقل. لا أحد يجرؤ على تحدي فكرة أو طرح سؤال.
• لعبة إلقاء اللوم (The Blame Game): أول ما تصير مشكلة، أول سؤال بينطرح هو “مين السبب؟” بدل “شو صار وكيف نصلحه ونتعلم منه؟”.
• تأخر الإبلاغ عن المشاكل: المبرمج بيكتشف bug صغير، بس بخاف يحكي، فبحاول يصلحه لحاله بالسر. بعد يومين، البج الصغير بكون كبر وصار وحش كاسر ضرب الـ production server.
• الخوف من طرح الأسئلة “الغبية”: أعضاء الفريق بفضلوا يقضوا ساعات يبحثوا عن معلومة بسيطة على جوجل بدل ما يسألوا زميلهم الخبير ويوفروا على حالهم وقت وجهد.
• غياب النقد البنّاء: في مراجعات الكود (Code Reviews)، التعليقات بتكون سطحية جداً (“LGTM” – Looks Good To Me) خوفاً من جرح مشاعر الزميل أو الدخول في نقاش تقني حقيقي.

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

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

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

ما بتقدر تطلب من فريقك يكون صريح وشفاف وأنت أول واحد بتخبي أخطاءك. لازم تكون أنت أول واحد يعترف بالخطأ. بتذكر مرة كنت مسؤول عن عملية deploy لتحديث مهم، ومن العجلة نسيت أحدث متغير بيئة (environment variable) مهم. النتيجة؟ الموقع وقع لمدة 10 دقائق.

أول إشي عملته، دخلت على قناة الفريق على Slack وكتبت:

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

هذا الاعتراف البسيط كان رسالة قوية للفريق: “أنا كقائد أخطئ، وهذا طبيعي. المهم هو كيف نتعامل مع الخطأ بسرعة ونتعلم منه”.

الخطوة الثانية: غيّر نظرتك للخطأ (Frame Work as a Learning Problem)

بدل ما تسأل “مين اللي عمل هيك؟”، اسأل “شو اللي صار؟ وكيف نظامنا سمح لهيك خطأ يصير؟”. هذا هو جوهر ما يسمى بـ “Blameless Post-mortems” (اجتماعات تحليل الأسباب بدون إلقاء لوم).

نصيحة عملية: في هاي الاجتماعات، ركز على تسلسل الأحداث، الأدوات المستخدمة، والعمليات المتبعة. الهدف هو تحسين النظام، مش معاقبة الفرد. مثال: لو في bug سببه Null Pointer Exception، التحليل لازم يكون هيك:

• ليش الـ Code Review ما لقط هاي المشكلة؟ هل محتاجين checklist أو تدريب أفضل؟
• ليش الـ Unit Tests ما غطت هاي الحالة؟ هل لازم نرفع معايير الـ Code Coverage؟
• هل لغة البرمجة أو الـ framework اللي بنستخدمه فيهم طرق أفضل للتعامل مع الـ Nulls (مثل Optional في Java أو Nullable Types في C#/Kotlin)؟

الخطوة الثالثة: شجّع الفضول والأسئلة (Model Curiosity)

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

نصيحة عملية: اعمل جلسات أسبوعية اسمها “ما في سؤال غبي” (No Stupid Questions). نص ساعة مخصصة لأي حدا يسأل أي سؤال تقني أو غير تقني بدون أي خوف من الحكم عليه. رح تتفاجأ من كمية المعرفة اللي بتنتشر في الفريق بسبب هاي الجلسات.

السلامة النفسية في الكود: مثال عملي

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

// Before: Complex and hard to read
public void processUserData(User user) {
    if (user != null) {
        if (user.getProfile() != null) {
            if (user.getProfile().getAddress() != null) {
                if (user.getProfile().getAddress().getCity() != null) {
                    System.out.println("User city: " + user.getProfile().getAddress().getCity());
                } else {
                    System.out.println("City not available");
                }
            } else {
                System.out.println("Address not available");
            }
        } else {
            System.out.println("Profile not available");
        }
    } else {
        System.out.println("User not available");
    }
}

مبرمج مبتدئ في فريق يفتقر للسلامة النفسية رح يشوف هالكود ويسكت. رح يخاف يقترح تعديل على كود “الخبير”.

لكن في فريق يتمتع بالسلامة النفسية، نفس المبرمج رح يشعر بالراحة إنه يفتح Pull Request ويقترح تعديل بسيط، مع تعليق محترم مثل:

مرحباً يا كبير، فكرت في طريقة ممكن نبسط فيها التحقق من الـ nulls باستخدام Optional، شو رأيك؟ هيك الكود بصير أسهل للقراءة والصيانة.

والنتيجة ممكن تكون كود أنظف وأفضل مثل هيك:

// After: Clean, readable, and safer
public void processUserData(User user) {
    String city = Optional.ofNullable(user)
                          .map(User::getProfile)
                          .map(Profile::getAddress)
                          .map(Address::getCity)
                          .orElse("Not available");
                          
    System.out.println("User city: " + city);
}

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

الخلاصة: من النجاة إلى الازدهار 🚀

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

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