يا جماعة الخير، بالصلاة على النبي. اسمحوا لي آخذكم في رحلة قصيرة لقبل كم سنة، لمشروع سمّيناه بيننا “العنقاء”. كان مشروع طموح، بنبني فيه نظام توصيات معقد باستخدام الذكاء الاصطناعي. الفريق اللي معي كان ما شاء الله عليه، من خيرة المهندسين اللي اشتغلت معهم. لكن، ورغم كل هالخبرات، كان التقدم بطيئًا بشكل يقتل الروح.
كنت ألاحظ إنه كل سطر كود بنكتبه بياخذ نقاشات وسجالات لا تنتهي. ما حدا كان بده يكون أول واحد يعمل “Merge” للكود تبعه. كنت أسأل مهندس مبتدئ: “شو رأيك يا غالي في هالطريقة؟”، فكان يطلع على المهندس الأقدم منه، كأنه بستنى إشارة منه ليحكي. والتعليقات على الـ “Pull Requests” كانت أشبه بمحاكمة قضائية مش مراجعة تعاونية. كل واحد بدور على غلطة للثاني عشان “يُثبت” إنه هو الأفضل.
في واحد من الاجتماعات، انفجر نقاش حاد بسبب “bug” بسيط ظهر في نسخة تجريبية. الأصابع توجهت فورًا للمهندسة اللي كتبت الكود. شفت في عيونها مزيج من الإحراج والغضب. في هذيك اللحظة، أدركت إنه المشكلة مش تقنية أبدًا. المشكلة كانت أعمق بكثير… كانت “الخوف”. الخوف من الخطأ، الخوف من الحكم، الخوف من تحمل اللوم. كنا نمشي على قشر بيض، والإبداع كان أول ضحية. عرفت وقتها إنه لازم أغير إشي جوهري في ثقافة الفريق، وإلا مشروع “العنقاء” رح يظل مجرد حبر على ورق.
ما هو “الأمان النفسي”؟ وليش هو مهم زي الأوكسجين للفريق؟
قبل ما أحكي لكم شو عملت، خلينا نوضح شو هو “الأمان النفسي” (Psychological Safety). المصطلح قد يبدو “فلسفي” أو من كتب التنمية البشرية، لكن صدقوني، هو إشي عملي وملموس جدًا في عالمنا التقني.
ببساطة، الأمان النفسي هو الإيمان المشترك بين أعضاء الفريق بأن هذا المكان آمن للمخاطرة على المستوى الشخصي. يعني، كل عضو في الفريق بيقدر يطرح فكرة “مجنونة”، يسأل سؤال “غبي”، يعترف بخطأ، أو يتحدى الوضع القائم بدون ما يخاف من العقاب أو الإهانة أو تهميش دوره.
الأمان النفسي مش معناه إنه نكون “لطيفين” طول الوقت ونتجنب النقد البنّاء. بالعكس، هو اللي بيسمح للنقد البنّاء إنه يحصل أصلًا! هو أشبه بشبكة الأمان اللي بتكون تحت لاعب الأكروبات في السيرك. الشبكة ما بتمنعه من السقوط، لكنها بتعطيه الثقة إنه يجرب حركات جريئة ومبدعة، وهو عارف إنه لو وقع، ما رح تكون النهاية.
أعراض الفريق الخائف (هل فريقك يعاني منها؟)
قبل ما أبدأ رحلة التغيير، كان لازم أشخّص المرض. فريق “العنقاء” كان بيعاني من أعراض واضحة، يمكن تكون موجودة في فريقك وأنت مش منتبه:
- صمت الاجتماعات: المدير أو المهندس الأقدم هو الوحيد اللي بيتكلم. الباقي مجرد مستمعين، بيهزوا رؤوسهم بالموافقة حتى لو ما كانوا مقتنعين.
- تجنب المخاطرة: التمسك الشديد بالتقنيات القديمة والمجربة. شعارهم “إذا بتشتغل، ما تلمسها”. أي اقتراح لتبني مكتبة جديدة أو طريقة مختلفة يُقابل بالرفض الفوري بحجة “ما بدنا مشاكل”.
- لعبة إلقاء اللوم: أول رد فعل عند ظهور أي مشكلة أو “bug” هو البحث عن كبش فداء. السؤال الأول دائمًا “مين اللي عمل هيك؟” بدلًا من “كيف نصلح المشكلة ونتعلم منها للمستقبل؟”.
- غياب الأسئلة “الغبية”: إذا ما حدا في فريقك بيسأل أسئلة أساسية، فهذا مش دليل إنهم كلهم عباقرة. هذا دليل إنهم خايفين يظهروا بمظهر الجاهل.
– المركزية القاتلة: كل قرار، مهما كان صغير، لازم يمر على المدير لأخذ الموافقة. ما حدا عنده الجرأة ياخذ زمام المبادرة.
خطواتي العملية لبناء الأمان النفسي: من النظرية إلى التطبيق
تشخيص المشكلة كان الجزء السهل. العلاج كان بده شغل وصبر ونفس طويل. هاي هي الخطوات اللي أخذتها، خطوة بخطوة، عشان أبني شبكة الأمان لفريقي.
الخطوة الأولى: أنا القائد، أنا أُخطئ أولًا
ما بنفع تطلب من فريقك يكونوا شجعان وأنت مختبئ في برجك العاجي. لازم القدوة تبدأ منك. بدأت أتكلم بصراحة وشفافية عن أخطائي أنا شخصيًا.
أتذكر مرة في اجتماع الصباح اليومي (Daily Standup)، قلتلهم: “يا جماعة، فاكرين الـ function اللي كتبتها الأسبوع الماضي لتعمل Caching؟ اليوم اكتشفت إنها بتعمل memory leak محترم وقاعده بتستهلك ذاكرة السيرفر. أنا آسف، هاي غلطتي. تعالوا بعد الاجتماع نفكر سوا كيف نصلحها ونحط آلية عشان نتجنب هيك أخطاء بالمستقبل”.
في البداية، استغربوا. كانوا متعودين إن القائد ما بيغلط. لكن مع الوقت، هاي الرسالة وصلت للجميع: الخطأ ليس عيبًا، بل هو فرصة للتعلم. لما شافوني بعترف بأخطائي، صار أسهل عليهم يعترفوا بأخطائهم.
الخطوة الثانية: تحويل مراجعة الكود (Code Review) من ساحة معركة إلى ورشة عمل
كانت مراجعات الكود هي أكبر مصدر للخوف. كانت أشبه بتحقيق. قررت أغير القواعد.
- غيرت لغة الحوار: بدلًا من كتابة “ليش استخدمت هاي الطريقة؟ هذا غلط”، صرت أكتب “نهج مثير للاهتمام. ممكن تشرحلي طريقة تفكيرك؟ أنا فضولي أعرف إذا قارنّاها مع [طريقة أخرى] وشو إيجابيات وسلبيات كل وحدة”. الهدف صار الفهم والتعاون، مش التصيّد.
- وضعت قاعدة ذهبية: “علّق على الكود، وليس على المبرمج”. (Comment on the code, not the coder).
- استخدمت قوالب للـ Pull Requests: عشان ننظم الحوار، أنشأت ملف
PULL_REQUEST_TEMPLATE.mdفي مستودع الكود على GitHub. هذا القالب كان يجبر المبرمج على شرح “لماذا” وليس فقط “ماذا” فعل.
هذا مثال بسيط على القالب اللي استخدمناه:
### 🎯 الغرض من هذا التغيير
### 🛠️ التغييرات الرئيسية
### 🧪 كيف تم الاختبار؟
### ❓ أسئلة للمراجعين
هذا القالب البسيط حوّل المراجعات من عملية سلبية إلى حوار بنّاء وموجه.
الخطوة الثالثة: الاحتفاء بالفضول وتشجيع الأسئلة
كنت بدي أقتل فكرة “السؤال الغبي”. صرت أحتفي بالأسئلة، خصوصًا الأساسية منها.
- في الاجتماعات، كنت أتعمد أسأل المهندس الأصغر في الفريق عن رأيه أولًا. كنت أقول: “يا فلان، إنت لسا عينك جديدة على المشروع، أكيد شايف إشي إحنا من كثر ما تعودنا عليه بطلنا نشوفه. شو ملاحظاتك؟”. هذا أعطاه صوتًا وأشعره بقيمته.
- أنشأنا قناة على Slack اسمها “#اسأل_وتعلم”، وشعارها كان “لا يوجد سؤال غبي”. صارت مكان آمن لأي حدا يسأل عن أي إشي، من أبسط أوامر Git إلى أعقد المفاهيم في الذكاء الاصطناعي.
- تبنينا تقنية “الخمسة لماذا” (The Five Whys). لما كان يصير خطأ، بدل ما نوقف عند “مين عمله”، كنا نسأل “ليش؟” خمس مرات للوصول إلى السبب الجذري للمشكلة، واللي غالبًا ما يكون مشكلة في العملية (Process) وليس في الشخص.
الخطوة الرابعة: فصل الأفكار عن أصحابها
من طبيعة البشر إنهم يدافعوا عن أفكارهم. عشان نتجنب هذا، كنا بحاجة لطريقة لنقد “الفكرة” بدون ما يشعر صاحبها إنه يتعرض لهجوم شخصي.
نصيحة عملية: استخدمنا “اللوح الأبيض” (Whiteboard) كسلاح سري. في جلسات العصف الذهني، كان كل واحد يكتب أفكاره على أوراق لاصقة (Post-it notes) بدون اسم ويلصقها على اللوح. بعدين، كنا كفريق نناقش “الأفكار اللي على اللوح” ونحللها ونقيمها. هيك، تحول النقاش من “فكرتك ضد فكرتي” إلى “نحن كفريق نقيم هذه الأفكار لاختيار الأفضل”.
النتائج: من الكبت إلى الإبداع 💡
التغيير ما حصل بيوم وليلة، أخذ شهور من الالتزام والمتابعة. لكن النتائج كانت مذهلة:
- الإبداع انفجر: صار أعضاء الفريق يقترحوا أفكار جريئة وتقنيات جديدة. بعضها فشل، وهذا كان طبيعي، لكن بعضها الآخر أدى إلى قفزات نوعية في المشروع.
- السرعة زادت: المبرمجون بطلوا يخافوا من دمج الكود (Merge) والحصول على تغذية راجعة، مما سرّع من وتيرة التطوير بشكل كبير.
- النمو تسارع: المهندسون الجدد تطوروا بسرعة خيالية لأنهم شعروا بالأمان للتجربة والسؤال والخطأ والتعلم.
- روح الفريق الواحد: اختفت لعبة إلقاء اللوم، وحلّت محلها الملكية الجماعية للمشكلة. الشعار الجديد صار: “الـ bug هو مشكلة الفريق، مش مشكلة فلان”. وبدأنا نعقد جلسات “مراجعة ما بعد الحادث” (Blameless Postmortems) للتعلم من كل عثرة.
مشروع “العنقاء” اللي كان متعثرًا، انطلق وحقق نجاحًا فاق توقعاتنا. لكن النجاح الأكبر بالنسبة لي ما كان إطلاق المشروع، بل كان رؤية الفريق وهو يعمل بانسجام وثقة وإبداع.
خلاصة من القلب ونصيحة أخيرة
يا صديقي المبرمج، ويا قائد الفريق، الأمان النفسي ليس رفاهية أو مجرد “مهارة ناعمة”. إنه أساس متين لا غنى عنه لبناء فرق عالية الأداء وقادرة على الابتكار في عالمنا التقني سريع التغير.
إذا كنت قائدًا، تذكر أن التغيير يبدأ منك. كن أول من يعترف بالخطأ، كن أول من يستمع، وكن أنت شبكة الأمان لفريقك. أما إذا كنت عضوًا في فريق، فساهم في بناء هذه الثقافة من خلال تشجيع زملائك ودعمهم وتقبل النقد برحابة صدر.
نصيحتي الأخيرة لك، من الآخر: حجم إبداع فريقك يتناسب طرديًا مع شعورهم بالأمان. إذا أردت أن تطلق العنان لقدراتهم الكامنة، لا تبنِ لهم أسوارًا أعلى، بل ابنِ لهم شبكة أمان أقوى. 🙏
