فريقنا كان يدفن أخطاءه: كيف أنقذتنا ‘السلامة النفسية’ من جحيم الفشل الصامت؟

لما كان الصمت أعلى من صوت الكود

يا جماعة الخير، اسمحوا لي أرجع بالذاكرة كم سنة لورا. كنا شغالين على مشروع ضخم، نظام تحليل بيانات معقد لعميل مهم جدًا. أنا كنت قائد الفريق التقني، وكان معي مجموعة من ألمع المبرمجين الشباب اللي قابلتهم. كان كل شيء على الورق “تمام التمام”، والتقارير الأسبوعية اللي كانت توصلني من مدراء الفرق الفرعية كلها إيجابية: “الأمور تحت السيطرة يا أبو عمر”، “ماشيين حسب الخطة”.

لكن في إحساس غريب كان يراودني، زي ما بقولوا “في إشي غلط”. الكود كان يتراكم، بس جودته مش زي ما بدي. والميزات الجديدة كانت تطلع، لكن معها بتطلع أخطاء صغيرة وغريبة ما الها تفسير واضح. في اجتماع من الاجتماعات، كنت بستعرض جزء من النظام مع الفريق، ولاحظت سلوك غريب في واجهة المستخدم. إشي بسيط، بس بدل على مشكلة أعمق في قاعدة البيانات.

سألت سؤال مباشر: “يا شباب، حدا لاحظ هالمشكلة؟ شو سببها؟”.

صمت… صمت مطبق في الغرفة. الكل نزل راسه يتطلع في اللابتوب تبعه. شفت بعيوني نظرات الخوف على وجه واحد من المبرمجين الجدد، شب شاطر اسمه “سامر”. كان وجهه أصفر، وواضح إنه هو اللي كتب الكود المسبب للمشكلة. لكنه ما حكى ولا كلمة. اللي حكى هو مديره المباشر، وقال: “مشكلة بسيطة يا أبو عمر، بنحلها. خطأ غير مقصود”.

هنا كانت لحظة الحقيقة بالنسبة إلي. المشكلة ما كانت في البَغ (Bug) اللي شفته. المشكلة كانت في الصمت اللي تلاه. المشكلة كانت في خوف “سامر” من الاعتراف بخطئه. أدركت وقتها إن فريقنا عنده مرض خطير: ثقافة الخوف. فريقنا كان يدفن أخطاءه تحت سابع أرض، وكل واحد “بنظّف ورا الثاني” بصمت، على أمل إنه المصيبة ما تكبر وتنفجر في وجهنا كلنا. وهذا بالضبط ما كان سيحدث.

في تلك اللحظة، قررت أن أتجاهل الخطأ التقني مؤقتًا، وأعالج الخطأ الأكبر: “الخطأ الثقافي”. ومن هنا بدأت رحلتنا مع ما يسمى بـ “السلامة النفسية”.

ما هي “السلامة النفسية” في بيئة العمل؟ وليش هي مش مجرد “كلام تنمية بشرية”؟

لما نحكي “سلامة نفسية” (Psychological Safety)، كثير ناس بتفكرها مصطلح “كيوت” من قسم الموارد البشرية، يعني إنه نكون لطيفين مع بعض وما نزعّل حدا. لكن الحقيقة أعمق وأخطر من هيك بكثير، خصوصًا في عالمنا التقني.

تعريف بسيط وعملي

السلامة النفسية، ببساطة، هي الإيمان المشترك بين أعضاء الفريق بأنهم لن يتعرضوا للعقاب أو الإهانة أو التهميش عند طرح أفكار، أو أسئلة، أو مخاوف، أو حتى عند الاعتراف بالأخطاء. هي البيئة اللي فيها “سامر” كان المفروض يرفع إيده ويقول: “يا جماعة، أنا اللي كتبت هالكود، وواجهتني مشكلة في فهم المتطلبات، ومحتاج مساعدة”.

هي مش دعوة للفوضى أو التساهل، بل هي شرط أساسي للوصول لأعلى مستويات الأداء.

الفرق بين السلامة النفسية واللطف الزائد

وهنا نقطة مهمة جدًا. السلامة النفسية لا تعني تجنب النقاشات الصعبة أو النقد البنّاء. بالعكس تمامًا! هي اللي بتسمح بوجود هاي النقاشات أصلًا.

• بيئة “اللطف الزائد” (Artificial Harmony): الكل يبتسم، لا أحد ينتقد الآخر علنًا، الأخطاء يتم تجاهلها لتجنب الإحراج. النتيجة: أداء ضعيف ومشاكل متراكمة.
• بيئة “السلامة النفسية” (Psychological Safety): يمكن لأي شخص أن يقول لزميله (حتى لو كان أقدم منه): “أنا أختلف مع هذا الحل التقني، وأعتقد أن له مخاطر كذا وكذا”. يمكن للمبرمج أن يعترف: “لقد ارتكبت خطأ كلفنا يوم عمل كامل”. النقاش يكون عن الفكرة أو المشكلة، وليس عن الشخص.

