بتذكرها زي كأنه امبارح. كنا في نص مشروع ضخم، “deadline” بيقرب والضغط على الجميع. كان في شاب جديد بالفريق، اسمه “سامر”، شب شاطر و”قد حاله” بس هادي شوي. في يوم، وقفت خدمة أساسية في نظام التجريب (Staging Environment) بالكامل. الدنيا قامت وقعدت، والمدير فوق راسنا بيسأل: “شو القصة يا جماعة؟ مين آخر واحد اشتغل على السيرفر؟”.
ساد صمت رهيب. الكل صار يطلع ببعضه، وبدأت رحلة “صيد الساحرات”. بعد ساعات من التوتر والبحث، اكتشفنا إنه سامر كان بيجرب “script” معين وارتكب خطأ بسيط، لكنه خطأ أدى لكارثة. لما سألته على جنب: “ليش ما حكيت يا سامر أول ما صارت المشكلة؟ كان حليناها بدقايق”. رد عليّ بصوت خافت وعيونه في الأرض: “خفت… خفت تفكروني مش شاطر أو أتعاقب”.
هذيك اللحظة كانت صفعة إلي. أدركت إن المشكلة مش في خطأ سامر، المشكلة فينا احنا، في “ثقافة” الفريق اللي بتخلي المبرمج يخاف يعترف بغلطه أو يقول “ما بعرف”. من يومها، قررت إن أكبر مشروع لازم أشتغل عليه مش كود، بل بناء بيئة آمنة للجميع. بيئة تسمح للكل يغلط ويتعلم ويقول “ما بعرف” بصوت عالي. وهون بدأت رحلتنا مع “الأمان النفسي”.
ما هو الأمان النفسي؟ (ولماذا هو ليس مجرد ‘كلام حلو’؟)
الأمان النفسي (Psychological Safety) ببساطة هو إيمان جماعي داخل الفريق بأن هذا المكان آمن للمجازفة على المستوى الشخصي. يعني بتقدر تطرح فكرة غريبة، تسأل سؤال “غبي”، تعترف بخطأ، أو تنتقد فكرة المدير بلباقة، بدون ما تخاف من الإحراج أو العقاب أو تهميشك.
وهون لازم نوضح شغلة مهمة، الأمان النفسي مش معناه إنه “الكل حبايب” وما في نقاشات حادة. بالعكس تماماً! هو اللي بيسمح بالنقاشات الحادة والمثمرة، لأنه الكل عارف إنه النقاش ضد “الفكرة” مش ضد “الشخص”. هو مش معناه التساهل مع الأداء السيء، بل هو اللي بيسمح بمناقشة الأداء السيء بصراحة وشفافية بهدف التطوير مش التوبيخ.
باختصار، الأمان النفسي هو التربة الخصبة اللي بتنمو فيها الثقة والإبداع وحل المشاكل بسرعة. بدونه، فريقك بكون مجرد مجموعة أفراد بيشتغلوا جنب بعض، وكل واحد خايف من اللي جنبه.
علامات الخطر: كيف تعرف أن فريقك يفتقر للأمان النفسي؟
قبل ما نبدأ بالحل، لازم تعرف تشخص المشكلة. فريقك ممكن يكون بيعاني من نقص الأمان النفسي إذا لاحظت هاي العلامات:
- صمت القبور في الاجتماعات: تطرح سؤال “حدا عنده أي سؤال؟” والرد هو صوت المكيفات فقط. لا أحد يجرؤ على السؤال خوفاً من الظهور بمظهر الجاهل.
- الأخطاء المدفونة: لا أحد يبلغ عن خطأ صغير إلا بعد أن يتحول إلى كارثة لا يمكن إخفاؤها. الكل بيمشي على مبدأ “الله يستر وتعدي”.
- ثقافة اللوم (Blame Culture): عند حدوث مشكلة، أول سؤال يكون “مين عمل هيك؟” بدل “كيف صارت المشكلة وكيف نمنعها مستقبلاً؟”. مراجعات الكود (Code Reviews) تتحول لساحة معركة شخصية.
- المعرفة كنز شخصي: المبرمجون الخبراء يحتفظون بالمعلومات لأنفسهم ولا يشاركونها، لأن المعرفة تعطيهم قوة وأمان وظيفي (على الأقل في نظرهم).
- صمت المبتدئين: المبرمجون الجدد أو الصغار في الفريق لا يشاركون بأي رأي، ويوافقون على كل شيء خوفاً من نقد الكبار.
إذا شفت هاي العلامات في فريقك، فلا تقلق. أنت لست وحدك، والخبر الجيد أن هذا الأمر يمكن إصلاحه.
رحلة التحول: خطوات عملية لبناء ثقافة الأمان النفسي
بناء الثقافة مش كبسة زر، هو مجهود يومي ومستمر. هاي هي الخطوات العملية اللي اتبعناها في فريقنا، واللي أثبتت فعاليتها على أرض الواقع.
الخطوة الأولى: القدوة الحسنة من القيادة (Lead by Example)
كقائد للفريق، أنت القدوة. فريقك يراقب كل حركة وكل كلمة. إذا أردتهم أن يكونوا ضعفاء وصادقين، يجب أن تكون أنت أولهم.
- اعترف بجهلك أولاً: كنت أول واحد بقول في الاجتماع “يا جماعة، هاي الشغلة جديدة عليّ، ما عندي فكرة واضحة. مين بيقدر يشرحلنا أكثر؟”. هذا التصرف البسيط يعطي إشارة للجميع بأن “عدم المعرفة” ليس عيباً.
- شارك أخطاءك: كنت أتعمد مشاركة أخطاء ارتكبتها في الماضي وكيف تعلمت منها. “بتذكروا مرة لما عملت deploy لكود فيه bug ووقف الموقع؟ تعلمت يومها إنه لازم…” هذا يكسر حاجز الخوف من الفشل.
الخطوة الثانية: إعادة صياغة الخطأ والفشل (Reframe Failure)
يجب أن نغير نظرتنا للخطأ. الخطأ في البرمجة ليس فشلاً شخصياً، بل هو فرصة للتعلم وتحسين النظام.
- طبّق قاعدة “Post-mortem بلا لوم” (Blameless Post-mortems): بعد كل مشكلة كبيرة، كنا نعقد اجتماعاً ليس لهدف تحديد المخطئ، بل للإجابة على هذه الأسئلة:
- ماذا حدث بالضبط (التسلسل الزمني)؟
- ماذا كانت التأثيرات؟
- ما هي الإجراءات التي يمكننا اتخاذها لمنع حدوث هذا النوع من المشاكل مرة أخرى؟ (مثال: تحسين الاختبارات، إضافة تنبيهات، تحديث التوثيق).
- غير لغة الحوار: بدلًا من “ليش عملت هيك؟”، اسأل “شو اللي خلانا نوصل لهي النقطة؟ كيف ممكن نحسن العملية عشان ما حدا يوقع بنفس الغلط؟”.
الخطوة الثالثة: تشجيع الفضول وتحويل مراجعات الكود (Code Reviews)
مراجعات الكود هي من أكثر الأماكن التي يمكن أن تُبنى فيها ثقافة الأمان النفسي أو تُهدم.
بدلاً من التعليقات الجافة والهجومية، حوّلناها إلى حوار تعليمي. انظر الفرق:
التعليق السيء (يدمر الأمان النفسي):
// هذا الكود بطيء جداً وغير فعال. استخدم Hash Map.
التعليق الجيد (يبني الأمان النفسي):
// فكرة حلوة! عندي فضول أعرف أكثر عن هذا الحل.
// فكرت في موضوع الأداء لو كان عنا عدد كبير من البيانات، هل ممكن يكون استخدام Hash Map أسرع لعمليات البحث؟ شو رأيك؟
// مجرد فكرة للنقاش :)
التعليق الثاني يفتح باب النقاش، يعترف بجهد المبرمج، ويقدم الاقتراح كفكرة وليس كأمر، مما يشجع على الحوار والتعلم المتبادل.
الخطوة الرابعة: الاستماع الفعال والتقدير
عندما يجرؤ شخص ما (خاصة المبتدئ) على التحدث، فإن رد فعلك يحدد ما إذا كان سيتحدث مرة أخرى أم لا.
- استمع بتركيز: لا تقاطعه. دعه يكمل فكرته حتى لو كانت خاطئة.
- اشكره على المشاركة: قل بوضوح “شكراً لمشاركتك يا سامر، هاي نقطة مهمة لازم نفكر فيها”. هذا يعزز السلوك الإيجابي.
- افصل بين الفكرة والشخص: إذا كانت الفكرة غير قابلة للتطبيق، انقد الفكرة وليس الشخص. “أنا فاهم وجهة نظرك، لكن ممكن نواجه مشكلة (كذا وكذا) مع هذا الحل. شو رأيك لو فكرنا في بديل يعالج هاي النقطة؟”.
النتائج على أرض الواقع: شو اللي تغيّر؟
بعد تطبيق هذه المبادئ بشكل مستمر، التغيير لم يكن فورياً، ولكنه كان عميقاً ومستداماً. ما الذي تغير؟
- سرعة اكتشاف الأخطاء: أصبح المبرمجون يبلغون عن أخطائهم فور حدوثها في قناة السلاك الخاصة بالفريق. أصبحنا نحل المشكلة في 5 دقائق بدل 5 ساعات.
- ابتكار حقيقي: صار الكل يطرح أفكار “مجنونة” في جلسات العصف الذهني، ومن هذه الأفكار خرجت أفضل الحلول لمشاكل معقدة.
- جودة الكود ارتفعت: مراجعات الكود أصبحت جلسات تعليمية جماعية، والجميع يتعلم من خبرات بعضهم.
- معنويات الفريق في السماء: انخفض معدل دوران الموظفين، وأصبح الفريق مكاناً يرغب الجميع في الانضمام إليه. قصة سامر، الشاب الخائف، تحول ليصبح من أكثر المبرمجين ثقة ومبادرة في الفريق.
خلاصة أبو عمر ونصيحة من القلب 👨💻
يا صديقي المبرمج، ويا صديقتي قائدة الفريق، الأمان النفسي ليس رفاهية أو “HR talk”. إنه ضرورة قصوى لبناء فرق تقنية قوية، مبدعة، وقادرة على مواجهة التحديات. هو الاستثمار الأذكى الذي يمكنك القيام به في فريقك.
الخوف يقتل الإبداع، يشجع على الصمت، ويحول الأخطاء الصغيرة إلى كوارث. أما الثقة، فهي تطلق العنان للقدرات الكاملة لكل فرد في فريقك.
نصيحتي العملية لك اليوم: ابدأ بنفسك. لا تنتظر الإذن من مديرك. في اجتماعك القادم، كن أول من يطرح سؤالاً “غبياً”. كن أول من يعترف بأنه لا يعرف إجابة شيء ما. كن أول من يشكر زميلاً على فكرة حتى لو لم تكن متفقاً معها. قد تكون هذه الشرارة الصغيرة هي كل ما يحتاجه فريقك ليبدأ رحلة التحول.
