بتذكرها زي كأنها مبارح. كانت ليلة خميس، والكل بستنى الويكند بفارغ الصبر. كنت مسؤول عن “مشروع الزيتون”، واحد من أكبر المشاريع اللي اشتغلنا عليها في الشركة. فجأة، وبدون سابق إنذار، التلفونات بلشت ترن، ورسائل “السلاك” (Slack) صارت زي المطر… النظام واقع! السيرفرات طافية، والعملاء مش قادرين يوصلوا لبياناتهم.
أول ردة فعل في غرفة الطوارئ الافتراضية كانت سؤال واحد، بصوت مدير المشروع المتوتر: “مين آخر واحد عمل commit على الفرع الرئيسي (main branch)؟”. في تلك اللحظة، تجمد الدم في عروقي. كنت أنا. أنا اللي عملت merge لآخر feature قبل ما أروح.
شعرت بكل العيون (الافتراضية) موجهة نحوي. بدأت حبات العرق البارد تتصبب على جبيني، مش خوفًا من المشكلة التقنية بحد ذاتها، بل خوفًا من “المحاكمة” اللي رح تصير. مين المذنب؟ مين رح يتحمل المسؤولية؟ مين رح “يلبس الطاقية” الليلة؟ كانت تلك الأجواء هي السائدة، أجواء “ثقافة اللوم” التي كانت تخنق فريقنا ببطء.
هذا الموقف، وغيره الكثير، كان الشرارة التي دفعتنا للبحث عن طريقة أفضل للعمل. طريقة لا يكون فيها الخطأ جريمة، بل فرصة. واليوم، بدي أحكيلكم كيف انتقلنا من جحيم الخوف إلى جنة الإبداع، وكيف كان مفهوم “السلامة النفسية” هو طوق النجاة.
ما هي ‘ثقافة اللوم’ ولماذا هي سم قاتل؟
قبل ما نحكي عن الحل، خلينا نوصف المرض. “ثقافة اللوم” (Blame Culture) هي بيئة العمل اللي بيكون فيها التركيز الأساسي عند حدوث أي مشكلة هو تحديد “الشخص” المسؤول ومعاقبته أو لومه، بدلًا من فهم “أسباب” المشكلة الجذرية لمنع تكرارها.
في هذه الثقافة، بتصير تسمع جمل زي:
- “مين اللي كتب هالكود؟” (بنبرة اتهام)
- “أكيد فلان خبّص الدنيا.”
- “لو إنك سمعت كلامي من الأول ما كان صار هيك.”
هذه الثقافة، يا جماعة، مدمرة بكل معنى الكلمة. نتائجها كارثية:
- قتل الإبداع: بصير المبرمج يخاف يجرب أي إشي جديد. ليش أغلب حالي وأعمل refactor للكود القديم إذا ممكن أكسر إشي وأتحمل اللوم؟ خليني على المضمون، “شغل copy-paste وربك الحامي”.
- إخفاء المشاكل: بدل ما الموظف يبلغ عن مشكلة صغيرة أول ما يكتشفها، بصير يخبيها أو “يلفلفها” خوفًا من اللوم. والمشكلة الصغيرة بتكبر وبتصير كارثة.
- بطء في التطور: الفريق بضل يكرر نفس الأخطاء لأنه ما حدا بتعلم منها. كل حادثة بتمر وبتنتهي بلوم شخص، وبننسى الدرس الأهم: كيف نمنعها في المستقبل.
- بيئة سامة: الكل بصير “يخاف على كرسيّه”. بتكثر السياسة والمكائد، وبقلّ التعاون والثقة. بصير الشغل ساحة حرب بدل ما يكون رحلة إبداع مشتركة.
‘السلامة النفسية’: الدواء الشافي الذي لا يعرفه الكثيرون
في خضم بحثنا عن حل، تعثرت بمصطلح غيّر حياتي المهنية: “السلامة النفسية” (Psychological Safety). المفهوم، اللي صاغته الباحثة في جامعة هارفارد إيمي إدموندسون، بسيط في ظاهره وعميق في تأثيره.
السلامة النفسية هي الاعتقاد المشترك بين أعضاء الفريق بأن الفريق آمن للمخاطرة الشخصية. إنها الإحساس بالثقة في أن الفريق لن يحرج أو يرفض أو يعاقب شخصًا ما على التحدث أو طرح الأسئلة أو الاعتراف بالخطأ.
الفرق جوهري. ثقافة اللوم تسأل: “من المسؤول؟”. بيئة السلامة النفسية تسأل: “ماذا حدث؟ وكيف نضمن ألا يحدث مرة أخرى؟”.
مهم جدًا نفهم: السلامة النفسية لا تعني التخلي عن المسؤولية أو خفض معايير الجودة. بالعكس تمامًا! هي التي تسمح بالصراحة المطلقة والنقد البنّاء الذي يرفع من جودة العمل لأعلى المستويات، لأن الناس لا تخاف من قول “هذا الكود سيء” أو “هذه الفكرة غير قابلة للتطبيق”.
كيف بنينا حصن ‘السلامة النفسية’ في فريقنا؟ خطوات عملية
الكلام النظري حلو، بس “الحكي ما بطعمي خبز”. كيف طبقنا هذا المفهوم على أرض الواقع؟ إليكم الخطوات اللي مشيناها، خطوة بخطوة.
الخطوة الأولى: القائد هو القدوة (Lead by Example)
التغيير يبدأ من فوق. مستحيل تطلب من فريقك يكون صريح وشفاف وأنت أول واحد بتخبي أخطائك. أتذكر مرة، كنت أعمل على تحسين أداء استعلام (query) معقد في قاعدة البيانات. بعد ما نشرت التغيير، تفاجأنا إنه أداء النظام صار أسوأ بكثير!
في اجتماع الفريق الصباحي، كان ممكن ألف وأدور، أو أرمي اللوم على بطء السيرفر. لكني قررت أكون القدوة. وقفت وقلت: “يا جماعة، أنا اللي خبّصت مبارح. الاستعلام اللي كتبته كان فيه خطأ منطقي فادح، وأنا أتحمل كامل المسؤولية عن تدهور الأداء. حاليًا رجّعت النسخة القديمة، وبدي مساعدة منكم لنلاقي حل أفضل. مين عنده أفكار؟”
الصمت اللي ساد الغرفة لثواني كان مريبًا، ثم تحول إلى نقاش بنّاء ومثمر. اعترافي بالخطأ لم يجعلني أبدو ضعيفًا، بل جعلني أبدو إنسانًا، وفتح الباب أمام الجميع ليكونوا كذلك.
الخطوة الثانية: استبدال ‘تحقيقات اللوم’ بـ ‘جلسات ما بعد الحادثة’ (Blameless Postmortems)
هذه كانت أهم خطوة تقنية وتنظيمية قمنا بها. بدلًا من جلسات “التحقيق” التي تبحث عن مذنب، قمنا بتبني مفهوم “جلسات ما بعد الحادثة غير القائمة على اللوم”. الهدف من هذه الجلسات هو فهم ما حدث بشكل كامل، من منظور الأنظمة والعمليات، وليس الأفراد.
طورنا قالبًا بسيطًا نستخدمه بعد كل حادثة، سواء كانت كبيرة أو صغيرة. شكله كالتالي:
# جلسة ما بعد الحادثة: [توقف خدمة تسجيل الدخول]
**التاريخ:** 2023-10-26
**المشاركون:** أبو عمر، سارة، أحمد، ليلى
## 1. ملخص المشكلة (ماذا حدث؟)
- وصف: توقفت خدمة تسجيل الدخول عن العمل لمدة 45 دقيقة.
- التأثير: لم يتمكن المستخدمون الجدد والحاليون من الوصول إلى حساباتهم.
## 2. التسلسل الزمني للأحداث (Timeline)
- 14:05: بدء ظهور تنبيهات بوجود أخطاء (5xx errors) في خدمة المصادقة.
- 14:10: تأكيد المشكلة من قبل فريق الدعم الفني.
- 14:20: تحديد أن السبب هو انتهاء صلاحية شهادة SSL داخلية.
- 14:40: تجديد الشهادة يدويًا.
- 14:50: عودة الخدمة للعمل بشكل كامل.
## 3. الأسباب الجذرية (لماذا حدث؟ - وليس من تسبب به)
- **السبب المباشر:** انتهاء صلاحية شهادة SSL.
- **السبب الجذري 1:** عدم وجود نظام تنبيهات تلقائي لمراقبة تواريخ انتهاء صلاحية الشهادات.
- **السبب الجذري 2:** عملية تجديد الشهادة يدوية وعرضة للنسيان.
## 4. الإجراءات التصحيحية والوقائية (ماذا سنفعل لمنع تكراره؟)
- [x] (مهمة عاجلة) إضافة مراقبة آلية لتنبيه الفريق قبل 30 يومًا من انتهاء أي شهادة. - المسؤول: أحمد.
- [ ] (مهمة) بحث وتطبيق حل لتجديد الشهادات بشكل تلقائي (e.g., Let's Encrypt). - المسؤول: سارة.
- [ ] (مهمة) توثيق عملية التجديد اليدوية كحل مؤقت. - المسؤول: ليلى.
## 5. ما الذي قمنا به بشكل جيد؟
- سرعة استجابة الفريق وتعاونه في تحديد المشكلة.
- التواصل الواضح والفعال أثناء الحادثة.
لاحظوا أن القالب لا يحتوي على خانة “المتسبب بالخطأ”. التركيز 100% على النظام والعملية.
الخطوة الثالثة: تشجيع الفضول وطرح الأسئلة ‘الغبية’
من أهم علامات البيئة الآمنة هي قدرة المبرمج المبتدئ (Junior) على طرح سؤال دون الخوف من أن يبدو “غبيًا”. دائمًا ما أقول لفريقي: “ما في سؤال غبي، في بس فرصة ضايعة للتعلم”.
كقائد، عندما يسألك شخص سؤالًا أساسيًا، ردة فعلك تحدد الكثير. بدلًا من قول “هذا شيء بديهي”، جرب أن تقول: “هذا سؤال ممتاز، دعنا نوضحه للجميع لأن الكثيرين قد يفكرون بنفس الشيء”. هذا يشجع على الفضول ويقتل الخوف.
الخطوة الرابعة: فصل الشخص عن المشكلة
تغيير بسيط في اللغة يمكن أن يصنع فرقًا كبيرًا. بدلًا من قول:
- “أنت كسرت الـ build.” ↔️ قل: “آخر commit كسر الـ build، تعالوا نلقي نظرة.”
- “كودك معقد جدًا.” ↔️ قل: “لم أفهم هذا الجزء من الكود، هل يمكنك شرحه لي؟ ربما يمكننا تبسيطه معًا.”
هذا الأسلوب يضعك أنت وزميلك في نفس الجانب ضد المشكلة، بدلًا من وضعكما ضد بعضكما البعض.
الثمار التي جنيناها: من الخوف إلى الإبداع
بعد تطبيق هذه المبادئ بصرامة لعدة أشهر، بدأنا نرى تغييرًا جذريًا في الفريق:
- تسارع الابتكار: أصبح المبرمجون يقترحون أفكارًا جريئة ويقومون بتجارب لإعادة هيكلة الأنظمة القديمة دون خوف.
- جودة أعلى: أصبحت مراجعات الكود (Code Reviews) أكثر فعالية، حيث شعر الجميع بالراحة في تقديم وتلقي النقد البنّاء.
- حل أسرع للمشاكل: صار الإبلاغ عن الأخطاء فور اكتشافها هو القاعدة، مما سمح لنا بحل المشاكل وهي صغيرة.
- معنويات مرتفعة: “صار الواحد ييجي على الشغل وهو مرتاح، مش حامل هم مين بده يلومه اليوم”. تحسن الجو العام في الفريق بشكل لا يصدق.
خلاصة أبو عمر: نصيحة من القلب
بناء ثقافة السلامة النفسية ليس رفاهية أو من “المهارات الناعمة” التي نتجاهلها. إنها أساس الفرق عالية الأداء، والمحرك الذي يدفع الابتكار والجودة. إنها الاستثمار الأكثر ربحية الذي يمكنك القيام به في فريقك.
قد يتطلب الأمر وقتًا وجهدًا وصبرًا، خاصة إذا كانت ثقافة اللوم متجذرة في شركتك. لكن ابدأ بنفسك، كن القدوة، احتفل بالشفافية، وتعامل مع كل خطأ على أنه درس مجاني ثمين.
تذكر دائمًا، الفريق الذي لا يرتكب أخطاء هو فريق لا يعمل شيئًا جديدًا. اسمح لفريقك بالفشل بأمان، وستندهش من المرتفعات التي سيصلون إليها. 💪
