من مقبرة الأفكار إلى واحة الإبداع: كيف أنقذت ‘السلامة النفسية’ فريقنا البرمجي؟

بتذكر منيح هذاك الاجتماع، قبل كم سنة. كنا قاعدين في غرفة الاجتماعات، القهوة باردة، والوجوه عليها تعابير جامدة. كنا بنناقش تصميم بنية تحتية جديدة (New Architecture) لمشروع ضخم. المدير التقني كان بشرح رؤيته، والكل بهز براسه موافق، وأنا منهم، مع إنه كان في إشي جواتي بحكيلي إنه في مشكلة.

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

ساد صمت ثقيل في الغرفة. المدير التقني نظر إليه نظرة فوقية، وقال بحدة جافة: “إحنا مش فاضيين للتجارب يا أحمد، خلينا في المضمون. مين عنده إشي مهم يحكيه؟”.

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

هذه الحادثة كانت نقطة تحول بالنسبة إلي. أدركت إنه مشكلتنا ما كانت تقنية، بل كانت بشرية. مشكلتنا كانت غياب ما يُعرف بـ “السلامة النفسية”.

ما هي ‘السلامة النفسية’ في فريق العمل؟

لما نحكي “سلامة نفسية” (Psychological Safety)، كثير ناس بتفكر إنها مجرد “نكون لطيفين مع بعض” أو نتجنب النقد. بس الموضوع أعمق من هيك بكثير. السلامة النفسية، ببساطة، هي الإيمان المشترك بين أعضاء الفريق بأنهم بيقدروا ياخدوا مخاطر شخصية (interpersonal risks) بدون ما يتعرضوا للعقاب أو الإهانة.

شو يعني مخاطر شخصية؟ يعني:

• تسأل سؤال ممكن يبين “غبي”.
• تقترح فكرة مجنونة وغير تقليدية.
• تعترف إنك أخطأت أو إنك ما بتعرف إشي معين.
• تختلف مع رأي الأغلبية أو حتى مع رأي القائد.

في بيئة عمل آمنة نفسياً، الموظف ما بخاف يحكي: “أنا مش فاهم، ممكن تعيد شرح هاي النقطة؟” أو “يا جماعة، أنا شايف إنه هاد الاتجاه غلط والسبب هو كذا وكذا”. البيئة الآمنة هي اللي بتحول الخوف من العقاب إلى حماس للمشاركة.

أعراض غياب السلامة النفسية: كيف تعرف أن فريقك في خطر؟

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

صمت الاجتماعات المرعب

أوضح علامة. الاجتماع بكون عبارة عن مونولوج من شخص واحد (عادةً القائد)، والباقي مستمعين صامتين. الأفكار لا تُناقش، بل تُملى. إذا كان اجتماع فريقك المكون من 10 أشخاص يمكن إجراؤه مع شخص واحد فقط، فأنت في مشكلة.

ظاهرة “الامتثال الأعمى” أو “نعم يا سيدي”

الكل بوافق على كلام المدير أو المهندس الأقدم، حتى لو كان واضح إنه الكلام مش منطقي. هذا ليس احتراماً، بل هو خوف مقنّع. الخوف من أن يُنظر إليك كشخص “سلبي” أو “مش متعاون” إذا عارضت.

الخوف من الخطأ ولعبة إلقاء اللوم

لما تحصل مشكلة أو يظهر “Bug” في النظام، أول سؤال بكون “مين اللي عمل هيك؟” بدل “كيف نصلح المشكلة ونتعلم منها؟”. المبرمجين بصيروا يخفوا أخطائهم أو يكتبوا كود “دفاعي” وآمن جداً لدرجة أنه يقتل أي إبداع، خوفاً من المساءلة.

غياب الأسئلة “الغبية”

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

كيف بنينا جسور الثقة؟ خطوات عملية لخلق بيئة آمنة نفسياً

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

1. القيادة بالقدوة: اعترف بأخطائك أولاً

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

“يا جماعة الخير، أنا أبو عمر، وبكل فخر بعلن إني خربطت ودفعت كود فيه مشكلة على الـ main branch. أنا آسف جداً، وعم بشتغل على حلها حالياً. هذا درس إلي إني دايماً أعمل فحص إضافي قبل الـ push. حدا عنده أي نصيحة لتجنب هذا النوع من الأخطاء في المستقبل؟”

ردة فعلي هاي عملت شغلتين: أولاً، طمأنت الفريق إنه الخطأ مش نهاية العالم. وثانياً، فتحت باب للنقاش حول تحسين عملياتنا بدل من إلقاء اللوم.

2. تشجيع الفضول لا الحكم: غيّر طريقة طرح الأسئلة

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

• “هاي فكرة مثيرة للاهتمام، ممكن تشرحلي أكثر كيف بتتخيلها رح تشتغل على أرض الواقع؟”
• “شو المخاطر اللي ممكن تواجهنا لو اتبعنا هذا النهج؟”
• “شو في بدائل أخرى فكرت فيها؟”

هذا الأسلوب يشجع الشخص الآخر على التفكير بعمق في فكرته، ويُشعره بأنك تستمع إليه وتهتم برأيه، حتى لو لم توافق عليه في النهاية.

3. ثقافة مراجعة الكود (Code Review) البنّاءة

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

التعليق السيء (يدمر السلامة النفسية):

// ليش عامل كل هاي اللفة؟ الكود هذا بطيء جداً وغير مفهوم. أرجع أكتبه من أول.
// Why did you do all this? This code is very slow and unreadable. Rewrite it from scratch.

التعليق الجيد (يبني السلامة النفسية):

// مرحباً، يعطيك العافية على الشغل. لاحظت إنه استخدمت حلقة تكرار متداخلة (nested loop) هنا.
// خطر ببالي إنه ممكن نواجه مشكلة أداء لو كبرت البيانات. شو رأيك لو نفكر سوا
// بطريقة نستخدم فيها Hash Map لتحسين الأداء؟ ممكن يكون شكلها كالتالي [...].
// What do you think?
//
// Hello, nice work on this. I noticed you're using a nested loop here.
// I'm a bit concerned about performance if the dataset grows.
// What do you think about exploring a Hash Map approach to optimize it?
// We could potentially structure it like [...]. Let me know your thoughts!

التعليق الثاني يركز على الكود وليس على المبرمج، يقترح حلاً، ويفتح باباً للحوار بدلاً من إصدار الأوامر.

4. احتفل بالأخطاء كفرص للتعلم

اعتمدنا مبدأ “Blameless Postmortems” (تحليل الأحداث بدون إلقاء لوم). لما تحدث مشكلة كبيرة، بنعمل اجتماع مش عشان نعرف “مين” السبب، بل عشان نفهم “ماذا” حصل، و”لماذا” حصل، و”كيف” نمنع حدوثه مرة ثانية. الوثيقة اللي بتطلع من هذا الاجتماع بتكون عامة ومتاحة للجميع، وبتصير مرجع للتعلم في الشركة كلها.

النتائج الملموسة: من جحيم الصمت إلى جنة الإبداع

بعد تطبيق هاي المبادئ بشكل مستمر، التغيير كان مذهل:

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

خلاصة أبو عمر ونصيحة من القلب ❤️

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

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

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