من الخوف إلى الإبداع: كيف أنقذت “السلامة النفسية” فريقي من شلل الصمت القاتل؟

يا الله شو بذَكّر هداك اليوم… كنا قاعدين كلنا في غرفة الاجتماعات، والوجوه عليها ألوان الطيف. مشكلة كبيرة طالعة في الـ Production، والعميل الرئيسي على التلفون مع الإدارة، وصوتهم واصلنا. أنا، أبو عمر، كنت وقتها قائد الفريق، وكل شوي أطلع في الشباب وأسأل: “يا جماعة، حدا عنده فكرة شو اللي صار؟ مين آخر واحد عمل push على هاي الجزئية؟”.

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

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

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

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

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

• إنك تسأل سؤال ممكن يبين “غبي” بدون ما تخاف حدا يتضحوك عليك.
• إنك تعترف بغلطة عملتها (“يا جماعة، أنا خبّصت”) بدون ما تخاف من اللوم أو العقاب.
• إنك تقترح فكرة مجنونة أو جديدة بدون ما تخاف حدا يحكيلك “شو هالهبل هاد؟”.
• إنك تعارض رأي مديرك أو زميلك الأقدم منك باحترام، لأنك شايف الأمور من زاوية تانية.

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

علامات الخطر: كيف تعرف أن فريقك يغرق في “جحيم الصمت”؟

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

1. الصمت في الاجتماعات، خصوصاً الـ Retrospectives

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

2. الخوف من طرح الأسئلة

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

3. إخفاء الأخطاء حتى تكبر

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

تخيل هذا السيناريو: مبرمج اكتشف إنه الـ logic اللي كتبه لخصم الرصيد فيه مشكلة ممكن تسبب خصم مزدوج في حالات نادرة. في بيئة غير آمنة، ممكن يعمل commit سريع ومريب زي هيك:

git commit -m "fix"

هو بيأمل إنه التعديل يمر بدون ما حدا يسأل. لكن في بيئة آمنة، هو مش بس رح يبلغ الفريق، رح يكتب رسالة commit واضحة ويطلب مراجعة فورية:

git commit -m "fix(Billing): Critical fix for potential double-charge race condition.
This addresses an edge case found in manual testing where two requests could process simultaneously. Added a database lock to prevent this. Needs urgent review and deploy."

الفرق بين الرسالتين هو الفرق بين الخوف والثقة.

4. ثقافة “اللوم” بدلاً من “الحل”

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

وصفة أبو عمر لبناء جسور الثقة: خطوات عملية لخلق بيئة آمنة

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

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

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

2. غيّر لغة الحوار: من “لماذا فعلت؟” إلى “ماذا تعلمنا؟”

اعتمد نظام الـ “Blameless Postmortems” (تحليل الأحداث بدون لوم). بعد كل مشكلة كبيرة، اعمل اجتماع مش هدفه نحدد مين المذنب، هدفه نجاوب على هاي الأسئلة:

• ما هو التسلسل الزمني للأحداث؟ (Timeline)
• ما هو الأثر الذي حدث؟ (Impact)
• ما هو السبب الجذري للمشكلة (Root Cause) في النظام والعمليات؟ (لاحظ: في النظام، مش في الشخص)
• ما هي الإجراءات اللي رح نعملها عشان نمنع تكرار المشكلة؟ (Action Items)

3. شجع الأسئلة “الغبية” واحتفل بها

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

4. التقدير العلني والملاحظات البناءة في الخاص

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

5. افرض “التنوع في التفكير” بالقوة

في اجتماعات التصميم (Design sessions)، كنت أحيانًا أستخدم تقنية “قبعات التفكير الست”. أطلب من واحد من الفريق يلعب دور “المتشائم” أو “محامي الشيطان” (Devil’s Advocate) بشكل رسمي. مهمته هي إنه يطلع كل المشاكل والسيناريوهات السيئة في التصميم المقترح. هيك، النقد بصير جزء من اللعبة، مش هجوم شخصي.

الخلاصة: الثقة هي الـ Compiler الحقيقي للفريق 💡

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

بناء السلامة النفسية مش مشروع إله بداية ونهاية، هو ثقافة بتنبني يوم ورا يوم، موقف ورا موقف، واجتماع ورا اجتماع. يمكن تكون الطريق طويلة، بس النتيجة تستاهل كل التعب. فريق قوي، منتج، ومبدع، والأهم من كل هاد… فريق سعيد. 👍