كان الجميع يهز رأسه موافقاً: كيف أنقذتنا ‘ثقافة الأمان النفسي’ من جحيم الإجماع الزائف؟

أذكر ذلك اليوم جيداً، كنا في اجتماع عصف ذهني لمشروع جديد يعتمد على تقنيات تعلم الآلة. كنت قد طرحت بنية تحتية (Architecture) معينة للمشروع، بدت لي منطقية وسليمة في ذلك الوقت. بعد أن أنهيت شرحي، سألت السؤال التقليدي: “شو رأيكم يا جماعة؟ في أي ملاحظات؟”.

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

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

كانت تلك اللحظة بمثابة صفعة لي. لم نكن فريقاً متناغماً، بل كنا مجموعة من الأفراد الذين يخشون التعبير عن رأيهم الحقيقي. كنا نعيش في جحيم “الإجماع الزائف” (False Consensus)، حيث يوافق الجميع في العلن، ثم يشتكون ويعانون في السر. هذه الحادثة كانت نقطة التحول التي دفعتني للبحث والغوص في مفهوم “الأمان النفسي” وتطبيقه بكل ما أوتيت من قوة.

ما هو “الأمان النفسي”؟ وليش هو مهم لدرجة كبيرة؟

ببساطة، الأمان النفسي (Psychological Safety) مش معناه إنه نكون “لطيفين” مع بعض طول الوقت أو نتجنب النقاشات الصعبة. بالعكس تماماً!

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

في بيئة العمل البرمجية، هذه “المجازفات” قد تكون:

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

بدون هذا الأمان، تحصل على ما حصل معي: فريق صامت، وأخطاء مدفونة، وإبداع مقتول.

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

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

اجتماع “الهزّازين رؤوسهم”

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

اجتماعات ما بعد الاجتماع

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

لعبة إلقاء اللوم (The Blame Game)

عندما يظهر “باغ” (Bug) في النظام، يكون السؤال الأول: “مين اللي كتب هالكود؟” بدلاً من “كيف حدث هذا؟ وكيف نمنع تكراره؟”. هذا يخلق بيئة من الخوف حيث يحاول المطورون إخفاء أخطائهم بدلاً من التعلم منها.

صمت المبتدئين

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

كيف بنينا ثقافة الأمان النفسي خطوة بخطوة؟ (الدليل العملي)

التحول لم يحدث بين ليلة وضحاها، بل كان عملية تدريجية ومقصودة. إليكم الخطوات العملية التي اتبعناها والتي يمكنك تطبيقها في فريقك اليوم.

1. القائد يبدأ بنفسه (Lead by Example)

لا يمكنك أن تطلب من فريقك شيئًا لا تفعله بنفسك. كقائد للفريق، بدأت عمدًا في إظهار ضعفي البشري:

• اعترف بأخطائك علنًا: في أحد الاجتماعات الصباحية، قلت بصراحة: “يا جماعة، أنا اللي عملت push للكود اللي كسر الـ build مبارح بالليل. خبّصت في الـ merge، وهاي الشغلات اللي تعلمتها من غلطتي…”. في البداية، استغرب الفريق، لكنهم بعد ذلك شعروا بالراحة لأن “أبو عمر” نفسه يخطئ ويعترف بذلك.
• اطلب المساعدة والنقد: بدلاً من إعطاء الأوامر، بدأت أطرح أسئلة مثل: “هذا هو الحل المبدئي اللي فكرت فيه لمشكلة الـ caching، بس مش مقتنع فيه 100%. مين عنده فكرة أفضل أو شايف فيه مشكلة؟”.

2. أعد صياغة اللغة: من اللوم إلى التعلم

الكلمات التي نستخدمها تشكل ثقافتنا. قمنا بتغيير واعٍ في مصطلحاتنا:

• بدلاً من: “ليش الكود هذا ما بشتغل؟”، أصبحنا نقول: “يبدو أن هناك سلوكًا غير متوقع هنا، دعونا نفهمه معًا”.
• بدلاً من: “مين المسؤول عن هذا الخطأ؟”، أصبحنا نسأل: “ما هي العوامل في نظامنا (العمليات، الأدوات، الاختبارات) التي سمحت بحدوث هذا الخطأ؟ وكيف نحسن النظام؟”.

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

3. اجعل الاختلاف في الرأي مُنتجًا ومطلوبًا

الخلاف ليس مشكلة، بل هو فرصة لرؤية الزوايا التي لم نكن نراها. طبقنا تقنيتين:

• مهمة “محامي الشيطان” (Devil’s Advocate): في الاجتماعات الهامة، كنا نكلف أحد أعضاء الفريق (كل مرة شخص مختلف) بلعب دور “محامي الشيطان”. مهمته هي البحث عن كل العيوب والثغرات المحتملة في الاقتراح المطروح. هذا حوّل النقد من هجوم شخصي إلى جزء مطلوب من العملية.
• اشكر من يخالفك الرأي: عندما كان أحدهم يقدم وجهة نظر مختلفة، كنت أحرص على أن أشكره علنًا. “شكرًا يا سارة على هذه الملاحظة، نقطة مهمة جدًا ما كانت خاطرة على بالي. خلينا نفكر فيها أكتر”.

4. استخدم عمليات وإجراءات تدعم الأمان النفسي

الثقافة لا تُبنى بالنوايا الحسنة فقط، بل بالإجراءات الملموسة.

مثال: مراجعة الكود (Code Review) كأداة بناء لا هدم

حوّلنا مراجعات الكود من عملية “تصيّد أخطاء” إلى فرصة للتعلم الجماعي. انظر الفرق بين التعليقين التاليين على طلب سحب (Pull Request):

التعليق السيئ (يهدم الأمان النفسي):

// ليش عامل كل هاللخبطة؟ استخدم for-loop عادي وخلص.

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

// أرى أنك استخدمت recursion هنا، فكرة مثيرة للاهتمام!
// هل فكرت في حالة لو كانت الـ array كبيرة جدًا؟ قد نواجه stack overflow.
// أقترح أن نناقش إمكانية استخدام نهج تكراري (iterative approach) لتجنب هذه المشكلة.
// ما رأيك؟

التعليق الثاني يقر بالجهد، يشرح “لماذا” التغيير مقترح (السبب التقني)، ويفتح باب النقاش بدلاً من إغلاقه.

إجراءات أخرى:

• جلسات “ما بعد الوفاة” بدون لوم (Blameless Postmortems): عند حدوث فشل كبير (مثل توقف الخادم)، نعقد اجتماعًا ليس لتحديد المذنب، بل لتوثيق التسلسل الزمني للأحداث، فهم الأسباب الجذرية (تقنية، بشرية، إجرائية)، والخروج بخطوات عملية لمنع تكرار المشكلة.
• ساعات مكتبية مفتوحة (Open Office Hours): خصصت ساعة كل يوم ثلاثاء يمكن لأي شخص في الفريق حجزها معي لمناقشة أي شيء، سواء كان تقنيًا، شخصيًا، أو مجرد فكرة يريد استكشافها.

النتيجة: ماذا جنينا من ثقافة الأمان النفسي؟

بالآخر، ما هي الثمار التي قطفناها؟

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

الخلاصة: ابدأ بنفسك، ولو بخطوة صغيرة ✅

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

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

قد تكون هذه الخطوة الصغيرة هي التي تنقذ فريقك من جحيم الإجماع الزائف وتأخذكم جميعًا إلى مستوى جديد من الإبداع والإنتاجية. والله ولي التوفيق. 🚀