> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # التفاحة الفاسدة Bad Apple: كيف يغير شخص واحد أداء الفريق - URL: https://arabroot.io/articles/التفاحة-الفاسدة-bad-apple-في-الفريق-التقني/ - Published: 2026-10-31T09:52:21.000Z - Updated: 2026-10-31T10:51:46.000Z - Description: ما تقوله الأبحاث عن الموظف الذي يخفض أداء فريق كامل بسلوكه، وكيف تفرق بينه وبين فريق مؤذ أو أداء ضعيف، وما تفعله في الاجتماع وبعده قبل أن يغادر أفضل من عندك. - Author: فريق عرب رووت - Tags: الأدلة التقنية, القيادة التقنية لنفرض أنك قائد فريق Team Lead في شركة ناشئة تبني منصة حجوزات للعيادات، وفريقك سبعة مهندسين، وكانت الأمور تسير بشكل جيد طوال السنة الماضية، ثم لاحظت في الأشهر الأربعة الأخيرة أشياء صغيرة متفرقة: طلبات الدمج Pull Requests تنتظر المراجعة أياماً بدل ساعات، واجتماع المراجعة الدورية Retrospective صار صامتاً، والمهندسة التي انضمت قبل ستة أشهر لم تعد تسأل في قناة الفريق Channel، وأحد أفضل مهندسيك طلب منك في الاجتماع الفردي One-on-One أن ينتقل إلى فريق آخر «لأسباب شخصية». وعندما جمعت هذه الأشياء الصغيرة بجانب بعضها وجدت أن أغلبها يمر بشخص واحد: مهندس أول Senior Engineer انضم مبكراً ويعرف النظام أكثر من الجميع، يكتب في المراجعة تعليقات مثل «مين كتب هذا؟»، ويقول في كل اجتماع «ما في فايدة نناقش، الإدارة بتقرر اللي تبغاه»، ويترك المهام المملة والصعبة لغيره. والسؤال الذي يواجهه كل قائد في هذا الموقف: هل يمكن فعلاً أن يخفض شخص واحد أداء فريق كامل؟ أم أنك تبالغ لأنك متضايق منه؟ وإذا كان الجواب نعم، فما الذي تفعله دون أن تظلمه، ودون أن تحوله إلى «الشرير» في قصة الفريق قبل أن تفهم ما يحدث معه؟ وهذا ما يسميه الناس «التفاحة الفاسدة» Bad Apple، من المثل الإنجليزي الذي يقول إن تفاحة فاسدة واحدة تفسد الصندوق كله. وفي هذا المقال سوف نرى ما تقوله الأبحاث عن هذا المثل، ولماذا يتأثر الفريق بشخص واحد أكثر مما نتوقع، وكيف تفرق بين التفاحة الفاسدة وبين فريق مؤذ أو زميل صعب أو موظف ضعيف الأداء، وماذا تفعل في الاجتماع نفسه وبعده، وما الذي يحدث عندما تنتظر. وهذا المقال هو أول مقالات مرحلة الأداء الضعيف في مسار القيادة التقنية، وبعده مقالات عن تشخيص سبب ضعف الأداء، وجودة العمل الضعيفة، والقرارات التقنية السيئة، ومشكلة السلوك Attitude، والزميل الضعيف عندما لا تكون مديره، وخطة تحسين الأداء PIP، وإنهاء الخدمة Termination. وأما الفريق المؤذي كله والزميل الصعب في علاقتك به شخصياً فلهما مقالان منشوران نشير لهما في الطريق ولا نكرر ما فيهما. وسوف نناقش في هذا المقال ما يلي: - ما وجده Felps وزميلاه عام 2006، وتجربة الممثل التي خفضت أداء المجموعات بين 30% و40%. - السلوكيات الثلاثة التي تصنع التفاحة الفاسدة، بأمثلة من الفرق التقنية. - لماذا يتأثر الفريق بشخص واحد، وكيف ينتقل السلوك من شخص إلى آخر. - كيف تفرق بين التفاحة الفاسدة والفريق المؤذي والزميل الصعب والأداء الضعيف والفترة الصعبة. - ثمن الانتظار، ولماذا يقول كتاب Software Engineering at Google إن الأمل ليس استراتيجية. - ثلاث حالات: شركة ناشئة، وشركة متوسطة فيها «عبقري صعب»، وجهة شبه حكومية فيها موظف فقد الحماس. - ما يفعله القائد في الاجتماع نفسه، والمحادثة الخاصة، وحماية الفريق أثناء ذلك. - إذا كنت تخشى أن تكون أنت التفاحة الفاسدة، وسجل الأثر كأداة عملية. ## ماذا تقول الأبحاث؟ (Felps, Mitchell and Byington, 2006) أشهر عمل علمي عن هذا الموضوع هو [مراجعة نشرها Will Felps وTerence Mitchell وEliza Byington عام 2006](https://doi.org/10.1016/S0191-3085%2806%2927005-9?ref=arabroot.io) في مجلة Research in Organizational Behavior بعنوان «كيف ومتى ولماذا تفسد التفاحات الفاسدة الصندوق». وكان سؤالهم بسيطاً في ظاهره: الأبحاث عن الفرق تقول منذ عقود إن المجموعة أقوى من الفرد، وإن الفريق يضغط على من يخرج عن قواعده حتى يعود إليها، فهل يحدث العكس أيضاً؟ هل يستطيع فرد واحد سلبي أن يغير المجموعة؟ وجمع الباحثون ما وجدوه في دراسات سابقة عن الفرق، وكثير منه كان مدفوناً في جداول الارتباط والهوامش كما قال Felps لاحقاً، ووصلوا إلى ثلاثة أنواع من السلوك تظهر مرة بعد مرة مرتبطة بضعف أداء الفريق كله، وليس أداء صاحبها فقط. ثم شرح Felps في [حلقة من برنامج This American Life](https://www.thisamericanlife.org/370/ruining-it-for-the-rest-of-us?ref=arabroot.io) عام 2008 تجربة أجراها لاختبار الفكرة: استأجر ممثلاً شاباً اسمه Nick، ووضعه في مجموعات من أربعة طلاب جامعيين، والثلاثة الآخرون لا يعرفون أنه ممثل، وأعطى كل المجموعات مهمة إدارية مدتها حوالي 45 دقيقة مع جائزة للمجموعة الأفضل. وفي كل مجموعة كان Nick يلعب واحداً من ثلاثة أدوار: من يهين الآخرين ويرفض أفكارهم دون أن يقترح شيئاً، أو من لا يبالي فيضع رجليه على الطاولة ويرسل رسائل من جواله، أو المتشائم الذي يقول إن المهمة مملة ويشكك في قدرة المجموعة ثم يضع رأسه على الطاولة. والنتيجة، كما قال Felps، أن المجموعات التي كان فيها Nick أدت أسوأ بنسبة بين 30% و40% من المجموعات التي لم يكن فيها، مع أن بعض هذه المجموعات كان فيها طلاب أذكياء ومتمكنون. والأهم من الرقم ما رآه في التسجيلات: أعضاء المجموعة لم يكتفوا بالتأثر بسلوك Nick، وإنما بدأوا يقلدونه. فعندما كان يسخر من الآخرين صاروا يسخرون من بعضهم، وعندما كان لا يبالي قال أحدهم في النهاية «خلونا نخلص ونطلع» فكتبوا أي إجابات، وعندما كان متشائماً انتهت المجموعة كلها برؤوسها على الطاولة. وتوقف الناس عن مشاركة المعلومات، وتواصلوا أقل، وتجادلوا أكثر. وهذا ما يجعل التفاحة الفاسدة مختلفة عن الموظف الضعيف: الضعيف يؤثر على عمله، أما التفاحة الفاسدة فتغير سلوك من حولها. وقبل أن نبني على هذه النتيجة، لاحظ حدودها، وهو ما قاله Felps نفسه في الحلقة: هذه تجربة مخبرية مدتها 45 دقيقة، مع طلاب وليس مع فريق يعمل معاً منذ سنوات، والفرق الحقيقية قد تتصرف بطريقة مختلفة. لذلك لا نأخذ الرقم 30% إلى 40% على أنه ما سيحدث لفريقك، وإنما نأخذ منها الآلية: السلوك السلبي ينتقل، والفريق لا يمتصه تلقائياً كما كنا نظن. ## السلوكيات الثلاثة في فريق تقني (Three Behaviours) صنفت المراجعة سلوك التفاحة الفاسدة في ثلاثة أنواع، وهي تصف أفعالاً وليس شخصيات، وهذا الفرق مهم جداً لما سنفعله لاحقاً، لأنك تستطيع أن تتحدث مع شخص عن فعل محدد ويستطيع أن يغيره، ولكنك لا تستطيع أن تتحدث معه عن «شخصيته السلبية». ![ثلاث بطاقات للسلوكيات التي تصنع التفاحة الفاسدة مع أمثلة تقنية: حجب الجهد Withholding Effort مثل أخذ التذكرة السهلة وترك الصعبة وطلب دمج بلا اختبارات والتأخر في المناوبة، والمزاج السلبي المستمر Negative Affect مثل قول ما في فايدة في كل اجتماع مراجعة والتشكيك في كل خطة ونقل الإحباط للجدد، وخرق قواعد التعامل Interpersonal Deviance مثل التعليق الساخر على الشخص في مراجعة الكود والاستهزاء بالسؤال في القناة ورفض الفكرة دون بديل](https://arabroot.io/content/images/2026/10/bad-apple-01-three-behaviours.webp) السلوك هو الذي يوصف، والسلوك الواحد قد يأتي من مهارة ناقصة أو رغبة ضعيفة أو بيئة سيئة - **حجب الجهد Withholding Effort:** أن يعطي الشخص أقل مما يستطيع بشكل متكرر، فيأخذ التذاكر Tickets السهلة ويترك الصعبة، ويرسل طلب دمج بلا اختبارات Tests وكأن إكمالها مسؤولية غيره، ويتأخر في الرد أثناء المناوبة On-call فيضطر زميله لتغطيته. وفي الفريق التقني يظهر هذا السلوك بوضوح لأن العمل مرئي في نظام التذاكر وفي سجل Git، ولكنه يتأخر في الظهور في التقييم لأن عدد التذاكر المغلقة قد يبقى معقولاً. - **المزاج السلبي المستمر Negative Affect:** أن يعبر الشخص باستمرار عن التشاؤم والتذمر والإحباط، فيقول في كل خطة «ما راح تمشي»، وفي كل قرار «الإدارة ما تفهم»، ويحكي للمنضمين الجدد أن الشركة لا أمل فيها. وهذا السلوك أصعب في الملاحظة من الأول، لأن كل جملة وحدها تبدو رأياً عادياً، ولكن أثرها المتراكم على طاقة الفريق كبير. - **خرق قواعد التعامل Interpersonal Deviance:** أن يتجاوز الشخص قواعد الاحترام المتفق عليها في الفريق، فيعلق في مراجعة الكود Code Review على كاتب الكود بدل الكود نفسه، ويقاطع زملاءه، ويستهزئ بالسؤال في القناة، ويرفض أفكار غيره دون أن يقدم بديلاً. وهذا أوضح الأنواع الثلاثة وأسرعها أثراً، وهو الذي يجعل الناس يتوقفون عن السؤال. وفي حالتنا، أي فريق منصة الحجوزات، نجد الأنواع الثلاثة في شخص واحد: تعليقات «مين كتب هذا؟» من النوع الثالث، و«ما في فايدة نناقش» من النوع الثاني، وترك المهام الصعبة من النوع الأول. وهذا ليس نادراً، فالأنواع الثلاثة تأتي كثيراً معاً، ولكن لكل واحد منها طريقة مختلفة في الحديث عنه، ولكل واحد منها أسباب محتملة مختلفة، وهو ما سنراه عندما نصل إلى التشخيص. ## لماذا يتأثر الفريق بشخص واحد؟ (Why It Spreads) قد يتساءل البعض: إذا كان في الفريق ستة مهندسين جيدين وواحد سلبي، فلماذا لا يغلب الستة الواحد؟ والإجابة على ذلك أن الفريق لا يعمل بالتصويت، وإنما بالتفاعل، والسلوك السلبي يدخل في كل تفاعل يكون صاحبه طرفاً فيه. فإذا كان هو أكثر من يعرف النظام القديم، فكل من يحتاج معلومة يمر به، وإذا كان مراجعاً لطلبات الدمج، فكل كود يكتبه الفريق يمر بتعليقاته. وتصف المراجعة ثلاث طرق يرد بها أعضاء الفريق على هذا السلوك، وكلها تضر الفريق: ![سلسلة من ثلاث مراحل: سلوك متكرر مثل السخرية في المراجعة والتذاكر المتروكة وقول ما في فايدة، ثم ردود فعل الفريق وهي الدفاعية Defensiveness والانسحاب Withdrawal والالتفاف Working Around والتقليد Contagion، ثم النتيجة وهي إنجاز أقل في كل دورة عمل Sprint وجودة أقل لأن المراجعة صارت شكلية وأفضل الناس يطلبون النقل أو يغادرون Attrition، ومربع أسفلها يقول إن ما يقطع السلسلة قائد يسأل ويشرك الجميع ويهدئ الخلاف ثم محادثة خاصة واضحة](https://arabroot.io/content/images/2026/10/bad-apple-02-spillover.webp) الفريق لا يمتص السلوك السلبي، وإنما يرد عليه بطرق تضره، ثم يقلده - **الدفاعية Defensiveness:** عندما يتوقع المهندس تعليقاً ساخراً على طلب الدمج، يقضي وقتاً أطول في حماية نفسه منه، فيكتب شرحاً طويلاً يبرر كل سطر، أو يؤجل إرسال الطلب حتى يصبح كبيراً جداً، وكلاهما يجعل المراجعة أبطأ وأسوأ. - **الانسحاب Withdrawal:** يتوقف الناس عن السؤال وعن مشاركة المعلومات وعن اقتراح الأفكار في الاجتماعات، لأن الكلام صار له ثمن. وهذا بالضبط عكس ما وجدته Google في [دراستها لفاعلية الفرق](https://rework.withgoogle.com/en/guides/understanding-team-effectiveness?ref=arabroot.io)، حيث كان الأمان النفسي Psychological Safety أهم عامل في الفرق الناجحة، أي أن يشعر الشخص أنه يستطيع أن يسأل ويخطئ دون أن يدفع ثمناً اجتماعياً. - **الالتفاف Working Around:** يبدأ الفريق يتجنب الشخص دون أن يقول ذلك، فيطلبون المراجعة من غيره، ويعيدون كتابة الأجزاء التي سلمها ناقصة بصمت، ويخططون الإصدار Release حول غيابه. و[دليل GitLab عن ضعف الأداء Underperformance](https://handbook.gitlab.com/handbook/leadership/underperformance/?ref=arabroot.io) يذكر هذه العلامة بالتحديد بين علامات المشكلة: أن يبدأ أعضاء الفريق في العمل حول الشخص. وخطورتها أنها تخفي المشكلة عن المدير، لأن العمل ما زال ينجز، ولكن بتكلفة يدفعها الآخرون. - **التقليد Contagion:** وهذا ما رآه Felps في التسجيلات، فالسخرية تصبح طريقة الفريق في الكلام، وعدم المبالاة يصبح «واقعية»، والتشاؤم يصبح «خبرة». وفي الفرق التقنية يحدث هذا كثيراً مع المنضمين الجدد، لأنهم يتعلمون ثقافة الفريق من أكثر الأصوات وضوحاً فيه، وليس من الوثيقة المكتوبة. وهناك سبب آخر يجعل أثر هذا الشخص أكبر من حجمه: موقعه. فالتفاحة الفاسدة في الفرق التقنية كثيراً ما تكون شخصاً قديماً يعرف النظام، أو مهندساً قوياً تقنياً، لأن هذا الموقع هو ما يجعل الفريق يتحمل سلوكه بدل أن يواجهه. والقائد نفسه يتردد، لأنه يحتاج معرفة هذا الشخص ويخاف أن يغادر ويأخذها معه، وهذا التردد هو ما سنراه في ثمن الانتظار. ## هل هي تفاحة فاسدة فعلاً؟ (Bad Apple or Something Else) أخطر ما في مصطلح «التفاحة الفاسدة» أنه مريح، فهو يعطيك تفسيراً بسيطاً لكل ما يحدث في الفريق: شخص واحد سيئ، وإذا ذهب عاد كل شيء جيداً. ولكن في كثير من الحالات يكون ما تراه شيئاً آخر يشبهه من بعيد، والخطأ في التسمية يقودك إلى علاج خاطئ. وهذه خمس حالات تتشابه، ولكل واحدة بداية مختلفة: ![جدول من خمسة أسطر: التفاحة الفاسدة Bad Apple سلوك متكرر من شخص واحد والفريق يتأثر به والمشكلة في سلوك الفرد والبداية محادثة خاصة بالوقائع وتوقع مكتوب، والفريق المؤذي Toxic Team السلوك نفسه عند كثيرين والإدارة تكافئه والمشكلة في الثقافة والبداية علاج النظام، والزميل الصعب Difficult Colleague احتكاك بين اثنين والبداية حدود واضحة وتوثيق، والأداء الضعيف Underperformer نتائج أقل دون أذى للآخرين والبداية التشخيص بين المهارة والرغبة والبيئة، والفترة الصعبة Bad Season تغير مفاجئ عند شخص كان جيداً والبداية سؤال خاص ودعم ومرونة لمدة محددة](https://arabroot.io/content/images/2026/10/bad-apple-03-not-the-same.webp) نفس الأعراض من بعيد، ولكل حالة بداية مختلفة فإذا وجدت أن السخرية في المراجعة موجودة عند ثلاثة أو أربعة في الفريق، وأن المدير الأعلى يفعلها في الاجتماعات، وأن من يسخر يترقى، فأنت لست أمام تفاحة فاسدة، وإنما أمام صندوق يفسد التفاح، وإخراج شخص واحد لن يغير شيئاً، وهذا موضوع مقال علامات الفريق المؤذي المنشور في هذا المسار. وإذا كان الاحتكاك بينك أنت وبين شخص واحد، والباقون يعملون معه دون مشكلة، فقد تكون المسألة في العلاقة بينكما، وهنا يفيدك مقال الزميل الصعب. وإذا كان الشخص يسلم عملاً أقل من المتوقع ولكنه لا يؤذي أحداً، لا يسخر ولا يتذمر ولا يترك عمله لغيره عمداً، فهذا أداء ضعيف وليس تفاحة فاسدة، وأسبابه في الغالب مهارة ناقصة أو بيئة لا تساعده، وهو موضوع المقال التالي في هذه المرحلة عن التشخيص. والحالة الخامسة هي التي يخطئ فيها القادة أكثر من غيرها: شخص كان جيداً طوال سنتين ثم تغير فجأة، فصار سريع الغضب، أو غائباً، أو متشائماً. وهنا السؤال الأول ليس «كيف أصحح سلوكه؟» وإنما «ماذا حدث؟»، لأن التغير المفاجئ يأتي في الغالب من ظرف: مرض في العائلة، أو مولود جديد، أو احتراق Burnout من مناوبات متتالية، أو ترقية وعد بها ولم تحدث. ودليل GitLab يطلب من الموظف أن يخبر مديره فوراً إذا كانت هناك ظروف في حياته تجعله أقل فاعلية، دون أن يلزمه بذكر التفاصيل، ويطلب من المدير في المرحلة الأولى أن يراجع تاريخ أداء الشخص، ويتأكد أنه أخذ إجازاته، ويسأل إن كان كل شيء بخير في حياته الشخصية. وهذا ترتيب صحيح: اسأل قبل أن تحكم. ## العبقري الصعب (The Brilliant Jerk) أصعب نسخة من التفاحة الفاسدة في الفرق التقنية هي المهندس الممتاز تقنياً والسيئ في التعامل، والذي يسميه الناس في الثقافة التقنية الإنجليزية Brilliant Jerk. فهو يحل المشاكل التي لا يحلها غيره، ويكتب أسرع كود في الفريق، ويعرف كل زاوية في النظام، ولذلك يتحمل الجميع سخريته ومقاطعته ورفضه لكل فكرة لم تأت منه. والحجة التي تسمعها دائماً: «صحيح أسلوبه صعب، بس ما نقدر نستغني عنه». وقد حسمت بعض الشركات هذا السؤال كتابة في ثقافتها. فصفحة [ثقافة Netflix](https://jobs.netflix.com/culture?ref=arabroot.io)، وهي شركة معروفة بأنها تكافئ الأداء العالي بشكل صريح جداً، تقول إنه مهما كان الشخص لامعاً فلا مكان في فريقها لمن لا يعامل زملاءه باللياقة والاحترام. والسبب في هذا الحسم ليس أخلاقياً فقط، وإنما حسابي: إنتاجية العبقري الصعب مرئية لأنها باسمه، أما تكلفته فموزعة على الآخرين، في الأسئلة التي لم تسأل، والأفكار التي لم تقترح، والمهندسين الذين غادروا وذكروا السبب في مقابلة المغادرة Exit Interview أو لم يذكروه. والقائد الذي يقارن إنتاجية هذا الشخص بإنتاجية غيره فقط يقارن رقماً واضحاً برقم مخفي. ولا يعني هذا أن العبقري الصعب لا يتغير، فكثير منهم لم يقل له أحد بوضوح إن سلوكه له ثمن، لأن كل من حوله كان يحتاجه أو يخاف منه. والمحادثة الأولى الواضحة معه كثيراً ما تكون أول مرة يسمع فيها هذا الكلام، وسوف نرى في الحالة الثانية كيف تسير. ## ثمن الانتظار (Cost of Waiting) أغلب القادة لا يتجاهلون التفاحة الفاسدة لأنهم لا يرونها، وإنما لأنهم يأملون أن تتحسن الأمور وحدها، أو لأن المحادثة صعبة، أو لأنهم يخافون أن يغادر الشخص. وفي الفصل الخامس من كتاب [Software Engineering at Google](https://abseil.io/resources/swe-book/html/ch05.html?ref=arabroot.io)، وهو فصل عن قيادة الفرق، يصف المؤلفون هذا السلوك كنمط خاطئ اسمه «تجاهل ضعيفي الأداء» Ignore Low Performers، ويقولون إنهم رأوا قادة يفعلون كل شيء صحيح لبناء فرق قوية، ثم تفشل هذه الفرق وتتفكك بسبب شخص أو اثنين. ويستعيرون شعار فريق موثوقية المواقع SRE في Google: «الأمل ليس استراتيجية» Hope is not a strategy، ويقولون إنه لا يوجد مكان يستخدم فيه الأمل كاستراتيجية أكثر من التعامل مع ضعيف الأداء. ![خط زمني لاثني عشر شهراً: في الشهر الأول تعليقات ساخرة في المراجعة والفريق يضحك أو يسكت، وفي الثالث المنضمون الجدد يتجنبون طلب مراجعته وطلبات الدمج تنتظر أياماً، وفي السادس اثنان يكتبان نفس السخرية واجتماع المراجعة صار صامتاً، وفي التاسع أفضل مهندسة تطلب النقل ومقابلة المغادرة تذكر السبب، وفي الثاني عشر المحادثة أصعب لأنه لا يوجد توثيق والسلوك صار عادياً](https://arabroot.io/content/images/2026/10/bad-apple-04-cost-of-waiting.webp) كل شهر انتظار يجعل المحادثة أصعب، لأن السلوك يصبح «عادياً» والتوثيق غائباً ويذكر الفصل نفسه ثلاث نتائج للانتظار. الأولى أن أفضل الناس في الفريق يغادرون، لأنهم يستطيعون، وتبقى في النهاية مع من لا يستطيع المغادرة. والثانية أنك لا تخدم الشخص نفسه بإبقائه في مكان لا ينجح فيه، فكثير ممن لا ينجحون في فريقك ينجحون في مكان آخر. والثالثة، وهي الأهم، أن التعامل المبكر يعطيك فرصة حقيقية للمساعدة، لأن كثيراً من الناس يحتاجون فقط توجيهاً واضحاً، أما إذا انتظرت طويلاً فستكون علاقتهم بالفريق قد ساءت، وستكون أنت قد تعبت منهم، فلا تستطيع أن تساعدهم حتى لو أردت. وفي الكتاب عبارة يتذكرها كل من قرأها، قالها مدير قديم لأحد المؤلفين عندما فرح بتوزيع خطابات المكافآت: «أحياناً تكون جنية الأسنان، وأحياناً يجب أن تكون طبيب الأسنان». وهناك ثمن رابع لا يذكره الكتاب ولكنك ستراه في فريقك: الفريق يراقبك. فكل أسبوع يمر دون أن تفعل شيئاً، يفهم الفريق منه رسالة: هذا السلوك مقبول هنا. وعندما تقرر في النهاية أن تتحدث، يسألك الآخرون في سرهم لماذا الآن، ولماذا لم تفعل ذلك قبل سنة عندما اشتكينا. لذلك فالسؤال ليس هل تتعامل مع الموقف، وإنما متى، والجواب في الغالب: الآن، وبالحجم المناسب، أي محادثة واضحة وليس إجراءً رسمياً. ## قبل أن تحكم: الوصف لا اللقب (Describe, Don't Label) بعد كل ما سبق قد تميل إلى أن تقرر أن هذا الشخص «تفاحة فاسدة» وتبدأ في التعامل معه على هذا الأساس، وهنا خطر حقيقي. فاللقب نفسه يغير طريقة رؤيتك له، فتبدأ ترى كل ما يفعله من خلاله، وتفسر تعليقاً عادياً في المراجعة على أنه سخرية، وتأخيراً بسبب عطل حقيقي على أنه تهرب. وعلماء النفس يسمون هذا الميل خطأ الإسناد الأساسي Fundamental Attribution Error، أي أن نفسر سلوك الآخرين بشخصياتهم ونتجاهل ظروفهم، بينما نفسر سلوكنا نحن بظروفنا. لذلك قاعدة عملية: لا تستخدم كلمة «تفاحة فاسدة» عن أحد، لا في الاجتماعات ولا في الرسائل ولا في رأسك إذا استطعت، واستخدم بدلها وصف السلوك وأثره: «في آخر شهر كتب في ثلاث مراجعات تعليقات عن الكاتب وليس عن الكود، واثنان من الفريق توقفا عن طلب مراجعته». هذه الجملة يمكن أن تتحقق منها، ويمكن أن تقولها له، ويمكن أن يغيرها، أما «شخص سلبي» فليست شيئاً يستطيع أحد أن يفعل به شيئاً. ثم اسأل نفسك أسئلة البيئة قبل أسئلة الشخص: هل التوقع منه واضح ومكتوب؟ هل قال له أحد إن هذا السلوك مشكلة؟ هل تغير شيء في عمله قريباً، مثل مدير جديد أو مشروع ألغي أو مناوبة زادت؟ هل هو الوحيد الذي يفعل هذا، أم أن الفريق كله يفعله بدرجات؟ وإذا وجدت أن الجواب على السؤال الثاني «لا»، أي أن أحداً لم يقل له بوضوح، فأنت لم تصل بعد إلى مرحلة الحكم، وإنما إلى مرحلة المحادثة الأولى. وأسئلة التشخيص بتفصيل أكبر، بين المهارة Skill والرغبة Will والبيئة Context، هي موضوع المقال التالي في هذه المرحلة. ## الحالة الأولى: المهندس الأول الساخر في شركة ناشئة (Startup) نعود إلى فريق منصة الحجوزات. المهندس الأول الذي يكتب «مين كتب هذا؟» انضم قبل ثلاث سنوات، وكتب أغلب النظام الأول وحده، وكان في السنة الأولى المرجع الوحيد لكل شيء. ثم كبرت الشركة، وجاء مهندسون جدد، وتعين قائد فريق من خارج الشركة، وهو أنت، وتغيرت طريقة العمل من «هو يقرر» إلى اجتماعات تصميم وسجل قرارات. وفي آخر أربعة أشهر صار سلوكه كما وصفنا: سخرية في المراجعة، وتذمر في الاجتماعات، وترك للمهام الصعبة. ### ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse) ما يحدث عادة أن القائد يتجنب الموضوع لأن هذا المهندس يعرف النظام أكثر منه، ويخاف أن يغادر، فيبدأ في حماية الفريق بطرق جانبية: يطلب من الجدد أن يرسلوا طلبات الدمج لغيره، ويقلل حضوره في اجتماعات التصميم، ويحمل المهام الصعبة لمهندسين آخرين بصمت. وهذا بالضبط الالتفاف Working Around الذي ذكرناه، ولكن هذه المرة من القائد نفسه، والرسالة التي تصل لهذا المهندس أنه يهمش، فيزيد تذمره، وتصل للفريق أن القائد لا يستطيع أن يقول له شيئاً. وما يزيد الموقف سوءاً ثلاثة أشياء: أن ينتقده القائد أمام الفريق في اجتماع، فيصبح الأمر معركة على المكانة لا يستطيع أن يتراجع فيها، أو أن يجمع القائد شكاوى الآخرين ويقدمها له كـ«الفريق كله يشتكي منك» دون وقائع محددة، فيبدأ يبحث عمن اشتكى، أو أن ينتقل القائد مباشرة إلى الموارد البشرية HR وإجراء رسمي دون أي محادثة قبلها، فيشعر أنه عوقب على شيء لم يسمع عنه أبداً. ### ما الذي ينجح؟ (What Works) الذي ينجح هنا محادثة خاصة مبكرة، بوقائع محددة، تبدأ بسؤال حقيقي وليس باتهام. فأنت تحضر قبلها ثلاث وقائع من الشهر الأخير، بتاريخها ونصها، مثل التعليق في طلب الدمج رقم 412، وجملة اجتماع التصميم يوم الأحد، والتذكرة التي أعادها بعد أسبوع دون أن يبدأها. ثم تذكر الأثر، أي أن المهندسة الجديدة لم ترسل له أي طلب بعدها، وأن الاجتماع انتهى دون قرار. ثم تسأل وتسمع. وفي هذه الحالة، عندما سأل القائد «وش الصورة من جهتك؟»، سمع شيئاً لم يكن يعرفه: هذا المهندس كان يحمل المناوبة On-call وحده تقريباً منذ سنة، لأنه الوحيد الذي يعرف أجزاء النظام القديم، ووعد بترقية إلى قائد تقني Tech Lead قبل أن يأتي القائد الجديد، ثم لم يسمع عنها شيئاً. وهذا لا يبرر السخرية، ولكنه يفسرها، ويعطي القائد شيئين يعمل عليهما معاً: سلوك يجب أن يتوقف، وظروف يجب أن تتغير. فاتفق معه على أن تعليقات المراجعة تتحدث عن الكود فقط، وعلى أن يقترح بديلاً عندما يرفض فكرة، ووعد في نفس الجلسة بخطة مكتوبة لتوزيع المناوبة خلال شهر، وبمحادثة صريحة عن مساره الوظيفي Career Path وما ينقصه للوصول إلى دور القائد التقني. ثم أرسل له ملخصاً قصيراً بعد المحادثة، كما يقترح دليل GitLab، حتى يكون للطرفين نفس الفهم لما اتفقا عليه، وتابع معه كل أسبوعين. وفي هذه الحالة تحسن السلوك خلال شهرين بشكل واضح، وصار هو من يدرب المهندسين الجدد على النظام القديم حتى يشاركوه المناوبة، وهذا أعطاه دوراً يحترمه وخفف عنه الضغط في نفس الوقت. ولكن لاحظ أن التحسن جاء لأن السبب كان في جزء كبير منه في البيئة، أي المناوبة والترقية الغامضة، وليس كل حالة تنتهي هكذا، وهذا ما سنراه في الحالة الثانية. ### عبارات تقولها (What to Say) في بداية المحادثة الخاصة: > «أبغى أتكلم معك عن شي لاحظته في المراجعات والاجتماعات الشهر الماضي، لأنه صار يأثر على الفريق، وقبل ما أقول رأيي أبغى أسمع الصورة من جهتك.» عند ذكر الوقائع: > «في طلب الدمج 412 كتبت "مين كتب هذا؟"، وفي اجتماع الأحد قلت "ما في فايدة نناقش". بعدها نورة ما أرسلت لك أي طلب مراجعة، والاجتماع خلص بدون قرار. أنت أكثر واحد يعرف النظام، والفريق يحتاج مراجعتك، بس بهالطريقة صاروا يتجنبونها.» عند الاتفاق: > «اللي أطلبه منك من اليوم: التعليق في المراجعة يكون عن الكود مو عن اللي كتبه، وإذا رفضت فكرة تقترح بديل. وأنا من جهتي بأرجع لك خلال أسبوعين بخطة لتوزيع المناوبة، ونجلس نتكلم عن موضوع القائد التقني بوضوح، وش اللي ناقص وكيف نوصل له.» ## الحالة الثانية: العبقري الصعب في شركة متوسطة (Mid-size Company) في شركة متوسطة لتقنية المدفوعات Payments، فيها حوالي ثمانين مهندساً، كان في فريق البنية التحتية Platform Team مهندس رئيسي Staff Engineer هو أفضل من يعرف نظام التسويات Settlement، وهو من أصلح أغلب الحوادث Incidents الكبيرة في السنتين الأخيرتين. وفي نفس الوقت كان يقاطع زملاءه في الاجتماعات، ويكتب في مراجعات التصميم Design Review تعليقات مثل «هذا كلام مبتدئين»، ويرفض أي تغيير في النظام لم يقترحه هو. وخلال ثمانية عشر شهراً غادر الفريق مهندسان، وذكر أحدهما السبب صراحة في مقابلة المغادرة، والمدير كان يقول لكل من يشتكي: «أعرف، بس هو اللي يشيل النظام». ### ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse) ما يحدث عادة في هذه الحالة أن المدير يقيم هذا المهندس بأعلى درجة في تقييم الأداء Performance Review لأن نتائجه التقنية ممتازة، ثم يضيف ملاحظة صغيرة عن «التواصل» لا يقرأها أحد. والرسالة التي تصل للمهندس واضحة: سلوكه لا يؤثر على تقييمه، أي لا يهم. والرسالة التي تصل للفريق أوضح: الأداء التقني يشتري لصاحبه حق إهانة الآخرين. وما يزيد الموقف سوءاً أن يرقى هذا المهندس إلى دور قيادي لأنه «الأفضل تقنياً»، فيصبح سلوكه هو نموذج القيادة في الفريق، أو أن يحاول المدير حل المشكلة بأن يعزله عن الفريق ويعطيه مشاريع فردية، فيبقى يعرف النظام وحده أكثر، وتزيد حاجة الجميع إليه. ### ما الذي ينجح؟ (What Works) الذي ينجح هنا أن يصبح السلوك جزءاً من التقييم بشكل صريح، أي أن يكون في مصفوفة الكفاءات Competency Matrix للمهندس الرئيسي بند عن التعاون وتطوير الآخرين، وأن يقال له بوضوح إن هذا البند جزء من دوره وليس إضافة. ففي أغلب سلالم المسار الوظيفي Career Ladder، كلما ارتفع المستوى زاد الجزء المتعلق بأثرك على الآخرين، وهذا يعطي المدير لغة موضوعية: «أنت ممتاز في الجزء التقني من دورك، وضعيف في الجزء الآخر منه، والجزء الآخر ليس اختيارياً في مستواك». ثم توقع مكتوب بسلوك محدد، مثل عدم المقاطعة، وتعليقات مراجعة التصميم تقترح بديلاً، ومتابعة كل أسبوعين بوقائع، وخطة لنقل معرفة نظام التسويات إلى اثنين آخرين خلال ربع سنة، لأن اعتماد الفريق على شخص واحد خطر في كل الأحوال، وهو ما يسمى في الفرق التقنية عامل الحافلة Bus Factor. وفي هذه الحالة تحسن جزء من السلوك، فتوقفت المقاطعة في الاجتماعات بعد شهر، ولكن التعليقات المهينة في مراجعات التصميم المكتوبة استمرت بدرجة أقل. وبعد ثلاثة أشهر من المتابعة الموثقة، انتقل المدير إلى خطة تحسين أداء PIP رسمية، ثم انتهت العلاقة بالاتفاق بعدها، وكانت معرفة نظام التسويات قد انتقلت إلى مهندسين آخرين قبل ذلك. وما يهمنا هنا ليس النهاية، وإنما أن المدير لو بدأ قبل ثمانية عشر شهراً، لكان لديه وقت أطول، ولكان المهندسان اللذان غادرا ربما بقيا. وخطة تحسين الأداء وإنهاء الخدمة لكل منهما مقال مستقل في هذه المرحلة. ### عبارات تقولها (What to Say) > «تقييمك التقني من أعلى التقييمات في الشركة، وهذا ما راح يتغير. بس دورك كمهندس رئيسي فيه جزء ثاني: إن الفريق حولك يكبر بسببك. وفي آخر ربع، اثنين من الفريق قالوا بوضوح إنهم ما يقدرون يطرحون فكرة في مراجعة التصميم وأنت موجود. هذا الجزء صار مكتوب في توقعات مستواك، وراح نتابعه مثل ما نتابع الجزء التقني.» > «ما أطلب منك توافق على كل فكرة. أطلب إذا رفضت فكرة تكتب ليش وتقترح بديل، وما تقاطع أحد في الاجتماع. وأبغى خلال ثلاثة أشهر يكون في اثنين غيرك يقدرون يصلحون أي عطل في نظام التسويات.» ## الحالة الثالثة: موظف فقد الحماس في جهة شبه حكومية (Semi-Government) في جهة شبه حكومية تبني منصة خدمات إلكترونية للمستفيدين، كان في فريق التطوير محلل أنظمة Systems Analyst انتقل قبل سنة من مشروع كبير ألغي فجأة بعد سنتين من العمل فيه. ومنذ انتقاله صار يحضر الاجتماعات دون أن يتكلم، وإذا تكلم قال «هذا المشروع بيتلغى مثل اللي قبله»، ويسلم المتطلبات Requirements متأخرة وناقصة، والمطورون الجدد صاروا يرددون جملته عن الإلغاء. والمدير كان يرى فيه موظفاً سلبياً «ما عنده رغبة»، وبدأ يفكر في طلب نقله. ### ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse) ما يحدث عادة في الجهات الكبيرة أن مثل هذا الموظف يبقى سنوات في نفس الحالة، لأن الإجراءات طويلة، والمدير يفضل أن يتجنبه بدل أن يتعامل معه، فيعطي عمله لغيره تدريجياً حتى يصبح بلا عمل حقيقي، وهذا يؤكد له أن لا أحد يحتاجه. وما يزيد الموقف سوءاً أن ينقل إلى فريق آخر دون أي محادثة، فيحمل معه نفس الإحباط ونفس الجملة، أو أن يقيم بدرجة منخفضة في نهاية السنة دون أن يسمع قبلها أي ملاحظة محددة، فيقرأ التقييم على أنه دليل جديد على أن المؤسسة لا تقدر ما يفعله. ### ما الذي ينجح؟ (What Works) الذي نجح هنا أن المدير بدأ بالسؤال قبل الحكم، فسأله في اجتماع فردي عن المشروع الملغى، واكتشف أن المحلل كان قد قاد جزءاً كبيراً منه، وأن الإلغاء جاء دون أي شرح للفريق، وأنه انتقل إلى دور مختلف عن دوره، أي من تصميم الحلول إلى كتابة متطلبات تفصيلية لا يشارك في قرارها، دون أن يسأله أحد. فكانت المشكلة في جزء كبير منها في البيئة: إحباط مشروع ألغي دون شرح، ودور لا يناسبه. فطلب المدير من مدير الإدارة جلسة قصيرة يشرح فيها للفريق سبب الإلغاء السابق، وأعطى المحلل مسؤولية تصميم الحل لخدمة جديدة صغيرة من البداية إلى الإطلاق، مع توقع واضح عن مواعيد تسليم المتطلبات، ومتابعة كل أسبوعين. وفي أربعة أشهر تغير الوضع: سلم المتطلبات في مواعيدها، وصار يشرح للمطورين الجدد لماذا كان المشروع القديم معقداً، وتوقفت جملة الإلغاء. وهذه الحالة هي سبب أننا نكرر في هذه المرحلة أن تشخص قبل أن تحكم، لأن «لا يملك رغبة» كان تشخيصاً خاطئاً، والرغبة عادت عندما تغير الدور. ولاحظ أن الجهات الحكومية لها أنظمة موارد بشرية خاصة بموظفيها تختلف عن نظام العمل الذي يحكم القطاع الخاص، لذلك إذا وصلت إلى إجراء رسمي فاسأل الموارد البشرية HR عن النظام الذي يخضع له عقد الموظف قبل أي خطوة. ### عبارات تقولها (What to Say) > «لاحظت إنك من أكثر الناس خبرة في الفريق، وفي نفس الوقت أحسك مو مرتاح من وقت ما انتقلت لنا. ممكن تحكي لي وش صار في المشروع اللي قبل، ووش تحس إنه ناقصك هنا؟» > «جملة "المشروع بيتلغى" صارت تتكرر عند المطورين الجدد، وأفهم ليش تقولها بعد اللي صار. بس هي تأثر عليهم وهم ما عاشوا التجربة. أبغاك تكون أنت اللي تشرح لهم وش تعلمنا من المشروع القديم، بدل ما يسمعون النهاية بس.» ## في الاجتماع نفسه: ما يفعله القائد (In the Room) في تجربة Felps حدث شيء لم يتوقعه: مجموعة واحدة فقط لم تتأثر بسلوك Nick، بل أدت بشكل جيد جداً. وعندما راجع التسجيل وجد فيها شخصاً كان يسأل الأسئلة، ويشرك كل أعضاء المجموعة، ويهدئ الخلاف كلما بدأ، وعرف لاحقاً أنه ابن دبلوماسي. وهذه ملاحظة واحدة من مجموعة واحدة، فلا تبني عليها نظرية، ولكنها تتفق مع ما يعرفه كل قائد من تجربته: ما تفعله في لحظة السلوك نفسها يحدد هل ينتقل إلى الفريق أم لا. ![مقارنة بين ما يحدث في الاجتماع وما يقوله القائد: عندما يقول أحدهم هذا التصميم ما يمشي واضح إن ما أحد هنا اشتغل على نظام حقيقي يعيد القائد النقاش للفكرة ويسأل عن السيناريو المقلق بالتحديد، وعندما يقول كالعادة ما في فايدة نناقش يشرك القائد الصامتين بسؤال مهندسة كتبت الجزء عن رأيها، وعندما يسود الصمت يضع القائد القاعدة بهدوء بأن النقاش عن التصميم وليس عن من كتبوه ويطلب دقيقتين بعد الاجتماع](https://arabroot.io/content/images/2026/10/bad-apple-05-in-the-room.webp) التدخل العلني قصير ويحمي الفريق، والحديث عن السلوك نفسه يكون في محادثة خاصة والقاعدة في الاجتماع أن تفصل بين شيئين: حماية الفريق في اللحظة، والحديث عن السلوك لاحقاً. فحماية الفريق تكون بإعادة النقاش إلى الفكرة، أي أن تأخذ من الجملة الساخرة الجزء التقني الحقيقي فيها، إن وجد، وتحوله إلى سؤال: «وش اللي ما يمشي بالتحديد؟». وهذا يفعل شيئين: يعطي صاحب التعليق فرصة ليقول اعتراضه بشكل مفيد، ويرسل للفريق رسالة أن النقاش هنا عن التصميم. ثم إشراك الصامتين باسمهم، وخاصة من كان التعليق موجهاً لعملهم، حتى لا يكون آخر ما قيل عن عملهم هو السخرية. ثم، إذا تكرر السلوك في نفس الاجتماع، جملة قصيرة هادئة تذكر القاعدة، دون محاضرة ودون نقاش أمام الجميع، وطلب للحديث بعد الاجتماع. ولا تقم بتوبيخه أمام الفريق، لأن هذا يحول الموقف من سلوك يجب أن يتغير إلى مكانة يجب أن يدافع عنها، والحديث أمام الآخرين لا يترك له مخرجاً يحفظ فيه وجهه. وفي نفس الوقت لا تسكت تماماً، لأن السكوت في الاجتماع يقرأ موافقة، وأول من يقرأه كذلك هو من وجه له التعليق. وطريقة إعطاء الملاحظة الصعبة نفسها، أي صيغة الموقف والسلوك والأثر SBI، شرحناها في مقال الملاحظات الصعبة المنشور في هذا المسار، وهي ما تستخدمه في المحادثة الخاصة بعد الاجتماع. وفي العمل عن بعد، حيث يحدث كثير من هذا السلوك في الكتابة، القاعدة نفسها: إذا كتب تعليقاً على الشخص في طلب دمج، فرد عليه في نفس المكان بسؤال تقني يعيد النقاش للكود، ثم تحدث معه في رسالة خاصة أو مكالمة، ولا تدخل معه في نقاش طويل مكتوب أمام الفريق، لأن الكتابة تحفظ كل كلمة وتجعل التراجع أصعب. ## حماية الفريق أثناء ذلك (Protecting the Team) من وقت أن تبدأ المحادثة الأولى إلى أن يتحسن السلوك أو تنتهي العلاقة، قد تمر أسابيع أو أشهر، والفريق يعيش هذه المدة كلها. وهنا يقع القادة في خطأين متعاكسين: الأول أن يقولوا للفريق كل شيء، فيشرحوا أنهم تحدثوا معه وأنه في خطة متابعة، وهذا يخالف حقه في الخصوصية ويحول الموضوع إلى قصة يتابعها الجميع. والثاني ألا يقولوا شيئاً أبداً، فيظن الفريق أن القائد لا يرى ما يحدث أو لا يهتم. والطريق الصحيح بينهما: لا تتحدث عن الشخص، وتحدث عن القواعد. فإذا كانت قواعد المراجعة غير مكتوبة، فهذا وقت مناسب لكتابتها للفريق كله، مثل أن التعليق يكون عن الكود، وأن كل رفض يأتي مع سبب، وأن المراجعة تتم خلال يوم عمل، و[إرشادات مراجعة الكود في Google](https://google.github.io/eng-practices/review/?ref=arabroot.io) مرجع جيد تبدأ منه. وإذا جاءك أحد يشتكي، فاسمعه، واكتب ما قاله، وقل له إنك تتعامل مع الموضوع دون أن تشرح كيف: «شكراً إنك قلت لي، وأنا شايف الموضوع وأتعامل معه، ولو صار شي ثاني قل لي مباشرة». ووزع العمل بحيث لا يحمل أحد بصمت ما يتركه غيره، لأن من يحمل العمل الزائد اليوم هو من سيطلب النقل غداً. وانتبه لمن يقلد السلوك، فإذا بدأ آخرون يكتبون نفس التعليقات، فلا تنتظر حتى تحل الحالة الأولى، وتحدث معهم أيضاً بنفس الطريقة، لأن التقليد هو الطريقة التي يتحول بها سلوك شخص واحد إلى ثقافة فريق، وعندها لا تعود المشكلة تفاحة واحدة. ## وإذا كنت أنت التفاحة الفاسدة؟ (When It Is You) قال Felps في نهاية حديثه عن التجربة إنه صار حساساً جداً لهذا السلوك في نفسه، وإنه كان يمزح ويسخر من زملائه كثيراً ويظن أن هذا يقوي العلاقة، ثم رأى في التسجيلات أن المشاركين كانوا يضحكون على نكات Nick عن الآخرين، ثم يكتبون في التقييم بعد التجربة أنهم لا يريدون العمل معه مرة أخرى أبداً، فتوقف عن السخرية. والدرس هنا أن الضحك لا يعني الموافقة، وأنك قد تكون أنت مصدر السلوك دون أن تعرف، لأن الناس لا يقولون لك. وإذا كنت مهندساً تقرأ هذا المقال وتشك أنك تفعل بعض ما فيه، فهذه بعض الأسئلة: ارجع إلى آخر ثلاث تعليقات كتبتها في مراجعات الكود، هل تتحدث عن الكود أم عن كاتبه؟ هل تقول «ما في فايدة» أكثر مما تقترح بديلاً؟ هل تترك المهام المملة لغيرك بشكل متكرر؟ وهل تغير شيء في حياتك أو عملك في آخر أشهر جعلك أكثر حدة، مثل ضغط أو احتراق أو إحباط من قرار لم يعجبك؟ فإذا وجدت شيئاً من ذلك، فأسهل خطوة أن تتحدث مع مديرك قبل أن يتحدث هو معك، كما يقترح دليل GitLab، وأن تقول له ما الذي يضايقك، لأن الإحباط الذي يقال في اجتماع فردي يمكن أن يعالج، أما الإحباط الذي يقال في كل اجتماع للفريق فيتحول إلى سلوك يحاسب عليه. وإذا كنت مقتنعاً أن ما يحدث في الفريق خطأ فعلاً، مثل قرار سيئ أو ظلم في التوزيع، فلك حق أن تعترض، والفرق بين الاعتراض المفيد والتذمر أن الأول يذهب للشخص الذي يستطيع التغيير ومعه اقتراح، والثاني يذهب للجميع ومعه إحباط. وطريقة الاختلاف التقني دون أن تخسر زميلك شرحناها في مقال الخلاف التقني المنشور في هذا المسار. ## أخطاء شائعة (Common Mistakes) - **التسمية قبل التشخيص:** أن تقرر أن الشخص «تفاحة فاسدة» من أول أسبوع، فترى كل ما يفعله من خلال هذا الحكم، وتفوت ظرفاً أو دوراً خاطئاً كان يمكن تغييره. - **الانتظار على أمل:** أن تؤجل المحادثة لأن المشروع في مرحلة حرجة، أو لأنك تحتاج معرفته، حتى يغادر أفضل من في الفريق. - **الشكوى المجمعة بدل الوقائع:** «الفريق كله يشتكي منك» تجعله يبحث عمن اشتكى، أما «في طلب الدمج 412 كتبت كذا» فتجعله يفكر فيما كتب. - **المواجهة أمام الفريق:** التوبيخ العلني يحول السلوك إلى معركة مكانة، ويجعل التراجع مستحيلاً. - **الالتفاف بدل المواجهة:** أن تعيد توزيع العمل حوله بصمت، فيستمر السلوك ويدفع الفريق ثمنه وأنت تظن أنك حللت المشكلة. - **إعفاء الأداء التقني العالي:** أن تعطي العبقري الصعب أعلى تقييم وتكتب ملاحظة صغيرة عن التواصل، فتخبر الجميع أن السلوك لا يهم. - **إخراج الشخص وترك النظام:** أن ينتهي عمل الشخص ويبقى ما جعل سلوكه ممكناً، مثل معرفة محصورة في شخص واحد، أو قواعد مراجعة غير مكتوبة، أو مدير يسخر هو نفسه. - **عدم التوثيق:** أن تتحدث معه ثلاث مرات دون أن تكتب شيئاً، ثم تحتاج بعد أشهر أن تثبت أن الموضوع نوقش. ## الأداة: سجل أثر السلوك على الفريق (Team Impact Log) الأداة العملية في هذا المقال سجل محفوظ في ملف `lab/team-impact-log.md`، تملؤه قبل أن تقرر أن المشكلة في شخص، وقبل المحادثة الأولى معه. والفكرة أنه يجبرك على ثلاثة أشياء يتجاوزها القادة عادة: أن تكتب وقائع وليس انطباعات، وأن تسأل أسئلة البيئة قبل أسئلة الشخص، وأن ترى الأثر على الفريق بشكل منفصل عن انزعاجك أنت. ```markdown ## الجزء الأول: الوقائع (Facts) | التاريخ | ماذا حدث بالضبط | أين | من تأثر | الأثر الملموس | |---|---|---|---|---| | | | | | | ## الجزء الثاني: أي سلوك يتكرر؟ (Felps, Mitchell and Byington, 2006) - [ ] حجب الجهد Withholding Effort - [ ] المزاج السلبي المستمر Negative Affect - [ ] خرق قواعد التعامل Interpersonal Deviance عدد المرات في آخر 30 يوماً: ____ منذ متى بدأ: ____ ## الجزء الثالث: قبل أن تحكم (Context Check) | السؤال | الجواب | |---|---| | هل التوقع منه مكتوب وواضح؟ | | | هل تغير شيء قريباً؟ (مدير، مشروع ألغي، ترقية، مناوبة) | | | هل يعرف أن سلوكه يؤثر على الآخرين؟ | | | هل السلوك نفسه موجود عند آخرين؟ | | ## الجزء الرابع: أثر على الفريق (Team Signals) - [ ] آخرون يلتفون حوله Working Around - [ ] أسئلة أقل، واجتماع المراجعة أهدأ - [ ] طلب نقل أو ذكر في مقابلة المغادرة - [ ] السلوك بدأ يظهر عند غيره Contagion ``` في السجل أعلاه لاحظ التالي: - عمود «ماذا حدث بالضبط» يطلب فعلاً أو جملة ورابطاً إن وجد، مثل رقم طلب الدمج أو تاريخ الاجتماع، لأن هذا ما ستقوله في المحادثة، ولأن الانطباع العام لا يمكن مناقشته. - عمود «الأثر الملموس» منفصل عن الواقعة، لأن نفس الجملة قد تمر دون أثر في يوم وتوقف مهندسة عن السؤال في يوم آخر، والأثر هو ما يجعل السلوك موضوعاً للعمل وليس مسألة ذوق. - الجزء الثالث يأتي قبل الرابع عمداً، فإذا وجدت أن أحداً لم يقل له بوضوح إن السلوك مشكلة، فخطوتك التالية محادثة وليست إجراءً. - سؤال «هل السلوك نفسه موجود عند آخرين؟» يحميك من الخطأ الأكبر، أي أن تعالج شخصاً والمشكلة في الفريق كله. - في الملف نفسه جزآن إضافيان: خطوات المحادثة الأولى، وفحص ذاتي لمن يخشى أن يكون هو مصدر السلوك. ## قائمة تحقق (Checklist) | إذا لاحظت | جرب | | ------------------------------------------------------------- | ----------------------------------------------------------------------------- | | أشياء صغيرة متفرقة: مراجعات بطيئة، صمت في الاجتماعات، طلب نقل | اجمعها في سجل الأثر وانظر هل تمر بشخص واحد | | السلوك عند شخص واحد والفريق يتأثر | محادثة خاصة خلال أسبوع: وقائع، أثر، سؤال حقيقي، توقع مكتوب | | السلوك نفسه عند كثيرين والإدارة تكافئه | هذا فريق مؤذ Toxic Team: عالج القواعد والقيادة قبل الأفراد | | تغير مفاجئ عند شخص كان جيداً | اسأل في الاجتماع الفردي One-on-One قبل أي ملاحظة، وقدم مرونة لمدة محددة | | سخرية أو تذمر في الاجتماع نفسه | أعد النقاش للفكرة، أشرك الصامتين، ذكر القاعدة بجملة، ثم تحدث معه بعد الاجتماع | | العبقري الصعب Brilliant Jerk | اجعل التعاون جزءاً مكتوباً من توقعات مستواه، وانقل معرفته لاثنين آخرين | | تحسن بعد المحادثة | قل له ذلك بوضوح، واستمر في المتابعة شهرين قبل أن تتوقف | | لا تحسن بعد متابعة موثقة | انتقل إلى خطة تحسين الأداء PIP مع الموارد البشرية HR | | آخرون بدأوا يقلدون السلوك | تحدث معهم أيضاً الآن، ولا تنتظر حل الحالة الأولى | ومقالات المسار التالية تكمل هذا الموضوع من زوايا أخرى، فالفريق المؤذي والزميل الصعب والملاحظات الصعبة والأمان النفسي كلها متصلة به: [![](https://arabroot.io/content/images/2026/10/toxic-team-signs-cover-cover.webp)دليلعلامات الفريق المؤذي Toxic Team: كيف تميزه وماذا تفعلكيف تفرق بين فريق مرهق في فترة صعبة وفريق مؤذ فعلاً، وما الذي تفعله كعضو أو قائد، ومتى تصعد ومتى تحمي نفسك وتغادر.](https://arabroot.io/articles/%D8%B9%D9%84%D8%A7%D9%85%D8%A7%D8%AA-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82-%D8%A7%D9%84%D9%85%D8%B1%D9%87%D9%82-%D8%A7%D9%88-%D8%A7%D9%84%D9%85%D8%A4%D8%B0%D9%8A-toxic-team-%D9%88%D9%85%D8%A7%D8%B0%D8%A7-%D8%AA%D9%81%D8%B9%D9%84/)[![](https://arabroot.io/content/images/2026/10/difficult-colleague-cover-cover.webp)دليلزميل صعب Difficult Colleague: حدود واضحة وتوثيق هادئكيف تفرق بين أسلوب مزعج وسلوك يحتاج حداً، وماذا تقول لزميل يسخر أو يقاطع، وكيف تسجل الوقائع ومتى تصعد.](https://arabroot.io/articles/%D8%B2%D9%85%D9%8A%D9%84-%D8%B5%D8%B9%D8%A8-%D8%A7%D9%88-%D8%B9%D8%AF%D8%A7%D8%A6%D9%8A-%D8%AD%D8%AF%D9%88%D8%AF-%D9%88%D8%A7%D8%B6%D8%AD%D8%A9-%D9%88%D8%AA%D9%88%D8%AB%D9%8A%D9%82-%D9%87%D8%A7%D8%AF%D8%A6/)[![](https://arabroot.io/content/images/2026/10/difficult-feedback-cover-cover.webp)دليلكيف تعطي الملاحظات الصعبة Feedback وتتلقاهالماذا يخفض بعض الملاحظات الأداء بدلاً من أن يرفعه، وكيف تقول الملاحظة الصعبة بوضوح واهتمام وتتلقاها دون أن تدافع.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B9%D8%B7%D9%8A-%D8%A7%D9%84%D9%85%D9%84%D8%A7%D8%AD%D8%B8%D8%A7%D8%AA-%D8%A7%D9%84%D8%B5%D8%B9%D8%A8%D8%A9-feedback-%D9%88%D8%AA%D8%AA%D9%84%D9%82%D8%A7%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/psychological-safety-cover-cover.webp)دليلالأمان النفسي Psychological Safety: ما وجدته Googleما معنى الأمان النفسي كما عرفته Edmondson، ولماذا كان أهم عامل في فعالية فرق Google، وكيف تقيسه في فريقك وتبنيه بسلوك يومي.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D9%85%D8%A7%D9%86-%D8%A7%D9%84%D9%86%D9%81%D8%B3%D9%8A-psychological-safety-%D9%85%D8%A7-%D9%88%D8%AC%D8%AF%D8%AA%D9%87-google-%D9%81%D9%8A-project-aristotle/)[![](https://arabroot.io/content/images/2026/10/workplace-conflict-cover-cover.webp)دليلالخلاف التقني Conflict: كيف تختلف دون أن تخسر زميلكما الفرق بين الخلاف على الحل والخلاف على الشخص، وكيف تنقل النقاش التقني من الآراء إلى قرار مكتوب يلتزم به الجميع.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AE%D9%84%D8%A7%D9%81-%D8%A7%D9%84%D8%AA%D9%82%D9%86%D9%8A-conflict-%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D9%84%D9%81-%D8%AF%D9%88%D9%86-%D8%A7%D9%86-%D8%AA%D8%AE%D8%B3%D8%B1-%D8%B2%D9%85%D9%8A%D9%84%D9%83/)[![](https://arabroot.io/content/images/2026/10/dev-evaluation-cover-cover.webp)دليلكيف تقيم أداء المطورين Developer Performance دون قياس الأشياء الخطأ؟ماذا تقيس في أداء المطور والفريق، ولماذا تضلل أرقام مثل عدد الأسطر وطلبات الدمج، وكيف تقلل تحيز من يقيم.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%8A%D9%85-%D8%A7%D8%AF%D8%A7%D8%A1-%D8%A7%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86-%D8%AF%D9%88%D9%86-%D9%82%D9%8A%D8%A7%D8%B3-%D8%A7%D9%84%D8%A7%D8%B4%D9%8A%D8%A7%D8%A1-%D8%A7%D9%84%D8%AE%D8%B7%D8%A7/) ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - مراجعة Felps وزميليه عام 2006 وصفت ثلاثة سلوكيات ترتبط بضعف أداء الفريق كله: حجب الجهد، والمزاج السلبي المستمر، وخرق قواعد التعامل. - في تجربة Felps بالممثل أدت المجموعات أسوأ بنسبة بين 30% و40%، وبدأ أعضاؤها يقلدون السلوك، وهي تجربة مخبرية قصيرة نأخذ منها الآلية وليس الرقم. - الفريق يرد على السلوك بالدفاعية والانسحاب والالتفاف ثم التقليد، والالتفاف يخفي المشكلة عن المدير لأن العمل ما زال ينجز. - فرق بين التفاحة الفاسدة والفريق المؤذي والزميل الصعب والأداء الضعيف والفترة الصعبة، لأن لكل منها علاجاً مختلفاً. - الانتظار له ثمن: أفضل الناس يغادرون، والسلوك يصبح عادياً، والمحادثة تصبح أصعب، والأمل ليس استراتيجية. - صف السلوك ولا تلقب الشخص، واسأل عن البيئة قبل الحكم، فقد يكون السبب مناوبة زائدة أو دوراً خاطئاً أو مشروعاً ألغي دون شرح. - في الاجتماع أعد النقاش للفكرة وأشرك الصامتين، وفي المحادثة الخاصة وقائع وأثر وسؤال وتوقع مكتوب ومتابعة. ## سجل التحديثات - أكتوبر 2026: كتابة المقال، والتحقق من مراجعة Felps وMitchell وByington المنشورة في Research in Organizational Behavior عام 2006، ونص حلقة This American Life رقم 370، والفصل الخامس من كتاب Software Engineering at Google، ودليل GitLab عن ضعف الأداء، وصفحة ثقافة Netflix، ودليل Google re:Work عن فاعلية الفرق، بتاريخ 31 أكتوبر 2026.