أذكرها وكأنها البارحة. كنا في اجتماع الطوارئ لمناقشة “مشروع الزيتونة”، وهو نظام ذكاء اصطناعي كنا نبنيه لشهور طويلة. قبل يومين فقط من موعد الإطلاق التجريبي، اكتشفنا خطأً كارثياً (Bug) في قلب النظام، خطأ كان يهدد بنسف المشروع بأكمله. كان التوتر في الغرفة “مكهرباً”، والعيون تترقب من سيتحمل اللوم.
بعد ساعات من البحث والتحليل، عدنا في سجل الأكواد (Git history) لأسابيع إلى الوراء. الصدمة كانت أن أصل المشكلة كان موجوداً في كود كتبه أحد المطورين المبتدئين، خلينا نسميه “سالم”. لكن الأدهى من ذلك، أن سالم كان قد أشار بشكل خجول ومتردد إلى “احتمالية وجود مشكلة” أثناء جلسة مراجعة الكود (Code Review) قبل شهر، لكنه صمت بسرعة عندما قابله أحد كبار المطورين بنبرة حادة وانتقاد لاذع أمام الجميع.
في تلك اللحظة، لم أشعر بالغضب من سالم، بل شعرت بغصة في حلقي. يا زلمة، المشكلة ما كانت في كود سالم، المشكلة كانت فينا إحنا! في ثقافتنا التي جعلت مطوراً ذكياً يبتلع لسانه خوفاً من الإحراج أو العقاب. كنا نعيش في “جحيم الصمت القاتل”، حيث الخوف من الخطأ أقوى من الرغبة في النجاح. كانت تلك هي اللحظة التي أدركت فيها أننا لا نحتاج إلى إصلاح الكود فقط، بل نحتاج إلى إصلاح “روح” الفريق. وهنا بدأت رحلتنا مع مفهوم غيّر كل شيء: الأمان النفسي.
ما هو الأمان النفسي (Psychological Safety) وليش هو ‘أهم إشي’؟
ببساطة، الأمان النفسي هو الإيمان المشترك بين أعضاء الفريق بأن البيئة آمنة للمخاطرة على المستوى الشخصي. يعني أنك تستطيع أن تطرح سؤالاً “غبياً”، أو تعترف بأنك لا تعرف شيئاً، أو تقترح فكرة مجنونة، أو حتى تنتقد فكرة المدير، كل ذلك دون أن تخاف من أن يتم توبيخك، أو تهميشك، أو معاقبتك.
لا، هذا لا يعني أن نكون “لطيفين” طوال الوقت ونتجنب النقاشات الصعبة. على العكس تماماً! الأمان النفسي هو ما يسمح لنا بخوض تلك النقاشات الصعبة بصدق وشفافية لأننا نثق بأن الهدف هو مصلحة المشروع، وليس تسجيل النقاط على بعضنا البعض.
تخيل الأمان النفسي كشبكة أمان تحت بهلوان السيرك. كلما كانت الشبكة أقوى، زادت جرأة البهلوان على تجربة حركات جديدة ومدهشة. فريقك هو البهلوان، والأفكار المبدعة هي الحركات المدهشة. بدون شبكة أمان، سيكتفي الفريق بالحركات الآمنة والمملة التي يعرفها.
علامات الخطر: كيف تعرف أن فريقك يفتقر للأمان النفسي؟
قبل أن نبني الحل، علينا تشخيص المشكلة. هذه بعض العلامات الحمراء التي كانت تصرخ في فريقنا، وربما تجدها في فريقك أيضاً:
- الصمت المطبق في الاجتماعات: عندما يطرح المدير سؤالاً، والجميع يهز رأسه موافقاً دون أي نقاش أو استفسار. هذه ليست علامة على الاتفاق، بل علامة على الخوف.
- لعبة إلقاء اللوم (The Blame Game): عند حدوث خطأ، يكون السؤال الأول هو “مين المسؤول؟” بدلاً من “كيف حدث هذا، وكيف نمنع تكراره؟”.
- الخوف من التجربة والابتكار: المطورون يلتصقون بالتقنيات القديمة والأساليب المجرّبة لأن أي محاولة لاستخدام شيء جديد قد تفشل، والفشل يعني اللوم.
- إخفاء الأخطاء تحت السجادة: مثلما فعل “سالم”، يتم التستر على الأخطاء الصغيرة والمشاكل المحتملة أملاً في ألا يلاحظها أحد، حتى تنفجر وتتحول إلى كوارث.
- كثرة المحادثات الجانبية (النميمة): الآراء الحقيقية والملاحظات الهامة لا تُقال في الاجتماعات الرسمية، بل تُهمس في محادثات ثنائية أو على برامج الدردشة.
خطوات عملية لبناء ثقافة الأمان النفسي: ‘وصفة أبو عمر’ الخاصة
بعد كارثة “مشروع الزيتونة”، قررت أن التغيير يجب أن يبدأ. لم يكن الأمر سهلاً أو سريعاً، بل كان بناءً تدريجياً للثقة. إليكم وصفتي العملية التي طبقناها خطوة بخطوة.
1. القائد هو القدوة: اعترف بأخطائك أولاً
لا يمكنك أن تطلب من فريقك أن يكون شفافاً وصريحاً إذا كنت أنت نفسك ترتدي قناع الكمال. كقائد تقني، بدأت عمداً بمشاركة أخطائي. في أحد الاجتماعات الصباحية، قلت للفريق: “يا جماعة، الكود اللي عملتله push مبارح بالليل كان فيه مشكلة أداء خطيرة، وأنا بعتذر لأني استعجلت وما عملت اختبارات كافية. تعلمت من هالتجربة إنه لازم دايماً… والآن أنا أعمل على إصلاحها.”
كان الصمت في البداية غريباً، ثم بدأ الفريق يرى أن الاعتراف بالخطأ ليس نهاية العالم، بل هو بداية للتعلم. عندما تكون أنت، كقائد، أول من يعترف بالضعف، فإنك تعطي الإذن للآخرين بأن يكونوا بشراً أيضاً.
2. غيّر لغة الحوار: من “لماذا؟” إلى “ماذا لو؟”
الكلمات التي نستخدمها تشكل واقعنا. قمنا بحملة واعية لتغيير لغة النقد إلى لغة الفضول، خصوصاً في جلسات مراجعة الكود التي كانت ساحة معركة.
- بدلاً من أن تقول: “هذا الكود غير فعال وسيئ.”
- جرّب أن تقول: “أنا مهتم أفهم طريقة تفكيرك هنا. ممكن تشرحلي ليش اخترت هذا الأسلوب؟ فكرت في بديل مثل […] لأنه قد يحسن الأداء.”
الفرق شاسع. الأولى هجوم، والثانية دعوة للحوار والتعلم المشترك. هذا التغيير البسيط يزيل الشعور بالدفاعية ويفتح الباب للنقاش البنّاء.
3. حوّل الفشل إلى بيانات للتعلّم (Failure as Data)
استلهمنا من كبرى الشركات التقنية مفهوم “Blameless Postmortems” أو “تشريح الأخطاء دون لوم”. عندما تحدث مشكلة كبيرة الآن، لا نسأل “من فعلها؟” بل نجتمع للإجابة على هذه الأسئلة:
- ماذا حدث؟ (تسلسل زمني دقيق للوقائع)
- ماذا كان الأثر؟ (على النظام، على المستخدمين)
- ما هي الأسباب الجذرية؟ (ليس فقط السبب السطحي، بل الأسباب النظامية: نقص في الاختبارات؟ عملية مراجعة ضعيفة؟ ضغط في الوقت؟)
- ماذا سنتعلم من هذا؟ وما هي الإجراءات التي سنتخذها لمنع تكرار المشكلة؟ (مثال: إضافة automated tests، تحسين نظام المراقبة، تخصيص وقت أطول لمراجعة الكود).
لقد حولنا الأخطاء من مصدر للخزي إلى أثمن مصدر للبيانات لتحسين نظامنا وعملياتنا. يمكن حتى تمثيل هذه الفلسفة بشكل رمزي في الكود:
// A metaphorical representation of our team's process
function tryToLaunchFeature(feature) {
try {
// Attempt to build and deploy the new feature
console.log(`🚀 Launching: ${feature.name}...`);
deploy(feature);
console.log("✅ Success!");
} catch (error) {
// An incident occurred! Don't panic, don't blame.
console.error(`🔥 Incident detected: ${error.message}`);
// Step 1: Stabilize the system
rollback();
// Step 2: Run a blameless postmortem to learn
const learnings = runBlamelessPostmortem(error);
// Step 3: Apply learnings to improve our process
improveProcess(learnings.actionItems);
} finally {
// Acknowledge the effort, regardless of the outcome
appreciateTeamEffort();
}
}
4. شجع الأسئلة “الغبية” واحتفل بالفضول
أعلنتها قاعدة رسمية في فريقنا: “لا يوجد شيء اسمه سؤال غبي”. السؤال الغبي الحقيقي هو السؤال الذي لم يُطرَح. عندما يسأل مطور مبتدئ سؤالاً أساسياً، كنت أحرص على شكره علناً: “شكراً جزيلاً على سؤالك يا محمد، هذه نقطة ممتازة ومهمة، وبالتأكيد هناك آخرون في الفريق كانوا يفكرون بنفس الشيء.”
هذا التشجيع البسيط يخلق بيئة يشعر فيها الجميع بالراحة لطرح الأسئلة، مما يمنع سوء الفهم ويقضي على الافتراضات الخاطئة في مهدها.
5. الوضوح يقتل الخوف
جزء كبير من الخوف يأتي من الغموض. عندما لا يعرف أعضاء الفريق ما هو متوقع منهم بالضبط، أو من هو المسؤول عن ماذا، فإنهم يترددون في اتخاذ أي مبادرة. قمنا بجهد كبير لتوضيح الأدوار والمسؤوليات في كل مشروع. استخدمنا أدوات بسيطة مثل مصفوفة RACI (Responsible, Accountable, Consulted, Informed) وحددنا أهدافاً واضحة وقابلة للقياس لكل مهمة. عندما يعرف الجميع ما هو دوره وما هي حدود صلاحياته، تزداد ثقتهم في التحرك واتخاذ القرارات.
الخلاصة: الأمان النفسي ليس رفاهية، بل هو أساس النجاح 🚀
تحويل ثقافة فريقنا لم يحدث بين عشية وضحاها، بل كان رحلة طويلة من بناء الثقة، خطوة بخطوة، واجتماعاً تلو الآخر. لكن النتائج كانت مذهلة. الفريق الذي كان صامتاً ومشلولاُ بالخوف تحول إلى خلية نحل من النقاشات الصحية، والأفكار المبتكرة، والتعاون الحقيقي. الأخطاء ما زالت تحدث، فنحن بشر، لكنها الآن تُكتشف بسرعة، تُناقش بشفافية، وتُحوّل إلى دروس قيمة.
الأمان النفسي ليس من “المهارات الناعمة” أو الرفاهيات، بل هو بنية تحتية أساسية لأي فريق عالي الأداء، خاصة في مجال التكنولوجيا الذي يتغير بسرعة ويتطلب التجربة والتعلم المستمر.
💡 نصيحتي الأخيرة لك: لا تنتظر أن يبدأ مديرك. سواء كنت قائداً أو عضواً في الفريق، يمكنك أن تكون أنت الشرارة. ابدأ بنفسك. في اجتماعك القادم، كن أنت الشخص الذي يطرح سؤالاً لم يجرؤ غيرك على طرحه. عندما يرتكب زميلك خطأً، كن أول من يقول “لا بأس، دعنا نرى كيف يمكننا إصلاحه معاً”. كن أنت الشخص الذي يشكر زميلاً على فكرة جديدة حتى لو لم تكن مثالية. هذه الأفعال الصغيرة والمعدية هي التي تبني الجسور، وتزرع الثقة، وتحول مكان عملك من ساحة للخوف إلى واحة للإبداع.
