صوت إشعار الخطأ الحرج على قناة “سلاك” (Slack) كان كفيلاً بأن يُجمّد الدم في عروقنا جميعاً. الساعة كانت تقارب العاشرة مساءً، والموقع الرئيسي للعميل الأهم لدينا توقف عن العمل تماماً. “شاشة بيضاء”، لا شيء غيرها. في تلك اللحظات، لم يكن صوت الإشعار هو ما يخيفني، بل الصمت الذي تلاه.
صمت مطبق في قناة الفريق، كأن الجميع حبس أنفاسه. ثم بدأ الهمس في الرسائل الخاصة. “مين آخر واحد عمل deploy؟”، “أكيد فلان خبّص الدنيا”، “أنا مالي دخل، كنت شغال على شغلة ثانية”. كنت أرى الخوف يتجسد في كلمات لم تُكتب بعد. الخوف من الاعتراف بالخطأ، الخوف من تحمل المسؤولية، الخوف من أن تكون “كبش الفداء” هذه المرة.
دخلت على القناة العامة وكتبت: “يا جماعة، اهدوا شوي. المشكلة مش مين اللي عملها، المشكلة كيف صارت وكيف نرجع الموقع بأسرع وقت. مين عنده فكرة من وين نبدأ؟”. كان هذا السؤال البسيط بداية رحلة طويلة وشاقة، رحلة نقلت فريقنا من “جحيم ثقافة اللوم” إلى بيئة عمل آمنة ومبدعة. هذه قصتنا مع ما يسمى بـ “السلامة النفسية”.
ما هي “السلامة النفسية” في بيئة العمل؟
ببساطة شديدة، السلامة النفسية (Psychological Safety) هي الاعتقاد السائد داخل الفريق بأن المكان آمن للمجازفة الشخصية. هي أن تشعر بالراحة في طرح الأفكار، والأسئلة، والمخاوف، وحتى الاعتراف بالأخطاء، دون الخوف من العقاب أو الإهانة أو تهميشك.
هذا المفهوم ليس دعوة للتساهل أو غياب المحاسبة، على العكس تماماً. هو الفرق بين بيئة تقول:
“من المسؤول عن هذا الخطأ؟ يجب أن يُعاقب!”
وبيئة تقول:
“حدث خطأ، هذا طبيعي في عملنا. لندرس معاً لماذا حدث، وماذا تعلمنا منه، وكيف نضمن عدم تكراره؟”
الفارق هائل. الأولى تخلق الخوف والصمت، والثانية تخلق التعلم والنمو.
علامات تدل على غياب السلامة النفسية في فريقك
قبل أن نصلح المشكلة، يجب أن نعترف بوجودها. إذا رأيت هذه العلامات في فريقك، فاعلم أن “جرس الإنذار” قد انطلق:
- السكوت المطبق في الاجتماعات: هل الجميع يهز رأسه موافقاً على كل ما يقوله المدير أو القائد التقني؟ هل تنتهي الاجتماعات دون أي سؤال أو نقاش حقيقي؟ هذا ليس انسجاماً، هذا خوف.
- الأخطاء المدفونة: يكتشف المبرمجون أخطاءهم ويحاولون “ترقيعها” في الخفاء، على أمل ألا يلاحظها أحد، حتى تتحول هذه الأخطاء الصغيرة إلى كوارث كبيرة.
- ثقافة “أنا مالي دخل”: عندما تحدث مشكلة، أول رد فعل يكون “مش شغلي” أو “هذا ليس في نطاق مسؤوليتي”. يتهرب الجميع من الملكية لأن الملكية تعني المخاطرة.
- الخوف من طرح الأسئلة “الغبية”: المبرمجون الجدد، على وجه الخصوص، يخشون طرح الأسئلة الأساسية خوفاً من أن يظهروا بمظهر غير الكفؤ. هذا الخوف يؤدي بهم إلى ارتكاب أخطاء كان يمكن تفاديها بسؤال بسيط.
- التركيز على “مَن” بدلاً من “لماذا”: بعد كل مشكلة، يكون السؤال الأول هو “مَن فعل هذا؟” بدلاً من “لماذا سمح نظامنا وعملياتنا بحدوث هذا؟”.
كيف نبني ثقافة السلامة النفسية؟ خطوات عملية من الميدان
بناء هذه الثقافة لا يحدث بين ليلة وضحاها، بل هو جهد مستمر يتطلب التزاماً من الجميع، وخاصة من القادة. إليك بعض الخطوات التي طبقناها في فريقنا وأحدثت فرقاً حقيقياً.
الخطوة الأولى: القائد هو القدوة
لا يمكنك أن تطلب من فريقك أن يكون شفافاً وصريحاً إذا كنت أنت نفسك قلعة مغلقة. كقائد، يجب أن تكون أول من يعترف بالخطأ.
نصيحة من أبو عمر: أذكر جيداً في أحد الاجتماعات، كنت أشرح فكرة معمارية معقدة، فقاطعني مبرمج مبتدئ وقال: “عفواً أبو عمر، لكن ألا يتعارض هذا مع متطلبات الأداء التي ذكرناها الأسبوع الماضي؟”. كان بإمكاني أن أرفض سؤاله أو أدافع عن فكرتي بضراوة. بدلاً من ذلك، توقفت للحظة، وفكرت، ثم قلت أمام الجميع: “والله يا فلان، سؤالك في محله تماماً. نقطة ممتازة فاتتني. شكراً لأنك نبهتني”. في تلك اللحظة، لم أخسر شيئاً من هيبتي، بل كسبت ثقة الفريق بأكمله. لقد أرسلت رسالة واضحة: “من الآمن تحدي أفكاري”.
الخطوة الثانية: غيّر لغة الحوار
الكلمات التي نستخدمها تشكل واقعنا. استبدل لغة اللوم بلغة الفضول والتعلم.
- بدلاً من أن تسأل: “ليش عملت هيك؟!” (بنبرة اتهام)
- جرّب أن تسأل: “ممكن تشرحلي السياق اللي خلاك تاخد هاد القرار؟ حابب أفهم طريقة تفكيرك.”
- بدلاً من أن تقول: “هذا خطأك، أصلحه.”
- جرّب أن تقول: “يبدو أننا نواجه مشكلة هنا. كيف يمكننا كفريق أن نحلها ونتعلم منها؟”
هذا التحول البسيط في اللغة يغير ديناميكية الموقف من مواجهة إلى تعاون.
الخطوة الثالثة: طبّق ممارسات عملية تعزز الأمان
الأقوال الطيبة لا تكفي، يجب أن تدعمها أفعال وعمليات ملموسة.
1. جلسات “ما بعد الكارثة” بدون لوم (Blameless Postmortems)
بعد كل حادثة أو مشكلة كبيرة (مثل توقف الموقع في قصتي)، نعقد اجتماعاً لا نبحث فيه عن “كبش فداء”. الهدف هو تحليل ما حدث بموضوعية:
- الجدول الزمني: ماذا حدث ومتى؟
- التأثير: على من أثرت المشكلة وكيف؟
- الأسباب الجذرية: ليس فقط “المبرمج أخطأ”، بل “لماذا كان من السهل على المبرمج أن يخطئ؟ هل العملية ضعيفة؟ هل الأدوات غير كافية؟”.
- الإجراءات التصحيحية: ما هي الخطوات الملموسة التي سنتخذها لمنع تكرار هذه الفئة من المشاكل؟ (مثال: تحسين سكربت النشر، إضافة اختبارات تلقائية، إلخ).
2. مراجعات الكود (Code Reviews) كأداة للتعلم
حوّل مراجعة الكود من عملية “تصيد أخطاء” إلى حوار بنّاء.
تعليق سيء (يلوم):
// هذا الكود بطيء جداً وغير فعال. أعد كتابته.
// This code is very slow and inefficient. Rewrite it.تعليق جيد (يعلّم ويفتح حواراً):
// أرى أنك استخدمت حلقة متداخلة هنا. هل فكرت في استخدام خريطة (Map) لتقليل التعقيد الزمني من O(n^2) إلى O(n)؟
// قد يكون الأداء أفضل بكثير مع كميات البيانات الكبيرة. ما رأيك؟
// I see you've used a nested loop here. Have you considered using a Map to reduce the time complexity from O(n^2) to O(n)?
// The performance might be much better with large datasets. What do you think?الخطوة الرابعة: شجع الفضول واحتفل بالأسئلة
عندما يسأل عضو جديد في الفريق سؤالاً قد يبدو “بسيطاً”، لا تقل له “ابحث في جوجل”. بدلاً من ذلك، قل: “سؤال ممتاز! دعني أوضح لك…”. عندما تحتفل بالأسئلة، فأنت تشجع على التعلم المستمر وتقتل الخوف من الظهور بمظهر الجاهل.
نصيحة من أبو عمر: خصصنا في فريقنا قناة على “سلاك” باسم “أسئلة-بدون-خجل”. أي شخص يمكنه طرح أي سؤال، مهما كان بسيطاً، والجميع يتسابق للمساعدة. هذا خلق جواً رائعاً من الدعم المتبادل.
الخلاصة: من الخوف إلى الإبداع 🚀
السلامة النفسية ليست ترفاً أو “كلام تنمية بشرية” فارغ. إنها الأساس الذي تُبنى عليه الفرق عالية الأداء. إنها التربة الخصبة التي تسمح لأفكار الإبداع والابتكار بالنمو والازدهار.
عندما يشعر أعضاء فريقك بالأمان، سيبدؤون في تحمل المخاطر المحسوبة، وتجربة تقنيات جديدة، والتحدث بصراحة عن المشاكل قبل أن تتفاقم، والأهم من ذلك، سيعملون كفريق حقيقي يثق أفراده ببعضهم البعض.
يا جماعة، بناء الثقة يأخذ وقتاً وجهداً، لكن صدقوني، النتيجة تستحق كل لحظة تعب. فريق يعمل بحب وثقة، إنتاجيته وإبداعه ليس لهما حدود. يلا نشمر عن إيدينا ونبني بيئة عمل كلنا فخورون بها. 💪