دراسة “مشروع أرسطو” (Project Aristotle) الشهيرة اللي عملتها جوجل وجدت إن السلامة النفسية هي العامل الأهم رقم #1 في تحديد نجاح الفرق عالية الأداء. مش ذكاء الأفراد، ولا خبرتهم، بل شعورهم بالأمان للتعبير عن أنفسهم والمخاطرة.

علامات الخطر: كيف تعرف أن فريقك يدفن أخطاءه؟

قبل ما نصلح المشكلة، لازم نعرف نشخصها. هذه بعض العلامات اللي شفتها في فريقي، وممكن تكون موجودة في فريقك:

• صمت الاجتماعات: تسأل سؤالًا مفتوحًا مثل “ما رأيكم؟” أو “هل هناك أي مخاطر؟” ولا يجيب أحد، أو تسمع فقط إجابات عامة وموافقة دائمة.
• لعبة إلقاء اللوم (The Blame Game): عندما تحدث مشكلة، أول سؤال يُطرح هو “من فعل هذا؟” بدلًا من “ماذا حدث وكيف نصلحه؟”.
• المفاجآت المتأخرة: تكتشف المشاكل الكبيرة قبل موعد التسليم مباشرةً، لأن المبرمج كان خائفًا من الإبلاغ عنها عندما كانت صغيرة.
• قلة الأسئلة “الغبية”: لا أحد يسأل أسئلة أساسية أو يطلب توضيحًا، خوفًا من أن يبدو غير كفؤ.
• التحفظ في مراجعات الكود (Code Reviews): المراجعات تكون سطحية (مثلاً: “الكود نظيف” أو “يعمل بشكل جيد”) دون نقاش حقيقي حول التصميم أو الحلول البديلة.
• التردد في التجربة والابتكار: لا أحد يقترح أفكارًا جديدة أو “مجنونة” قد تفشل، لأن ثقافة الفريق لا تحتمل الفشل.

خطوات عملية لبناء ثقافة السلامة النفسية (من أرض المعركة)

طيب يا أبو عمر، حكيتلنا القصة وشخصت المشكلة، كيف الحل؟ الحل مش كبسة زر، هو عملية مستمرة. هذه الخطوات اللي طبقناها وغيرت فريقنا 180 درجة.

1. القائد هو القدوة: اعترف بأخطائك أولاً

هذه أهم خطوة. لا يمكنك أن تطلب من فريقك أن يكونوا ضعفاء وصادقين إذا كنت أنت نفسك ترتدي قناع “البطل الخارق الذي لا يخطئ”. بعد حادثة “سامر”، في الاجتماع التالي، بدأت حديثي قائلاً:

“يا جماعة، أريد أن أعتذر. في المرحلة الأولى من المشروع، أنا من أصر على استخدام تقنية X، والآن اكتشفت أنها لم تكن الخيار الأمثل وتسببت لنا في بعض المشاكل في الأداء. هذا خطئي في التقدير، وأنا أتحمل مسؤوليته. الآن، دعونا نفكر معًا كيف يمكننا تحسين الوضع.”

الصمت الذي ساد الغرفة هذه المرة كان مختلفًا. لم يكن صمت خوف، بل صمت دهشة. لقد رأوا قائدهم يعترف بخطئه علنًا. هذا يعطي إشارة قوية للجميع: “لا بأس أن تكون إنسانًا هنا. لا بأس أن تخطئ”.

2. غيّر طريقة تعاملك مع الفشل: من اللوم إلى التعلم

استبدلنا فورًا ثقافة “من المخطئ؟” بثقافة “ماذا تعلمنا؟”. طبقنا مفهومًا يسمى “Postmortems without Blame” (تشريح الأخطاء دون لوم). بعد كل مشكلة كبيرة (سيرفر وقع، بَغ خطير وصل للإنتاج)، كنا نعقد اجتماعًا ليس لهدف معاقبة أحد، بل للإجابة على هذه الأسئلة:

1. ماذا كان الأثر؟ (ماذا حدث بالضبط؟)
2. ما هي العوامل التي ساهمت في حدوث المشكلة؟ (نركز على الأنظمة والعمليات، وليس الأشخاص)
3. ماذا تعلمنا من هذه التجربة؟
4. ما هي الإجراءات التي سنتخذها لمنع تكرار هذه المشكلة في المستقبل؟

حتى أننا وضعنا “قاعدة” رمزية في هذه الاجتماعات. يمكننا أن نكتب شيئًا يشبه الكود لترسيخ الفكرة:

