“تمام يا باشمهندس، كله تحت السيطرة”… الكذبة التي كادت أن تدمرنا
أذكر ذلك اليوم جيداً، كان يوم خميس، والضغط في أعلى مستوياته. كنا على وشك إطلاق ميزة جديدة وحاسمة في نظام الذكاء الاصطناعي الذي نعمل عليه لعميل مهم. فجأة، بدأت التنبيهات تتوالى كالمطر على قنوات “سلاك” (Slack) الخاصة بنا: خطأ فادح في بيئة الإنتاج (Production Environment) يؤثر على المستخدمين الحاليين.
تجمّع الفريق بسرعة، وبدأت رحلة البحث عن سبب المشكلة. الشكوك حامت حول وحدة برمجية جديدة ومعقدة كان قد استلمها أحد المطورين الشباب في فريقي، دعونا نسميه “سامر”. شاب ذكي، هادئ، ومجتهد. توجهت إليه مباشرة وسألته بلهجة سريعة وحاسمة: “سامر، هل أنت متأكد من فهمك لآلية عمل الوحدة X؟ هل كل شيء كان واضحاً عندما شرحتها لك الأسبوع الماضي؟”.
نظر إليّ سامر، وبتردد خفيف بالكاد يُلاحظ، أجاب: “نعم يا أبو عمر، تمام. كله تحت السيطرة”.
أمضينا الساعات الثلاث التالية كمن يبحث عن إبرة في كومة قش. فحصنا كل شيء، السيرفرات، قواعد البيانات، تحديثات البنية التحتية… لا شيء. شعرت بالإحباط يتسلل إليّ، إلى أن قررت أن أعود للمربع الأول. جلست بجانب سامر، وبهدوء هذه المرة، قلت له: “اسمع يا سامر، انسَ كل الضغط اللي علينا. خلينا نراجع الكود سوا، سطر بسطر. أنا نفسي ممكن أكون نسيت شغلة وأنا بشرحلك”.
وما هي إلا دقائق حتى اتضحت الصورة. كانت هناك حالة حافة (Edge Case) لم يتعامل معها الكود بشكل صحيح، ناتجة عن سوء فهم بسيط لكنه حاسم في منطق العمل الذي شرحته له. عندما أشرت إليها، رأيت على وجه سامر مزيجاً من الراحة والخجل. اعترف بأنه لم يفهم تلك النقطة 100% وقتها، لكنه خشي أن يسأل مرة أخرى حتى لا يظهر بمظهر غير الكفء أو “الغبي” أمامي وأمام الفريق.
في تلك اللحظة، لم أشعر بالغضب من سامر، بل شعرت به تجاه نفسي. المشكلة لم تكن في سامر، بل في البيئة التي سمحتُ أنا، كقائد للفريق، بخلقها دون وعي. بيئةٌ أصبح فيها قول “لا أعرف” أو “لم أفهم” مخاطرة كبيرة، أكبر من مخاطرة ترك خطأ فادح يتسلل إلى بيئة الإنتاج. كانت تلك الحادثة هي جرس الإنذار الذي أيقظني على مفهوم غيّر طريقة قيادتي للفرق إلى الأبد: السلامة النفسية (Psychological Safety).
ما هي “السلامة النفسية” يا جماعة الخير؟
قد يبدو المصطلح فضفاضاً أو من مصطلحات التنمية البشرية “الناعمة”، لكن صدقوني، أثره على الأداء والإنتاجية قاسٍ وملموس أكثر من أي أداة تقنية. السلامة النفسية، ببساطة، هي الإيمان المشترك بين أعضاء الفريق بأن البيئة آمنة للمخاطرة على المستوى الشخصي والمهني.
إنها تعني أن يتمكن أي فرد في الفريق، سواء كان متدرباً جديداً أو مهندساً خبيراً، من:
- طرح الأسئلة دون الخوف من أن يُقال عنه “سؤاله غبي”.
- الاعتراف بالخطأ دون الخوف من اللوم والعقاب.
- تقديم فكرة جديدة أو “مجنونة” دون الخوف من السخرية.
- التعبير عن رأي مخالف لرأي الأغلبية أو حتى رأي القائد.
هي ليست مجرد “أن نكون لطفاء مع بعضنا البعض”، بل هي ثقافة تسمح بالصراحة والشفافية والضعف البشري، وتعتبر كل ذلك جزءاً لا يتجزأ من عملية الابتكار وحل المشكلات المعقدة.
نصيحة من أبو عمر: فكر في السلامة النفسية كأنها آلية التعامل مع الأخطاء في البرمجة
try...catch. الفريق هو الـtryحيث تجرب الأفكار وتطرح الأسئلة وتكتب الكود. ثقافة السلامة النفسية هي الـcatchالتي تلتقط الأخطاء (الأسئلة، الفشل، سوء الفهم) وتعالجها بشكل بنّاء بدلاً من أن تتركها تسبب انهيار النظام بأكمله.
علامات الخطر: كيف تعرف أن فريقك يفتقر للسلامة النفسية؟
قبل حادثة سامر، كنت أظن أن فريقي “زي الفل” لأن الجميع كان يعمل بجد ولا توجد مشاكل ظاهرة. لكن الأخطاء الصامتة كانت تتراكم تحت السطح. هذه بعض العلامات التي أصبحت أراها بوضوح الآن:
1. صمت الاجتماعات
هل تلاحظ أن الاجتماعات عبارة عن حوار بين شخص أو شخصين والبقية صامتون؟ هل عندما تسأل “هل من أسئلة؟” يكون الجواب دائماً صمت مطبق؟ هذا ليس دليلاً على أن شرحك كان مثالياً، بل قد يكون دليلاً على أن الناس تخشى الكلام.
2. لعبة “مش أنا، هو!” (The Blame Game)
عندما يحدث خطأ، هل أول رد فعل للفريق هو البحث عن “كبش فداء”؟ ثقافة اللوم تقتل السلامة النفسية، لأنها تجعل الاعتراف بالخطأ مساوياً للانتحار المهني. الكل سيبدأ بحماية نفسه بدلاً من حل المشكلة.
3. ندرة الأسئلة “الغبية”
في بيئة صحية، يطرح المبتدئون الكثير من الأسئلة الأساسية. إذا كان أعضاء فريقك الجدد صامتين، فهم لا يتعلمون بسرعة، بل هم خائفون من الظهور بجهلهم. تذكر: لا يوجد سؤال غبي، بل هناك خوف من السؤال.
4. متلازمة الموافقة الدائمة
عندما يقترح القائد أو المهندس الأقدم فكرة ما، هل يوافق الجميع فوراً؟ هذا مؤشر خطير على غياب النقد البنّاء. الابتكار يولد من رحم الاختلاف وتحدي الأفكار، وليس من الموافقة العمياء.
خطواتي العملية لبناء حصن من السلامة النفسية
بعد “صفعة” سامر، قررت أن التغيير يجب أن يبدأ مني. لم أقم بإرسال إيميل أعلن فيه “يا جماعة، من اليوم فصاعداً لدينا سلامة نفسية!”. التغيير كان عبر أفعال وممارسات يومية ومستمرة. إليكم ما فعلت:
الخطوة الأولى: بدأت بنفسي واعترفت بجهلي
كنتُ “أبو العرّيف” في الفريق، وهذا خطأ. بدأت عمداً في الاجتماعات أقول جملاً مثل:
- “والله يا جماعة، هذه التقنية جديدة عليّ، لم أتعامل معها من قبل. من لديه خبرة فيها أو قرأ عنها؟”
- “فكرتي قد تكون خاطئة تماماً، لكن ماذا لو جربنا…؟”
- “أذكر مرة في مشروع سابق أنني ارتكبت خطأ كبيراً في تصميم قاعدة البيانات كلفنا أسابيع من العمل لإصلاحه. تعلمت منه درساً مهماً…”
عندما يراني الفريق، أنا القائد، أعترف بجهلي وأخطائي، يصبح من الطبيعي والآمن لهم أن يفعلوا المثل.
الخطوة الثانية: إعادة تأطير العمل (Framing)
غيرت لغتي من لغة “التنفيذ” إلى لغة “التعلم والاكتشاف”. بدلاً من قول “علينا تنفيذ هذه المهام العشر”، أصبحت أقول “أمامنا تحدٍ معقد، وسنحتاج لتجربة عدة طرق وربما الفشل عدة مرات حتى نصل للحل الأمثل”. هذا الإطار يمنح الفريق رخصة للتجربة والخطأ.
الخطوة الثالثة: تطبيق طقوس “التشريح بلا لوم” (Blameless Postmortems)
بعد أي حادث أو خطأ كبير، أصبحنا نعقد اجتماعاً لا يُسمح فيه أبداً بتوجيه أصابع الاتهام. الهدف ليس معرفة “من” تسبب بالمشكلة، بل “كيف” و “لماذا” حدثت المشكلة على مستوى النظام والعمليات. نطرح أسئلة مثل:
- ما هو التسلسل الزمني للأحداث؟ (حقائق فقط)
- ماذا كانت الإجراءات الوقائية الموجودة؟ ولماذا لم تكن كافية؟
- كيف يمكننا تحسين أنظمتنا (مراجعة الكود، الاختبارات الآلية، آلية النشر) لمنع تكرار هذا النوع من المشاكل؟
هذا حوّل الأخطاء من مصدر للخوف إلى أثمن مصدر للتعلم والتحسين.
الخطوة الرابعة: الدعوة الفعّالة للمشاركة
في الاجتماعات، لم أعد أكتفي بسؤال “هل من أسئلة؟” بشكل عام. أصبحت أنادي على الأشخاص الهادئين بالاسم وبطريقة مشجعة: “سامر، أعرف أنك كنت تعمل على جزء مشابه، ما رأيك في هذه الفكرة؟ هل ترى أي مخاطر لم ننتبه لها؟” أو “يا ليلى، أنتِ دائماً لديكِ نظرة مختلفة للأمور، أحب أن أسمع وجهة نظرك”.
النتيجة: من حقل ألغام إلى ملعب ابتكار
التغيير لم يحدث بين عشية وضحاها، لكن خلال أشهر، بدأت أرى ثماراً مذهلة:
- زيادة الابتكار: بدأ أعضاء الفريق يقترحون أفكاراً جريئة لتحسين المنتج والعمليات، لأنهم لم يعودوا يخشون رفض أفكارهم.
- سرعة في حل المشاكل: أصبحت الأخطاء تُكتشف وتُناقش في مراحل مبكرة جداً، لأن الإبلاغ عن مشكلة أصبح يُقابل بالشكر لا بالغضب.
- تطور أسرع للمهارات: المطورون الجدد أصبحوا يطرحون الأسئلة باستمرار ويتعلمون بوتيرة أسرع بكثير.
- انخفاض منسوب التوتر: اختفت سياسة “حماية النفس”، وأصبح الجو العام أكثر تعاوناً ومتعة.
سامر نفسه تحول من شاب خجول إلى واحد من أكثر أعضاء الفريق مبادرة، وكثيراً ما كان يأتي إليّ ليقول: “أبو عمر، كنت أفكر في هذه المشكلة، ووجدت ثغرة محتملة في تصميمنا الحالي…”. هذه الجملة أصبحت تساوي عندي ذهباً.
خلاصة الحكي 🏁
يا صديقي المبرمج، ويا قائد الفريق، السلامة النفسية ليست ترفاً، بل هي حجر الأساس لأي فريق عالي الأداء ومبتكر. إنها الفرق بين فريق يطفئ الحرائق بصعوبة، وفريق يمنع اندلاعها أصلاً.
إذا كنت تريد أن تطلق العنان للقدرات الحقيقية لفريقك، ابدأ اليوم. كن أنت أول من يقول “لا أعرف”. كن أول من يعترف بخطأ. كن أول من يشكر الشخص الذي يأتي لك بخبر سيء. الأخطاء الصامتة هي أغلى أنواع الديون التقنية، والعملة الوحيدة التي تسددها هي ثقافة الثقة والأمان.
لا تخف من الضعف، فالقوة الحقيقية تكمن في بناء بيئة لا يخشى فيها أحد أن يكون إنساناً… يخطئ، ويتعلم، وينمو. 💪
