بتذكر منيح، قبل سنين طويلة، كنا في شركة ناشئة والضغط علينا “للسما”. كان معنا شب جديد، خلينا نسميه “سامر”، شب ذكي ومليان حماس. في يوم من الأيام، وبغلطة بسيطة وغير مقصودة، سامر عمل push لكود فيه bug صغير أوقف واحد من السيرفرات الرئيسية لدقايق معدودة. ما بنسى نظرة المدير وقتها، وكيف صرخ عليه قدام كل الفريق: “كيف بتعمل هيك! مش شايف شغلك؟!”.
من يومها، سامر انطفى. صار يخاف يكتب أي سطر كود بدون ما يسأل عشرين مرة، صار يتجنب أي مهمة فيها تحدي، وإنتاجيته نزلت في الحضيض. بعد كم شهر، ترك الشركة. أما احنا اللي ضلينا، فتعلمنا درس قاسي: “اوعك تغلط، وإذا غلطت، اوعك حدا يعرف”. صارت أخطاؤنا تُدفن سرًا، كل واحد فينا صار يشتغل في جزيرة معزولة، والابتكار مات على عتبة الخوف. هاي الحادثة البسيطة كانت شرارة خلتني أفكر لسنوات: هل هذه هي الطريقة الوحيدة للشغل؟ هل لازم نعيش في جحيم الخوف من الفشل عشان نكون “محترفين”؟
ما هي “السلامة النفسية” وليش هي مهمة إلنا كمبرمجين؟
بعد سنين من الخبرة والتنقل بين الفرق والشركات، اكتشفت مصطلح غيّر نظرتي لكل إشي: السلامة النفسية (Psychological Safety). المصطلح هاد صاغته الباحثة إيمي إدموندسون من جامعة هارفارد، وببساطة شديدة، معناه إنه أعضاء الفريق يشعروا بالأمان لطرح الأسئلة، الاعتراف بالأخطاء، اقتراح أفكار جديدة، وتحدي الوضع الراهن بدون ما يخافوا من العقاب أو الإحراج.
يمكن حدا يحكي: “شو هالحكي الفاضي يا أبو عمر، إحنا في شغل مش في حضانة!”. وهون بحكيله، “طوّل بالك عليّ”. السلامة النفسية مش مجرد “كلام لطيف”، هي أساس الفرق عالية الأداء، خصوصًا في مجالنا التقني اللي التغيير فيه هو الثابت الوحيد.
السلامة النفسية لا تعني غياب المساءلة أو خفض معايير الجودة، بل تعني خلق بيئة ترتفع فيها المعايير لأن الجميع يساهم في كشف الأخطاء وتحسين العمل بدون خوف.
الخوف يقتل الكود: كيف تدمر ثقافة اللوم فريقك؟
لما تغيب السلامة النفسية، بتسيطر ثقافة اللوم والخوف، وهاد إله آثار كارثية على أي فريق برمجي:
- موت الابتكار: مين رح يجرب مكتبة جديدة أو يقترح إعادة هيكلة (Refactoring) لجزء معقّد من الكود إذا كان بيعرف إنه لو فشل رح يكون “كبش الفداء”؟
- تأخر اكتشاف الأخطاء: بدل ما المبرمج يحكي “يا جماعة، أنا مش متأكد من هاد الجزء، حدا يلقي نظرة؟”، رح يسكت ويدعي إنه الكود يشتغل، وهيك Bug بسيط ممكن يوصل للـ Production ويسبب كارثة.
- اجتماعات صامتة: بتصير اجتماعات التخطيط ومراجعة التصاميم عبارة عن مسرحية، الكل بهز راسه بالموافقة على كلام المدير أو القائد التقني، حتى لو شايفين إنه القرار غلط، لأنه ما حدا بده يكون “الشخص المزعج” اللي دايماً بعترض.
- هجرة العقول: المبرمجين الشاطرين ما رح يتحملوا بيئة سامة. رح يلاقوا مكان تاني يقدّر عقولهم ويحترم أفكارهم، ورح يضل عندك الناس اللي تعلمت كيف “تلعبها صح” وتتجنب المسؤولية.
من اللوم إلى التعلم: خطوات عملية لبناء ثقافة السلامة النفسية
طيب يا أبو عمر، حكيتلنا عن المشكلة، وين الحل؟ الحل ببدأ بتغيير العقلية وتطبيق ممارسات عملية. بناء هاي الثقافة مش مسؤولية المدير لحاله، هي مسؤولية كل فرد في الفريق، بس القيادة عليها الدور الأكبر في تمهيد الطريق.
1. كقائد: اعترف بأخطائك أولاً
أقوى إشي ممكن تعمله كقائد فريق هو إنك توقف قدام فريقك وتحكي: “يا جماعة، أنا غلطت”. لما تعترف إنك قدرت الوقت بشكل خاطئ، أو إنك اخترت تقنية ما كانت الأنسب، إنت بتبعت رسالة واضحة للجميع: “الخطأ جزء من التعلم، وحتى أنا بغلط. المهم كيف نتعامل مع الخطأ”.
2. حوّل “تحقيقات الفشل” إلى “جلسات تعلم” (Blameless Postmortems)
لما تصير مشكلة (سيرفر يوقع، بيانات تضيع)، بدل ما يكون السؤال الأول “مين عمل هيك؟”، لازم السؤال يكون “شو اللي صار؟ وكيف نمنع إنه يتكرر؟”. هاي هي فلسفة الـ Blameless Postmortems.
تخيل السيناريو التالي بعد ما وقع سيرفر الإنتاج:
- ثقافة اللوم: “سامر هو اللي عمل deploy للكود الأخير. لازم نمنعه من الوصول للـ production”. (النتيجة: سامر صار يخاف، والفريق تعلم يخفي أخطاءه، والمشكلة الحقيقية في النظام ما انحلت).
- ثقافة السلامة النفسية: “تمام يا فريق، خلينا نعمل جلسة نفهم فيها شو صار.
- التسلسل الزمني: شو صار ومتى؟
- السبب الجذري (Root Cause): اكتشفنا إن الكود مر من كل الاختبارات الآلية، بس كان فيه مشكلة توافقية مع مكتبة تانية ما غطتها الاختبارات.
- الدروس المستفادة: الخطأ مش خطأ سامر، الخطأ هو وجود “نقطة عمياء” في نظام الاختبارات تبعنا.
- الإجراءات التصحيحية: رح نضيف خطوة جديدة في الـ CI/CD pipeline تعمل فحص للتوافقية قبل الـ deploy. شكرًا يا سامر، لأنك ساعدتنا نكتشف هاي الثغرة في نظامنا”.
(النتيجة: سامر شعر بالتقدير، والفريق كله تعلم، والنظام صار أقوى).
3. اجعل مراجعات الكود (Code Reviews) حوارًا بناءً
الـ Code Review ممكن يكون ساحة معركة أو واحة للتعلم. بدل ما تكتب تعليق مثل “هذا الكود سيء”، جرب أسلوب ثاني:
// بدل ما تحكي: "ليش ما استخدمت map؟ هاد الكود بطيء"
// Try this instead: "What's the reasoning behind using a for loop here?"
// You could say: "This is a great opportunity to use the `map` function.
// It could make the code more concise and potentially more readable. What do you think?"
// Original (less helpful) comment:
// "This is complex and hard to read."
// Better, more constructive comment:
// "I had to read this function a few times to understand it.
// Maybe we can break it down into smaller, more focused helper functions?
// For example, we could extract the validation logic into its own function."
استخدم عبارات مثل “ما رأيك لو…؟”، “هل فكرت في…؟”، “أنا تعلمت شغلة جديدة من طريقتك، بس شو رأيك لو جربنا هيك عشان نحسن الأداء؟”. الهدف هو تحسين الكود، مش إثبات مين “أذكى”.
4. شجع الفضول واحتفل بالأسئلة
في اجتماعاتك، اطلب الآراء بشكل مباشر من الناس الهاديين في الفريق. “يا فلان، ما سمعنا رأيك، شو شايف؟ في إشي أنا مش منتبهله؟”. ولما حدا يسأل سؤال “ساذج” أو “بسيط”، اشكره عليه علنًا! لأنك لو شكرته، فأنت بتشجع عشرة غيره كانوا خايفين يسألوا نفس السؤال.
الخلاصة: السلامة النفسية ليست رفاهية، بل ضرورة للبقاء
بناء ثقافة السلامة النفسية مش مشروع إله بداية ونهاية، هي عملية مستمرة وزراعة يومية، “شوي شوي” بتكبر وبتجيب ثمارها. هي التحول من عقلية “إخفاء الأخطاء” إلى عقلية “الاحتفاء بالدروس المستفادة منها”.
في عالمنا اللي بيعتمد على الابتكار والسرعة، الفريق اللي بخاف من الخطأ هو فريق محكوم عليه بالتجمد في مكانه. أما الفريق اللي بيتعلم كيف يفشل بسرعة، ويتعلم بسرعة، ويشارك المعرفة بسرعة، هو الفريق اللي رح يبني المستقبل.
نصيحتي الأخيرة إلك: ابدأ بنفسك. في المرة الجاي اللي زميلك يرتكب فيها خطأ، بدل ما توجهله إصبع الاتهام، مد إيدك وساعده. اسأله: “كيف بقدر أساعد؟ شو تعلمنا من هالتجربة؟”. هيك بنبني فرق ما بتخاف من الفشل، بل بتستخدمه كوقود للنجاح. 💪
