السلام عليكم يا جماعة الخير،
أنا أبو عمر، وبدي أحكيلكم قصة صارت معي قبل كم سنة، قصة علّمتني درس ما بنساه طول ما أنا بكتب كود. كنّا قاعدين في اجتماع مراجعة كود (Code Review) لمشروع مهم. معنا شب جديد، خلونا نسميه “سامر”، شب شاطر وعنده حماس، بس لسا خبرته على قدّه. عرض سامر الـ Pull Request تاعه، وكان فيه خطأ منطقي بسيط، من النوع اللي كلنا عملناه في بداياتنا.
فجأة، واحد من المبرمجين الكبار (Senior Developers) مسك المايك وبدأ ي “يشرح” الخطأ بطريقة… خلونا نقول “قاسية”. صوته كان عالي، ونبرته فيها اتهام، وكأنه بقول “كيف بتغلط هيك غلطة؟”. شفت سامر وجهه صار ألوان، انكمش على حاله وسكت. باقي الاجتماع ما فتح تمه بكلمة. بعدها بأسبوع، سامر صار ما يشارك، ما يسأل، وإذا بده يرفع أي كود بياخذ يومين وهو خايف ومتردد.
هذاك اليوم، أدركت إن المشكلة مش في كود سامر، المشكلة في “الجو” اللي إحنا فيه. النقاشات التقنية كانت ساحة معركة، الكل بده يثبت إنه الأذكى، والخوف من الخطأ كان قاتل للإبداع. من يومها، أخذت على عاتقي تغيير هذا الوضع. اليوم، بدي أشارككم كيف حوّلنا فرقنا من جحيم الخوف إلى بيئة عمل صحية ومنتجة، من خلال مفهوم اسمه “الأمان النفسي”.
ما هو ‘الأمان النفسي’ يا جماعة؟ وليش هو مهم؟
ببساطة، الأمان النفسي (Psychological Safety) هو إيمان كل عضو في الفريق بأنه ما راح يتعرض للعقاب أو الإهانة إذا طرح فكرة، أو سأل سؤال “غبي”، أو اعترف بخطأ، أو انتقد الوضع الحالي. هو الشعور بالراحة إنك تكون على طبيعتك، وتخاطر، وتفشل، وتتعلم بدون خوف.
ليش مهم؟ لأنه بدون أمان نفسي:
- المبرمجون المبتدئون يخافون السؤال: فيرتكبون أخطاء أكبر كان يمكن تجنبها بسؤال بسيط.
- المبرمجون الخبراء يخافون التجربة: فيظلون يستخدمون نفس الطرق القديمة خوفاً من فشل الأفكار الجديدة.
- لا أحد يجرؤ على قول “هناك مشكلة”: فتتفاقم المشاكل الصغيرة لتصبح كوارث كبيرة.
- الإبداع يموت: لأن الإبداع يتطلب المخاطرة، ولا أحد يخاطر في بيئة قمعية.
من الآخر، الفريق اللي ما فيه أمان نفسي، هو فريق “زومبيز”… بيشتغل، بس بدون روح وبدون إبداع.
من ساحة المعركة إلى مساحة التعاون: خطواتنا العملية
تغيير ثقافة فريق مش إشي بصير بيوم وليلة. بدها صبر وشغل “مرتب”. هذه هي الخطوات العملية اللي اتبعناها ونجحت معنا.
الخطوة الأولى: القدوة تبدأ من فوق (القيادة أولاً)
ما بتقدر تطلب من فريقك يكونوا شجعان وصريحين إذا كنت أنت كقائد فريق (Tech Lead) أو مدير، أول واحد “بجلدهم” على الغلط. القائد هو اللي بيحدد نبرة الحوار.
نصيحة أبو عمر: كن أول من يعترف بالخطأ. أتذكر مرة قمت بدمج كود سبب مشكلة في السيرفر الرئيسي (production). بدل ما ألف وأدور، دخلت على قناة الفريق العامة وكتبت: “يا جماعة، أنا أبو عمر، أنا اللي دمجت الكود X عن طريق الخطأ وهو اللي سبب المشكلة Y. أنا آسف جداً وبعمل حالياً على إصلاحه. هذا درس إلي إني أكون حذر أكثر في المراجعة. مين عنده أفكار تساعدنا نمنع هذا النوع من الخطأ مستقبلاً؟”.
هذه الرسالة البسيطة كان مفعولها سحري. أظهرت للجميع أن الخطأ ليس نهاية العالم، وأن التركيز يجب أن يكون على الحل والتعلم، وليس على لوم الأشخاص.
الخطوة الثانية: إعادة صياغة مراجعات الكود (من النقد إلى البناء)
مراجعة الكود (Code Review) هي أكثر مكان ممكن يظهر فيه انعدام الأمان النفسي. غيرنا قواعد اللعبة بشكل كامل.
القاعدة الذهبية: انتقد الكود، لا تنتقد المبرمج. اسأل، لا تأمر.
بدل ما نكتب تعليقات مثل:
// ليش استخدمت for loop هنا؟ هذا بطيء جداً وغير فعال. استخدم map.
// Why did you use a for loop here? This is very slow and inefficient. Use map.صرنا نكتب:
// أرى أنك استخدمت for loop هنا. هل فكرت في استخدام .map()؟ قد يكون أوضح للقراءة وأحياناً أفضل أداءً في بعض الحالات. ما رأيك؟
// I see you've used a for loop here. Have you considered using .map()? It might be more readable and sometimes more performant. What do you think?لاحظ الفرق؟ الأول هجوم واتهام بالغباء. الثاني سؤال ودعوة للنقاش. الثاني يفتح الباب للمبرمج ليشرح وجهة نظره، يمكن يكون عنده سبب وجيه لاستخدام الـ for loop! هذا الأسلوب يشجع على التعلم المتبادل.
الخطوة الثالثة: الاحتفاء بالتعلم من الأخطاء (Blameless Postmortems)
لما تصير كارثة (والكوارث بتصير في عالم البرمجة)، بدل ما نبحث عن “كبش فداء”، صرنا نعمل جلسات اسمها “تشريح الأزمة بدون لوم” (Blameless Postmortem).
الهدف من الجلسة هو الإجابة على هذه الأسئلة:
- ماذا حدث بالضبط (التسلسل الزمني)؟
- ما هو الأثر الذي ترتب على المشكلة؟
- ما هي الإجراءات التي اتخذناها لحل المشكلة؟
- الأهم: كيف يمكننا تحسين أنظمتنا وعملياتنا لمنع حدوث هذا النوع من المشاكل مرة أخرى؟
التركيز دائماً على “العملية” و”النظام”، وليس على “الشخص”. بدل ما نقول “سامر ضغط الزر الغلط”، نقول “عملية النشر لدينا سمحت بالضغط على الزر الغلط بسهولة. كيف نجعل الضغط على هذا الزر أصعب أو يتطلب موافقة إضافية؟”.
الخطوة الرابعة: تشجيع الأسئلة “الغبية”
لا يوجد شيء اسمه سؤال غبي، بل هناك بيئة عمل غبية تقتل الفضول. لكسر هذا الحاجز، قمنا ببعض الأمور البسيطة:
- إنشاء قناة مخصصة للمساعدة: أنشأنا قناة على Slack اسمها
#اسأل_ولا_تخف. القاعدة الوحيدة فيها: كل الأسئلة مرحب بها، والجواب لازم يكون لطيف ومساعد. - المبرمجون الكبار يسألون: كقادة، كنا نتعمد طرح أسئلة تبدو “أساسية” في القنوات العامة. مثلاً: “يا جماعة، حدا يذكرني كيف كنا نعمل setup للمشروع X؟ نسيت خطوة معينة”. هذا يرسل رسالة قوية: حتى الخبراء ينسون ويسألون، وهذا طبيعي.
شو صار بعدين؟ ثمار ‘الأمان النفسي’
بعد تطبيق هذه المبادئ على مدى شهور وسنوات، التغيير كان مذهلاً:
- سرعة الابتكار زادت: صار المبرمجون لا يخافون من تجربة تقنيات جديدة أو طرح أفكار جريئة.
- جودة الكود تحسنت: لأن الجميع صار يشارك في المراجعة ويشعر بالمسؤولية بدون خوف.
- المعنويات ارتفعت: الناس صارت تحب تيجي على الشغل، والتعاون صار هو الأساس.
- النمو السريع: المبرمجون المبتدئون مثل “سامر” تحولوا إلى أعمدة في الفريق، لأنهم وجدوا البيئة الآمنة للتعلم والنمو.
الخلاصة… من الآخر 📝
بناء ثقافة الأمان النفسي ليس رفاهية، بل هو أساس أي فريق تقني ناجح ومبدع. هو الاستثمار الأهم الذي يمكنك القيام به في فريقك. الأمر لا يتعلق بأن نكون “لطيفين” فقط، بل بأن نكون “فعالين”.
تذكر دائماً:
- ابدأ بنفسك: كن القدوة في الاعتراف بالخطأ وتقبل النقد.
- غير لغة الحوار: ركز على “ماذا” و”كيف”، وليس على “من”.
- حوّل الأخطاء إلى دروس: الفشل فرصة للتعلم، وليس سبباً للعقاب.
- شجع الفضول: اصنع بيئة يكون فيها السؤال أسهل من إخفاء الجهل.
الأمان النفسي رحلة، وليس وجهة. ابدأ اليوم بخطوة صغيرة، بتعليق لطيف في مراجعة كود، أو باعتراف صادق بخطأ. مع الوقت، سترى كيف تتحول ساحة المعركة إلى حديقة غنّاء من الإبداع والتعاون. 👍
الله يعطيكم العافية.
