بتذكرها زي كأنها مبارح. ليلة خميس، وكنا على وشك إطلاق ميزة جديدة ومهمة في النظام. السيرفرات جاهزة، القهوة شغالة، والمعنويات، يعني، نص نص. فجأة، بدأت التنبيهات تصرخ زي طفل صغير صحي من النوم голодным. النظام واقع. الموقع كله لا يعمل. الصمت عمَّ قناة السلاك (Slack) لثواني حسيتها دهر.
بعد ليلة طويلة من تصليح المشكلة، اجتمعنا الصبح في اجتماع “Post-mortem” أو “تشريح الخطأ”. بس بدل ما يكون جلسة للتعلم، تحول لا إرادياً لمحكمة. المدير التقني، اللي كان مضغوط من الإدارة العليا، بلّش يسأل بنبرة حادة: “مين اللي عمل commit للكود هاد؟”، “ليش ما حدا عمل مراجعة للكود صح؟”، “وين كان فلان لما صار هاد الأشي؟”.
شفت بعيني المبرمج المبتدئ اللي ارتكب الخطأ وهو ببلع ريقه، وجهه صار أصفر، وكأنه بده الأرض تنشق وتبلعه. الكل ساكت، كل واحد خايف يكون هو التالي في دائرة الاتهام. في هذيك اللحظة، ما كان الخطأ البرمجي هو المشكلة الأكبر. المشكلة الحقيقية كانت في الغرفة معنا: “ثقافة اللوم”. أدركت وقتها إنه إذا ما تغير هاد الأشي، إحنا مش بس رح نصلح أخطاء، إحنا رح نضل نعيش في جحيم من الخوف والصمت، وهذا هو الموت البطيء لأي فريق تقني.
ما هي “السلامة النفسية” وليش هي أهم من الـ Stand-up Meeting؟
خليني أبسطها. السلامة النفسية (Psychological Safety) مش إنك تكون لطيف مع الكل وتوزع ابتسامات مجانية. لا يا خوي. هي ببساطة بيئة عمل بحس فيها كل فرد في الفريق بالأمان الكافي عشان ياخد “مخاطرات محسوبة” بدون ما يخاف من العقاب أو الإهانة.
شو يعني مخاطرات محسوبة؟
- الاعتراف بالخطأ: “يا جماعة، أنا اللي دمجت الكود الغلط، وهاي هي الدروس اللي تعلمتها”.
- طرح سؤال “غبي”: “معلش تعيدوا شرح مفهوم الـ Microservices مرة تانية؟ مش فاهمها 100%”.
- تحدي الوضع الراهن: “بعرف إنه إحنا دايماً بنعمل هيك، بس شو رأيكم نجرب طريقة جديدة ممكن تكون أسرع؟”.
- تقديم فكرة مجنونة: “عندي فكرة ممكن تبين غريبة، بس ممكن تحل مشكلتنا…”.
في ثقافة اللوم، كل جملة من هدول ممكن تكلفك سمعتك أو حتى وظيفتك. أما في ثقافة السلامة النفسية، فهذه الجمل هي وقود الإبداع والنمو. الموضوع مش جديد، حتى شركة جوجل في “مشروع أرسطو” (Project Aristotle) الشهير تبعها، بعد ما حللت مئات الفرق على مدار سنين، اكتشفت إنه العامل الأول والأهم لنجاح أي فريق ما كان ذكاء أعضائه ولا خبرتهم، بل كان “السلامة النفسية”.
علامات الخطر: كيف تعرف إن فريقك يغرق في بحر الخوف؟
قبل ما نحكي عن الحلول، لازم تعرف تشخص المشكلة. هاي بعض الإشارات الحمرا اللي بتدل على غياب السلامة النفسية:
- صمت القبور في الاجتماعات: إذا كان القائد هو الوحيد اللي بيحكي، والباقي بهز راسه وبس، فاعرف إنه في مشكلة.
- ظاهرة “الاجتماع بعد الاجتماع”: الكلام الحقيقي والنقاشات المهمة بتصير في المطبخ أو في محادثات جانبية، مش في الاجتماع الرسمي.
- الأخطاء الخضراء (The Green-Shift): كل شي تمام، كل المشاريع خضرا في تقارير الحالة، وفجأة، بتكتشف كارثة قبل موعد الإطلاق بيومين. هذا معناه إنه الناس بتخبي المشاكل الصغيرة لحد ما تكبر وتنفجر.
- البحث عن كبش فداء: أول رد فعل عند حدوث مشكلة هو “مين المسؤول؟” بدل “شو اللي صار وكيف نصلحه؟”.
- قلة الأسئلة: خصوصاً من الأعضاء الجدد. إذا الموظف الجديد ما سأل أسئلة كثيرة في أول شهر، فهذا مش لأنه عبقري، هذا لأنه خايف يبين “غبي”.
كيف نبني جسور السلامة النفسية؟ خطوات عملية من الميدان
طيب يا أبو عمر، حكيت كثير ونظّرت علينا. كيف نصلح الوضع؟ الجواب هو بالتدريج وبخطوات عملية. الموضوع مش كبسة زر، هو تغيير ثقافي بياخد وقت وجهد، وهاي هي وصفتي اللي جربتها بنفسي.
الخطوة الأولى: القائد هو القدوة (أنت المراية)
إذا بدك فريقك يعترف بأخطائه، لازم تكون أول واحد يعترف بأخطائه. كقائد للفريق (Team Lead) أو مدير، أنت تحت المجهر. مرة كنت في اجتماع وكنت مصرّ على استخدام تقنية معينة للمشروع. بعد أسبوعين من التجارب، اكتشفنا إنها كانت قرار سيء جداً وأخرتنا عن الجدول الزمني.
في الاجتماع التالي، كان ممكن ألقي اللوم على صعوبة التقنية أو قلة التوثيق. لكني وقفت وقلت: “يا جماعة، أنا أتحمل مسؤولية هذا التأخير. تقديري للموقف كان خاطئ، واختياري للتقنية كان متسرع. أنا آسف، وهذا هو الدرس اللي تعلمته…”. الصمت اللي ساد الغرفة كان مختلف هالمرة. كان صمت احترام، مش صمت خوف. بعدها، واحد من المبرمجين قال: “في الحقيقة أنا كمان كان عندي شكوك بس خفت أحكي”. وكانت هاي بداية الحوار الحقيقي.
نصيحة أبو عمر: ابدأ اجتماعك القادم بمشاركة خطأ ارتكبته هذا الأسبوع، حتى لو كان بسيطاً، وشو تعلمت منه. شوف ردة فعل فريقك.
الخطوة الثانية: حوّل اللوم إلى فضول (من “مين؟” إلى “كيف؟”)
هاي أهم نقلة فكرية. لازم نبرمج عقولنا على إنه لما تصير مشكلة، هدفنا مش نلاقي المتهم، هدفنا نلاقي السبب الجذري في “النظام” (System) اللي سمح للخطأ يصير.
إحنا في البرمجة عنا أمر اسمه git blame، حتى اسمه يوحي باللوم! لكن المطورين الشاطرين بيستخدموه عشان يفهموا سياق الكود، مش عشان يلوموا زميلهم. لازم نطبق نفس المبدأ على كل عملياتنا.
استبدلنا اجتماعات “تشريح الجثة” المليئة بالاتهامات، بجلسات “التعلم من الحوادث” (Learning from Incidents) اللي بتتبع بروتوكول واضح وبدون لوم (Blameless Post-mortem). هدفها الإجابة على أسئلة محددة:
- ماذا حدث؟ (سرد زمني للأحداث بدون آراء شخصية).
- ما هو الأثر؟ (على المستخدمين، على النظام، على الشركة).
- ما هي العوامل المساهمة والأسباب الجذرية؟ (هنا التركيز على العمليات، الأدوات، نقص المعرفة، وليس على “إهمال فلان”).
- ما هي الإجراءات التصحيحية التي سنتخذها؟ (مهام واضحة ومسؤوليات محددة لمنع تكرار المشكلة).
هذا مثال بسيط على ملف Markdown ممكن نستخدمه كقالب:
# Incident Report: [اسم المشكلة] - [تاريخ]
## 1. Summary
* **Date:** 2023-10-26 14:30 UTC
* **Duration:** 45 minutes
* **Impact:** 50% of users experienced slow loading times on the dashboard.
* **Root Cause:** A database query with no index was deployed, causing high CPU load on the DB server.
## 2. Timeline (What Happened)
* 14:30 UTC - First alert received for high DB CPU.
* 14:35 UTC - On-call engineer (Omar) starts investigating.
* 14:45 UTC - The slow query was identified using the monitoring tool.
* 15:00 UTC - A hotfix to revert the change was deployed.
* 15:15 UTC - System recovered, services back to normal.
## 3. Root Cause Analysis (Why it Happened)
* The problematic code was part of a new feature.
* The code review process did not catch the missing index on the query.
* Our CI/CD pipeline does not have an automated step to check for slow queries before deployment.
## 4. Action Items (How We'll Fix It)
* [ ] **(Short-term)** Add an index to the `users` table. (Owner: @Layla, Due: EOD)
* [ ] **(Long-term)** Research and implement a static analysis tool for SQL queries in our CI pipeline. (Owner: @AbuOmar, Due: End of Sprint)
* [ ] **(Process)** Update the code review checklist to include a point about database query performance. (Owner: @TeamLead)
لاحظ كيف إن التركيز كله على “النظام” و”العمليات”، مش على المطور اللي كتب الكود.
الخطوة الثالثة: شجع الأسئلة والنقاش الصحي
لازم كقائد تعلنها صراحة: “ما في سؤال غبي”. ولما حدا يسأل سؤال “بسيط”، لا تجاوب بسخرية أو استعلاء. بالعكس، اشكره على سؤاله. قول جملة زي: “سؤال ممتاز، هاي فرصة حلوة نراجع المفهوم هاد للكل”.
بالنسبة للنقاش، شجع الاختلاف في الرأي. لما الكل يوافق على كلامك بسرعة، لازم تخاف مش تفرح. استخدم تقنيات مثل “محامي الشيطان” (Devil’s Advocate)، وعيّن شخص في كل اجتماع مهمته بس إنه ينتقد الفكرة المطروحة ويطلع نقاط ضعفها، عشان تتأكدوا إنكم فكرتوا في كل الزوايا.
النتيجة: من فريق صامت إلى خلية نحل مُبدعة
لما طبقنا هاي المبادئ، التغيير ما صار بيوم وليلة، بس كان واضح وعميق. الاجتماعات صارت أكثر حيوية. المبرمج المبتدئ اللي كان خايف، صار من أكثر الناس اللي بيقترحوا أفكار وبيكتشفوا الأخطاء في مراجعة الكود لأنه بطل يخاف. الأخطاء ما اختفت تماماً (وهذا مستحil)، بس صرنا نكتشفها أسرع بكثير، ونتعلم منها بشكل أكبر.
الأهم من كل هذا، صار في “روح” للفريق. صار الفريق كيان واحد بيشتغل لهدف واحد، مش مجموعة جزر منعزلة كل واحد همه يحمي حاله. الإنتاجية زادت، الإبداع زاد، والأهم، الناس صارت تيجي على الشغل وهي مبسوطة ومرتاحة نفسياً. 💡
خلاصة الكلام والنصيحة الأخيرة من أبو عمر
يا جماعة الخير، بناء البرمجيات هو عمل إنساني قبل ما يكون عمل تقني. وكبشر، إحنا بنبدع لما نحس بالأمان، وبننكمش على حالنا لما نحس بالخوف. السلامة النفسية مش رفاهية أو من “المهارات الناعمة” اللي بنحكي عنها وبس. هي أساس متين لأي فريق عالي الأداء.
إذا كنت قائد، مسؤوليتك الأولى هي رعاية هذه البيئة. ابدأ بنفسك، كن القدوة، استبدل اللوم بالفضول، واحتفل بالشفافية. وإذا كنت عضو في فريق، كن شجاعاً، ابدأ بطرح الأسئلة، اعترف بأخطائك الصغيرة، وساهم في بناء هذه الثقافة لبنة لبنة.
ابنوا ثقافة الثقة، مش ثقافة الخوف. وقتها بس، راح تشوفوا العجب من فرقكم، وراح تنتقلوا من جحيم اللوم إلى جنة الإبداع المشترك. 🙏