// Function to conduct our team's postmortem analysis
function conductBlamelessPostmortem(incident) {
    console.log("Incident Analysis: " + incident.id);

    // 👎 This is forbidden (ممنوع منعًا باتًا)
    // const guiltyPerson = findWhoToBlame(incident.logs);
    // punish(guiltyPerson);

    // 👍 This is what we do (هذا هو شغلنا الصح)
    const timeline = buildEventTimeline(incident.logs);
    const contributingFactors = analyzeSystemicCauses(timeline); // e.g., "Lack of automated testing", "unclear documentation"
    const lessonsLearned = extractLessons(contributingFactors);
    const actionItems = createActionItems(lessonsLearned); // e.g., "Implement new integration test", "Update deployment checklist"

    console.log("Focus is on future improvement, not past blame.");
    return {
        summary: incident.summary,
        actionItems: actionItems
    };
}

هذا التحول البسيط جعل الناس يتسابقون للإبلاغ عن المشاكل، لأنهم عرفوا أنها فرصة للتعلم والتحسين، وليست فرصة “للبهدلة”.

3. شجع الفضول والأسئلة “الغبية”

بدأت أمارس عادة بسيطة في كل اجتماع. عندما يسأل أحدهم سؤالًا، حتى لو كان بسيطًا جدًا، كنت أقول: “شكرًا لسؤالك، هذه نقطة مهمة جدًا”. هذا يشجع الآخرين على السؤال. أصبحت أطرح بنفسي أسئلة “غبية” عن قصد لأكسر حاجز الخوف: “يا جماعة، معلش حدا يرجع يشرحلي كيف هادي الجزئية بتشتغل؟ أنا ناسيها”.

نصيحة عملية: خصص أول 5 دقائق من الاجتماعات التقنية لـ “الأسئلة المفتوحة” حيث يمكن لأي شخص أن يسأل عن أي شيء يواجهه، دون حكم مسبق.

4. استمع بفعالية واطلب الرأي المعارض

عندما تقترح فكرة، لا تطلب الموافقة. اطلب النقد. غيّر سؤالك من:

“هل الجميع موافق على هذا التصميم؟”

إلى:

“ما هي المخاطر التي لا أراها في هذا التصميم؟ من منكم يرى طريقة أفضل؟ أريد أن أسمع الرأي المعارض”.

هذا يمنح الإذن للناس بالتفكير النقدي ويجعلهم يشعرون بأن رأيهم مهم، حتى لو كان مخالفًا لرأي القائد.

السلامة النفسية والكود: كيف يترجم هذا إلى جودة برمجية؟

قد يقول قائل: “كل هذا كلام جميل، لكن كيف يؤثر على الكود الذي نكتبه؟”. التأثير مباشر ومذهل:

• مراجعات كود (Code Reviews) أفضل: عندما يشعر المراجع بالأمان، لن يتردد في الإشارة إلى مشكلة حقيقية في التصميم أو منطق الكود، بدلًا من الاكتفاء بالتعليقات السطحية. هذا يمنع وصول الديون التقنية (Technical Debt) إلى مراحل متقدمة.
• إصلاح أسرع للأخطاء: يتم الإبلاغ عن الأخطاء فور اكتشافها، عندما يكون إصلاحها سهلًا ورخيصًا، بدلًا من تركها تتفاقم وتنفجر في وجه العميل.
• ابتكار حقيقي: يشعر المطورون بالأمان لتجربة تقنيات جديدة أو اقتراح حلول غير تقليدية. بعض أفضل الأفكار تأتي من مقترحات “مجنونة” قد تبدو محفوفة بالمخاطر في البداية.
• توثيق وتعاون أفضل: الناس لا يخافون من طلب المساعدة أو القول “أنا لا أعرف”، مما يؤدي إلى تبادل المعرفة بشكل أفضل وتوثيق العمليات بشكل أوضح للجميع.

خلاصة أبو عمر: من جحيم الفشل الصامت إلى جنة الإبداع المشترك 💡

الرحلة لم تكن سهلة، وتطلبت وقتًا وصبرًا وتغييرًا حقيقيًا في سلوكي أولًا قبل أن أطلبه من فريقي. لكن النتيجة كانت تستحق كل هذا العناء. تحولنا من فريق يدفن أخطاءه في صمت وخوف، إلى فريق يحتفل بالتعلم من الفشل، فريق يتناقش بحدة وشغف حول الأفكار وليس الأشخاص، فريق ينتج برمجيات عالية الجودة ليس لأن أفراده عباقرة، بل لأنهم يعملون في بيئة تسمح لهم بأن يكونوا أفضل نسخة من أنفسهم.

إذا كنت قائد فريق أو حتى عضوًا فيه وتشعر بأن الصمت أعلى من صوت الكود، فربما حان الوقت لتطرح السؤال الأهم: هل بيئتنا آمنة بما يكفي للاعتراف بالخطأ؟

تذكر دائمًا، الخطأ التقني يمكن إصلاحه بسطرين كود، لكن الخطأ الثقافي قد يهدم مشروعًا بأكمله. ابدأ بنفسك، وكن القدوة، وشاهد كيف يتحول الخوف الصامت إلى إبداع مشترك. 🚀