> ## 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. # زميل ضعيف الأداء Weak Colleague وأنت لست مديره - URL: https://arabroot.io/articles/زميل-ضعيف-الأداء-weak-colleague-وأنت-لست-مديره/ - Published: 2026-10-31T09:53:27.000Z - Updated: 2026-10-31T10:52:50.000Z - Description: ماذا تفعل عندما يثقل زميل ضعيف الأداء فريقك وأنت لست مديره: ما يخصك وما لا يخصك، وكيف تساعد دون أن تحمل عمله، ومتى وكيف تخبر المدير بالوقائع. - Author: فريق عرب رووت - Tags: الأدلة التقنية, القيادة التقنية لنفرض أنك مهندس خلفية Backend Engineer في شركة ناشئة تبيع نظام حجوزات للعيادات، وفريقك ستة مهندسين، وانضم إليكم قبل ثمانية أشهر زميل كلف بخدمة المدفوعات Payment Service. وفي آخر ثلاثة أسابيع عاد كل طلب دمج Pull Request أرسله بأخطاء واضحة، فمرة اختبار Test ناقص، ومرة استعلام Query يقرأ كل الجدول، ومرة تعديل يعطل شاشة لم يجربها، وأنت المراجع Reviewer الأول له لأنك تعرف الخدمة، فتجد نفسك تصلح الأخطاء بعد العشاء حتى لا يتأخر الإصدار Release، وفي الاجتماع اليومي Daily Standup يقول «تقريباً خلصت» عن مهمة بدأها قبل أسبوع. وأنت لست مديره، ولا تريد أن تكون الشخص الذي «يشتكي على زملائه»، ولكنك تعبت، والفريق بدأ يتجنب إسناد أي شيء له، والمدير لا يبدو أنه يرى ما ترى. هذا الموقف من أكثر المواقف إحراجاً في العمل التقني، لأنك ترى المشكلة كل يوم من قرب، ولكنك لا تملك أدوات المدير، فلا تستطيع أن تضع له أهدافاً، ولا أن تقيمه، ولا أن تغير مهامه، وكل ما تملكه هو عملك أنت، وكلامك معه، وطريقة مراجعتك لكوده، وما تقوله للمدير. وفي هذا المقال سوف نرى ما يخصك من المشكلة وما لا يخصك، وكيف تساعد زميلك دون أن تحمل عمله عنه، وكيف تتحدث معه مباشرة، ومتى وكيف ترفع الأمر لمديركما بحقائق وأثر لا بشكوى، وكيف تحمي عملك وسمعتك أثناء ذلك، والحالة التي يتضح فيها أنك كنت مخطئاً في حكمك لأن عنده سياقاً Context لم تكن تعرفه. ونفترض في هذا المقال أن المشكلة في جودة العمل أو الالتزام، أما الزميل العدائي أو المسيء فله مقال مستقل عن الزميل الصعب نضع رابطه في آخر المقال. وسوف نناقش في هذا المقال ما يلي: - لماذا يؤثر زميل واحد ضعيف على الفريق كله، وما تقوله الأبحاث عن ذلك. - ثلاث دوائر: ما يخصك، وما يخص الفريق، وما يخص المدير وحده. - قبل أن تحكم: ما الذي لا تراه من مكانك. - الحالة الأولى: طلبات الدمج التي تصلحها في الليل. - المساعدة دون أن تحمل عنه، ومراجعة الكود Code Review والبرمجة الثنائية Pair Programming كأدوات تعليم. - الحديث المباشر معه، ثم الحالة الثانية: «تقريباً خلصت» في كل اجتماع يومي. - متى ترفع الأمر للمدير، وكيف تفرق بين البلاغ والنميمة، وما الذي يحدث بعد ذلك. - الحالة الثالثة: الحد الأدنى من الجهد في جهة حكومية. - حماية عملك وسمعتك، وعندما تكون مخطئاً، وإذا كنت أنت الزميل الضعيف. - الأخطاء الشائعة، وأداة عملية لنص المحادثة، وقائمة تحقق. ## لماذا يؤثر زميل واحد على الفريق كله؟ (Peer Impact) قد يتساءل البعض: لماذا تأخذ المشكلة كل هذا الحجم، والفريق ستة أشخاص، وخمسة منهم يعملون بشكل جيد؟ والإجابة أن العمل في الفريق التقني مترابط، فالكود الذي يكتبه زميلك يراجعه أحدكم، ويختبره آخر، ويعمل عليه ثالث بعد شهر، والخطأ الذي يصل إلى بيئة الإنتاج Production يوقظ من في المناوبة On-call وليس من كتبه بالضرورة. ولذلك فإن ضعف شخص واحد لا يبقى في مهامه، وإنما ينتقل إلى وقت الآخرين وأعصابهم. وأشهر من درس هذا الأثر هو Will Felps وزملاؤه، الذين نشروا عام 2006 [مراجعة بعنوان How, When, and Why Bad Apples Spoil the Barrel](https://doi.org/10.1016/S0191-3085%2806%2927005-9?ref=arabroot.io) في Research in Organizational Behavior، عن العضو السلبي في المجموعة وكيف يغير أداءها. وقد شرح Felps في [حلقة من برنامج This American Life](https://www.thisamericanlife.org/370/ruining-it-for-the-rest-of-us?ref=arabroot.io) تجربة استخدم فيها ممثلاً ينضم إلى مجموعات من ثلاثة طلاب يعملون على مهمة قرارات إدارية، فيتصرف مرة كمتنمر يهين الآخرين، ومرة كمتكاسل يسند ظهره ويكتب الرسائل في هاتفه، ومرة كمتشائم يضع رأسه على الطاولة، وكانت المجموعات التي فيها هذا الممثل تؤدي أسوأ بنسبة 30% إلى 40% من المجموعات التي ليس فيها، حسب ما قاله في الحلقة. والملاحظة التي تهمنا هنا هي نمط المتكاسل، فقد قال إن أحد أعضاء المجموعة كان يعلن في النهاية أن المهمة ليست مهمة، ويقترح أن يملؤوا أي إجابات وينتهوا، أي أن قلة الجهد عند شخص واحد انتقلت إلى الآخرين. وفي العمل الحقيقي يأخذ هذا الانتقال شكلاً تعرفه، وهو ما يذكره [دليل GitLab عن ضعف الأداء Underperformance](https://handbook.gitlab.com/handbook/leadership/underperformance/?ref=arabroot.io) ضمن علامات التحذير Warning Signs: أن يبدأ أعضاء الفريق في العمل من حول الشخص Working Around Them، وأن يظهر الإحباط عند الآخرين، وأن تتأثر طريقة عمل الفريق وتواصله وتسليمه. فعندما يبدأ الفريق في تجنب إسناد المهام لزميل، أو في إعادة كتابة كوده دون أن يقول له، فهذا لا يحل المشكلة، وإنما يخفيها عن المدير، ويحمل الآخرين عملاً إضافياً لا يراه أحد، ويحرم الزميل نفسه من ملاحظة كان سيتحسن بها. ولاحظ أن المشكلة هنا لا تخص الزميل الضعيف وحده، وإنما تخص الطريقة التي يتعامل بها الفريق معه، وهذا الجزء الثاني هو ما تستطيع أنت أن تغيره. ## ما الذي يخصك وما الذي لا يخصك؟ (Circles of Responsibility) أول خطوة عملية أن ترسم لنفسك حدود دورك، لأن أكثر ما يتعب الزميل في هذا الموقف أنه يحاول أن يحل مشكلة ليست من صلاحياته، فيغضب لأنها لا تنحل، أو يتجاهل ما هو من صلاحياته فعلاً، مثل طريقة مراجعته. وتقسيم بسيط من ثلاث دوائر يكفي: ![ثلاث دوائر للمسؤولية عند زميل ضعيف: دائرتك أنت وفيها عملك وجودة مراجعتك للكود وكلامك المباشر معه وما تقوله للمدير، ودائرة الفريق وفيها معايير مراجعة الكود وتعريف الانتهاء Definition of Done وقواعد الاجتماع اليومي، ودائرة المدير وحده وفيها تشخيص السبب والتوقعات الرسمية والتقييم وخطة تحسين الأداء PIP وأي قرار في مهامه أو عقده](https://arabroot.io/content/images/2026/10/weak-colleague-01-circles.webp) تعمل بكامل قوتك في دائرتك، وتقترح في دائرة الفريق، وتعطي المدير الحقائق في دائرته ثم تتركها له - **دائرتك أنت:** جودة عملك، وطريقة مراجعتك لكوده، وما تقوله له مباشرة، وكم من وقتك تعطيه للمساعدة، وما تقوله للمدير ومتى. وهنا تملك القرار كاملاً. - **دائرة الفريق:** المعايير التي يتفق عليها الجميع، مثل قواعد مراجعة الكود، وتعريف الانتهاء Definition of Done، وما يقال في الاجتماع اليومي، ومن يراجع لمن. وهنا تقترح وتناقش في اجتماع المراجعة الدورية Retrospective، ولا تفرض. - **دائرة المدير وحده:** تشخيص سبب الضعف، ووضع التوقعات الرسمية، وتقييم الأداء Performance Review، وخطة تحسين الأداء PIP، وتغيير مهامه، وأي قرار يخص عقده. وهنا دورك أن تعطي المدير الحقائق، ثم تتركه يعمل. والفائدة من هذا التقسيم أنه يحول الغضب العام «ليش ما أحد يسوي شي؟» إلى أسئلة محددة: هل فعلت كل ما في دائرتي؟ هل اقترحت ما يخص الفريق؟ هل أعطيت المدير الحقائق بطريقة يستطيع أن يعمل بها؟ فإذا كانت الإجابة نعم عن الثلاثة، فما بقي ليس مسؤوليتك، حتى لو لم يعجبك بطء المدير. ولاحظ أن الدائرة الثالثة فيها أشياء لن تراها أبداً، لأن ما يحدث بين المدير والموظف في هذه المرحلة سري، وسوف نعود لهذه النقطة لاحقاً. ## قبل أن تحكم: ما الذي لا تراه من مكانك؟ (Missing Context) أنت ترى من زميلك نتيجة عمله: طلب الدمج، والتأخير، والجملة في الاجتماع اليومي. ولكنك لا ترى أشياء كثيرة قد تكون هي السبب، والمدير الجيد يبحث عنها قبل أن يحكم، كما نشرح في مقال تشخيص ضعف الأداء في هذه المرحلة، حيث نقسم الأسباب إلى ثلاثة: المهارة Skill، أي أنه لا يعرف كيف يفعل المطلوب، والرغبة Will، أي أنه يعرف ولا يفعل، والبيئة Context، أي أن شيئاً حوله يمنعه، مثل توقعات غير واضحة، أو مهمة لا تناسب خبرته، أو ظرف شخصي، أو مدير يكلفه بأشياء لا يعرفها الفريق. ودليل GitLab نفسه يقسم المشكلة إلى نوعين، مهارة Skill-based ورغبة Will-based، ويطلب من المدير أن يتأكد في البداية من أن الموظف أخذ إجازاته، وأن حياته الشخصية بخير. ومن مكانك كزميل لا تستطيع أن تجري هذا التشخيص، ولا يحق لك أن تسأل زميلك عن ظروفه الخاصة، ولكنك تستطيع أن تمتنع عن الحكم على الشخص، وأن تتحدث عن السلوك والنتيجة فقط. فبدلاً من «فلان ضعيف» أو «فلان ما يهتم»، قل لنفسك ثم لغيرك: «آخر أربعة طلبات دمج من فلان رجعت بأخطاء في الاختبارات»، لأن الجملة الثانية صحيحة مهما كان السبب، والأولى حكم قد يتضح لاحقاً أنه خطأ. وهذه العادة ستحميك إذا كان عنده سياق لا تعرفه، وستجعل كلامك مع المدير أقوى إذا لم يكن. وهناك سؤال يفيدك أن تطرحه على نفسك بصدق قبل أي خطوة: هل المشكلة في أداء زميلي، أم في أنه يعمل بطريقة مختلفة عن طريقتي؟ فالزميل الذي يكتب طلبات دمج صغيرة كثيرة بينما تفضل أنت طلباً كبيراً واحداً، أو يسأل كثيراً في القناة، أو يحتاج وقتاً أطول ليفهم قبل أن يكتب، ليس ضعيفاً بالضرورة، وإنما مختلف. والمعيار الذي تستخدمه هنا هو أثر عمله على النظام والفريق: هل تصل أخطاء إلى الإنتاج؟ هل تتأخر مهام يعتمد عليها غيره؟ هل يعيد أحد كتابة كوده؟ فإذا لم يكن هناك أثر، فالأمر خلاف في الأسلوب، ومكانه نقاش هادئ وليس شكوى. ## الحالة الأولى: طلبات الدمج التي تصلحها في الليل (Fixing Their Pull Requests) نعود إلى الشركة الناشئة. أنت المراجع الأول لزميلك في خدمة المدفوعات، وفي آخر ثلاثة أسابيع أرسل خمسة طلبات دمج، أربعة منها عادت بملاحظات أساسية، وفي اثنين منها كتبت أنت الإصلاح بنفسك ودفعته Push على فرعه Branch في الليل لأن الإصدار كان في اليوم التالي. وفي المرة الأخيرة اكتشف فريق الدعم Support خطأً في حساب ضريبة القيمة المضافة VAT في الفواتير، وكان من كود دمجته أنت بعد أن أصلحت نصفه. ### ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse) ما يحدث عادة أن المراجع يستمر في الإصلاح بصمت، لأنه أسرع من الشرح، ولأنه لا يريد أن يحرج زميله، ولأن الإصدار قريب. ومع الوقت يصبح هو صاحب الخدمة الفعلي، ويصبح الزميل ينتظر المراجعة ليعرف ما الخطأ بدلاً من أن يختبر بنفسه، ويتراكم الغضب حتى يخرج في لحظة غير مناسبة، مثل تعليق حاد في طلب دمج أمام الفريق، أو كلام في مجموعة الواتساب الجانبية. وما يزيد الموقف سوءاً ثلاثة أشياء: أن تستمر في كتابة الإصلاحات على فرعه، فيظهر في سجل Git أن الكود كوده وهو ليس كوده، ويظهر في تقييمه أنه سلم بينما سلمت أنت، وأن تشتكي لزملاء آخرين بدلاً من أن تتكلم معه، فيتحول الأمر إلى حديث جانبي عنه، وأن تنفجر في تعليق عام بعد أسابيع من الصمت، فيبدو أنك أنت المشكلة. ### ما الذي ينجح؟ (What Works) الذي ينجح أن تتوقف عن الإصلاح أولاً، وهذا أصعب ما في الأمر. فإرشادات Google لمراجعة الكود تقول في [صفحة كتابة التعليقات](https://google.github.io/eng-practices/review/reviewer/comments.html?ref=arabroot.io) إن إصلاح طلب الدمج مسؤولية كاتبه وليس مسؤولية المراجع، وإن المراجع ليس مطلوباً منه أن يصمم الحل أو يكتب الكود، مع أن عليه أن يوازن بين الإشارة إلى المشكلة والتوجيه المباشر. ولذلك تكتب في التعليق المشكلة وسببها وأين يجد المثال الصحيح، وتعيد الطلب إليه، وإذا كان الإصدار في خطر تقول ذلك لقائد الفريق Team Lead صراحة في وقته، بدلاً من أن تحمي الإصدار بليلة عمل لا يعرف عنها أحد. والشيء الثاني أن تتحدث معه مباشرة في جلسة قصيرة، بعيداً عن طلب الدمج، وتسأله قبل أن تحكم: هل يعرف كيف تعمل الخدمة؟ هل أخذ وقتاً كافياً عندما استلمها؟ ما الذي يصعب عليه؟ وفي هذه الحالة كان الجواب مفاجئاً: فقد استلم الخدمة من مهندس غادر الشركة دون أي تسليم Handover، ولم يكن هناك توثيق لقواعد الضريبة، وكان يكتشف المنطق Logic من الكود نفسه. والشيء الثالث أن تقترح ساعة برمجة ثنائية Pair Programming مرتين في الأسبوع لمدة أسبوعين، يقود فيها هو لوحة المفاتيح وتشرح أنت، وأن تكتبا معاً قائمة فحص Checklist قصيرة لكل طلب دمج في الخدمة: اختبارات الحالات الحدية Edge Cases، وتشغيل الاختبارات محلياً، وتجربة شاشة الفاتورة. وبعد ذلك تخبر قائد الفريق بما وجدته، أي أن الخدمة بلا توثيق، وأنكما تعملان على ذلك، لأن هذه معلومة يحتاجها، وليست شكوى على زميلك. ### عبارات تقولها أو تكتبها (What to Say) في تعليق طلب الدمج، بدلاً من أن تصلح بنفسك: > «الحساب هنا يطبق الضريبة على المبلغ بعد الخصم مرتين. المثال الصحيح في `InvoiceCalculator.applyDiscount`. ممكن تضيف اختبار للحالة اللي فيها خصم وضريبة مع بعض؟ وإذا تبغى نمر عليها سوا بعد الظهر، أنا فاضي.» في الجلسة المباشرة معه: > «لاحظت إن آخر كم طلب دمج في المدفوعات رجعت بملاحظات كثيرة، وأنا صرت أصلح بعضها بنفسي، وهذا مو صح لا لك ولا لي. أبغى أفهم: وش أصعب شي في الخدمة؟ وش اللي ممكن يساعدك؟» لقائد الفريق، بعد الجلسة: > «للعلم: خدمة المدفوعات انتقلت لفلان بدون تسليم ولا توثيق لقواعد الضريبة، وهذا سبب جزء من الأخطاء الأخيرة. اتفقنا على جلستين أسبوعياً لمدة أسبوعين وقائمة فحص لطلبات الدمج. وإصدار الخميس ممكن يتأخر يوم إذا ما خلصت الاختبارات، أفضل نعرف من الحين.» ولاحظ أن الرسالة الأخيرة لا تحكم على زميلك، وإنما تعطي المدير ثلاث معلومات يحتاجها: سبب في البيئة، وخطة، وخطر على موعد. وفي هذه الحالة تحسن زميلك خلال شهر بشكل واضح، وبدأ هو نفسه يكتب صفحة توثيق للخدمة، وتبين أن الضعف كان نصفه في البيئة ونصفه في مهارة تحتاج تدريباً، وكلاهما شيء يحل. ## المساعدة دون أن تحمل عنه (Help Without Carrying) الفرق بين المساعدة وحمل العمل عنه هو من يتعلم في النهاية. فعندما تساعد زميلك يخرج من الموقف وهو يعرف شيئاً لم يكن يعرفه، ويستطيع أن يفعله وحده في المرة القادمة، أما عندما تحمل عنه فيخرج والعمل منجز وهو لا يعرف كيف أنجز، فيعود إليك في المرة القادمة، وتعود أنت لتنجزه. وحمل العمل عنه يبدو لطيفاً في لحظته، ولكنه يضر الطرفين على المدى الطويل: أنت تتعب ويقل وقتك لعملك، وهو لا يتحسن، ويظهر في التقييم أنه بخير، فلا يحصل على الدعم الذي يحتاجه، والمدير لا يعرف أن هناك مشكلة أصلاً. ![جدول مقارنة بين المساعدة وحمل العمل عنه في أربعة مواقف: في طلب الدمج المساعدة تعليق يشرح المشكلة ومكان المثال وحمل العمل عنه أن تكتب الإصلاح على فرعه، وفي المهمة المتأخرة المساعدة جلسة برمجة ثنائية يقود فيها هو وحمل العمل عنه أن تنهيها في الليل، وفي الاجتماع اليومي المساعدة أن تسأله عن العائق وحمل العمل عنه أن تجيب نيابة عنه، وأمام المدير المساعدة أن تذكر الحقائق وحمل العمل عنه أن تخفي المشكلة، مع ملاحظة أن السؤال هو من يتعلم في النهاية](https://arabroot.io/content/images/2026/10/weak-colleague-02-help-vs-carry.webp) المساعدة تترك زميلك أقدر في المرة القادمة، وحمل العمل عنه يترك العمل منجزاً والمشكلة كما هي وبعض القواعد العملية تساعدك أن تبقى في جهة المساعدة: - **اشرح ولا تكتب:** في المراجعة اكتب المشكلة وسببها ومثالاً صحيحاً من الكود، واترك الإصلاح له، إلا في حالة طارئة حقيقية، وفي هذه الحالة قل ذلك في طلب الدمج نفسه حتى يكون واضحاً من كتب ماذا. - **حدد وقت المساعدة:** «ساعة يوم الأحد والثلاثاء» أفضل من «اسألني أي وقت»، لأن الثانية تتحول إلى مقاطعات طوال اليوم، وتجعلك تؤجل عملك دون أن يرى أحد. - **اجعله يقود:** في البرمجة الثنائية يكتب هو وتتكلم أنت، لأن من يكتب هو من يتعلم. - **اجعل العمل الإضافي مرئياً:** إذا كنت تقضي ساعات في دعمه، فهذا عمل حقيقي، فاذكره في الاجتماع اليومي أو مع قائد الفريق، بدون شكوى: «أمس قضيت ساعتين مع فلان في خدمة المدفوعات». - **توقف عندما لا يتغير شيء:** إذا ساعدت أسبوعين ولم يتغير شيء، فالمشكلة ليست في نقص المساعدة، وأصبح مكانها عند المدير. والقاعدة الأخيرة مهمة، لأن بعض المهندسين الطيبين يستمرون في المساعدة شهوراً على أمل أن تتحسن الأمور، وكتاب Software Engineering at Google يذكر في [الفصل الخامس عن قيادة الفريق](https://abseil.io/resources/swe-book/html/ch05.html?ref=arabroot.io) شعار فريق موثوقية المواقع SRE «الأمل ليس استراتيجية» Hope is not a strategy، ويقول إن الأمل لا يستخدم بإفراط في شيء أكثر من التعامل مع ضعيف الأداء. والكتاب يكتب هذا للقادة، ولكنه صحيح لك أيضاً: الأمل بأن يتحسن زميلك وحده، وأنت تحمل عمله في الخلفية، ليس خطة. ## مراجعة الكود والبرمجة الثنائية كأدوات تعليم (Code Review and Pairing) مراجعة الكود هي أقوى أداة في يدك كزميل، لأنها المكان الوحيد الذي ترى فيه عمله وتؤثر فيه بشكل رسمي ومقبول. ولكنها أيضاً المكان الذي يتحول فيه الإحباط إلى تعليقات حادة بسهولة. والإرشادات المنشورة من Google لمراجعة الكود فيها ثلاث نقاط تفيدك في هذا الموقف بالذات. الأولى في [صفحة معيار المراجعة](https://google.github.io/eng-practices/review/reviewer/standard.html?ref=arabroot.io)، وهي أن المراجع يوافق على التغيير عندما يحسن صحة الكود Code Health بشكل واضح حتى لو لم يكن كاملاً، فلا يوجد كود كامل، وإنما كود أفضل، وهذا يمنعك من تحويل كل طلب دمج من زميلك الضعيف إلى قائمة طويلة من الملاحظات الصغيرة التي تحبطه ولا تعلمه. والثانية في نفس الصفحة، وهي أن المراجعة مكان للتعليم Mentoring، وأن التعليق التعليمي غير الضروري يبدأ بكلمة Nit حتى يعرف الكاتب أنه ليس إلزامياً، وهذا يساعدك أن تفصل بين «هذا خطأ يجب إصلاحه» و«هذه طريقة أفضل للمستقبل». والنقطة الثالثة في صفحة كتابة التعليقات، وهي أن يكون التعليق عن الكود وليس عن الشخص، ومثالها في الصفحة نفسها أن تكتب أن نموذج التزامن Concurrency هنا يضيف تعقيداً دون فائدة في الأداء، بدلاً من أن تسأل لماذا استخدم الخيوط Threads وفائدتها «واضحة» أنها معدومة. وهذا الفرق يصبح أهم عندما تكون محبطاً من الشخص، لأن الإحباط يتسرب إلى الكلمات: «مرة ثانية؟» أو «كالعادة» أو «واضح إنك ما جربتها». وهذه الكلمات لا تعلم شيئاً، وتجعل زميلك يدافع عن نفسه بدلاً من أن يقرأ الملاحظة، ويراها كل من يفتح طلب الدمج. أما البرمجة الثنائية فهي أسرع طريقة لتعرف هل المشكلة مهارة أم شيء آخر. ففي ساعة واحدة تجلس فيها معه ويقود هو، سوف ترى هل يعرف كيف يشغل الاختبارات، وهل يفهم الخدمة، وأين يتوقف، وهل يستمع ويطبق أم يرد على كل اقتراح. فإذا كان يتعلم بسرعة عندما يشرح له أحد، فالمشكلة في الغالب مهارة أو بيئة، وستتحسن. وإذا كان يعرف كل شيء في الجلسة، ثم يرسل نفس الأخطاء بعدها، فالمشكلة شيء آخر، وهذا ليس شيئاً تحله أنت. ولاحظ أن هذه ملاحظة لك، لتعرف متى تتوقف، وليست تشخيصاً تنقله للآخرين. ## الحديث المباشر معه أولاً (Talk to Them First) أغلب الناس يقفزون فوق هذه الخطوة، فيذهبون مباشرة إلى المدير، أو يكتفون بالحديث مع الزملاء الآخرين. والسبب أن الحديث المباشر محرج، فأنت لست مديره، وتخاف أن يقول لك «وأنت مين عشان تقول لي؟». ولكن الحديث المباشر أعدل طريقة للتعامل مع الموقف، لأنه يعطي زميلك فرصة أن يعرف المشكلة قبل أن يعرفها مديره منك، وأن يشرح سياقه إن كان عنده سياق، وأن يصلح دون أن يتحول الأمر إلى ملف. وهو أيضاً ما سيسألك عنه المدير عندما تتحدث معه: «كلمته؟». والحديث الجيد قصير، وفي مكان خاص، ويبدأ بما رأيته أنت وأثره عليك، ثم سؤال حقيقي، وليس محاكمة. وصيغة الموقف والسلوك والأثر SBI التي شرحناها في مقال الملاحظات الصعبة تناسبه تماماً: الموقف «في إصدار الأسبوع الماضي»، والسلوك «طلب الدمج وصل بدون اختبار للخصم»، والأثر «أنا قعدت لين الساعة 11 أصلحه، والخطأ وصل للعملاء». ثم تسأل وتسكت. والسكوت هنا مهم، لأن كثيراً من الزملاء يقولون في هذه اللحظة شيئاً لم تكن تعرفه: «أصلاً ما أحد شرح لي الخدمة»، أو «عندي ظرف في البيت هالفترة»، أو «المدير معطيني مهمة ثانية لفريق المبيعات ما أحد يدري عنها». وهناك أشياء لا تفعلها في هذا الحديث: لا تتحدث باسم الفريق «كلنا نشوف إنك...»، لأنك لا تعرف رأي الجميع، ولأن الجملة تجعله يشعر أن هناك اجتماعاً عنه دون حضوره، ولا تقارنه بأحد، ولا تذكر أشياء قديمة من شهور، ولا تقدم له نصائح عن حياته أو مستقبله، ولا تهدده بأنك ستخبر المدير، وإنما إذا قررت أن تخبر المدير بعد ذلك فقل له ذلك بهدوء في وقته. وإذا لم يكن بينكما علاقة تسمح بهذا الحديث، أو كان زميلك أعلى منك بكثير في المستوى، أو كان الموضوع أكبر من ملاحظة عمل، فلا بأس أن تتجاوز هذه الخطوة وتتحدث مع المدير مباشرة. ## الحالة الثانية: «تقريباً خلصت» في كل اجتماع يومي (Always Almost Done) في شركة متوسطة الحجم فيها خمسة فرق منتجات Product Teams، انتقل مهندس واجهات أمامية Frontend Engineer قبل أربعة أشهر إلى فريق المنصة Platform Team ضمن إعادة تنظيم، وأصبح مسؤولاً عن جزء من خط النشر CI/CD Pipeline وإعدادات Kubernetes. وفي كل اجتماع يومي يقول عن مهمته «تقريباً خلصت، باقي شوية أشياء»، وبعد أسبوعين لا تزال المهمة مفتوحة، والفرق الأخرى تنتظر تغيير الإعدادات. وأنت زميله في نفس الفريق، وبدأت تأخذ مهامه الصغيرة دون أن تقول، لأن فريقاً آخر يسألك عنها كل يوم. ### ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse) ما يحدث عادة أن الفريق يتعلم ألا يصدق جملة «تقريباً خلصت»، ثم يبدأ في العمل من حوله، فيأخذ زميل مهمة، ويعيد آخر كتابة ملف، ويطلب فريق آخر من قائد الفريق ألا يسند لهم شيئاً عنده. وما يزيد الموقف سوءاً أن يسخر أحد في القناة «تقريباً تبع فلان»، أو أن يتجاهل قائد الفريق الموضوع لأن الفريق «يمشي الأمور»، أو أن تأخذ أنت مهامه في صمت حتى يأتي التقييم وأنت مرهق ولم تنجز مهامك الأصلية. ### ما الذي ينجح؟ (What Works) الذي ينجح أن تجعل الحالة الحقيقية للعمل مرئية بلطف، لأن «تقريباً خلصت» في الغالب جملة يقولها من لا يعرف كم بقي، أو يخجل أن يقول إنه عالق. ففي الاجتماع اليومي أو بعده تسأله سؤالاً محدداً: «وش الخطوة اللي واقف عندها؟»، وتعرض المساعدة في تلك الخطوة بالذات. وفي هذه الحالة تبين في جلسة قصيرة أنه لا يعرف كيف يختبر إعدادات Kubernetes محلياً، فكان يجرب كل تغيير بنشره في بيئة الاختبار Staging والانتظار عشرين دقيقة، وكان يخجل أن يسأل لأنه «المفروض» يعرف بعد أربعة أشهر. والمشكلة الأعمق كانت أن الرجل قوي جداً في الواجهات الأمامية، ونقل إلى فريق المنصة دون رغبته ولا تدريب، أي أن السبب في الدور Wrong Role وليس في الشخص. ودورك هنا محدود ولكنه مهم: ساعدته في الخطوة التي كان عالقاً فيها، واقترحت على الفريق في اجتماع المراجعة الدورية قاعدة عامة لكل الفريق، وهي أن كل مهمة تتجاوز ثلاثة أيام تقسم إلى خطوات صغيرة في لوحة المهام Board، فتظهر الخطوة العالقة للجميع دون أن يستهدف أحد، ثم قلت لقائد الفريق ما رأيته عن الدور، لأن هذا قرار لا يخصك. وبعد شهرين انتقل الزميل إلى فريق منتجات يحتاج مهندس واجهات، وأصبح من أفضل من فيه. ### عبارات تقولها أو تكتبها (What to Say) في الاجتماع اليومي أو بعده مباشرة: > «مهمة إعدادات الـ Ingress، وش الجزء اللي باقي بالضبط؟ إذا هو الاختبار، أقدر أوريك كيف أشغلها محلياً بـ kind، ياخذ عشر دقايق.» في اجتماع المراجعة الدورية، كاقتراح عام: > «أقترح أي مهمة أكبر من ثلاث أيام نقسمها لخطوات في اللوحة، عشان نعرف وين نقدر نساعد بعض بدري. أنا أول واحد بطبقها على مهامي.» لقائد الفريق: > «فلان شاطر في الواجهات، وواضح إنه يعاني في شغل المنصة لأنه ما أخذ تدريب. ساعدته في موضوع الاختبار المحلي، بس أعتقد السؤال الأكبر هو هل الدور مناسب له، وهذا قرارك.» ## متى ترفع الأمر للمدير، وكيف؟ (Raising It With the Manager) ترفع الأمر للمدير في واحدة من ثلاث حالات: إذا تحدثت مع زميلك وساعدته ولم يتغير شيء خلال أسبوعين أو ثلاثة، أو إذا كان هناك أثر على النظام أو العملاء أو مواعيد يعتمد عليها آخرون لا يحتمل الانتظار، أو إذا كان العمل الإضافي الذي تحمله بدأ يؤثر على عملك أنت. وفي الحالات الثلاث، الهدف من الحديث ليس أن يعاقب المدير زميلك، وإنما أن يحصل المدير على معلومة لا يراها، لأن المدير غالباً بعيد عن تفاصيل طلبات الدمج والاجتماع اليومي، ولا يرى إلا النتائج المتأخرة. والفرق بين البلاغ المهني والنميمة واضح إذا انتبهت له. فالبلاغ يذهب لمن يستطيع أن يفعل شيئاً، أي المدير المباشر، أما النميمة فتذهب لمن لا يستطيع، أي الزملاء. والبلاغ فيه وقائع بتواريخ وأثر، أما النميمة ففيها صفات وأحكام «ما يفهم» و«ما يهتم». والبلاغ يذكر ما فعلته أنت، أما النميمة فتطلب من الآخرين أن يتفقوا معك. والبلاغ يقال مرة واحدة ثم يترك للمدير، أما النميمة فتتكرر في كل استراحة قهوة. ![مقارنة بين البلاغ المهني Report والنميمة Gossip في خمسة جوانب: لمن يقال، البلاغ للمدير المباشر الذي يستطيع أن يفعل شيئاً والنميمة لزملاء لا يستطيعون، وماذا يحتوي، البلاغ وقائع بتواريخ والنميمة صفات وأحكام، والأثر، البلاغ يذكر أثراً على النظام والمواعيد والنميمة تذكر مشاعر عامة، وما فعلته، البلاغ يذكر أنك تحدثت معه وساعدته والنميمة لا تذكر شيئاً، وكم مرة، البلاغ مرة ثم يترك للمدير والنميمة تتكرر في كل استراحة](https://arabroot.io/content/images/2026/10/weak-colleague-03-report-vs-gossip.webp) البلاغ يعطي المدير ما يستطيع أن يعمل به، والنميمة تضر زميلك وتضرك معه والحديث الجيد مع المدير يحتوي أربعة أشياء، ويأخذ خمس دقائق في الاجتماع الفردي One-on-One: الوقائع، أي ما حدث بالتواريخ والروابط، مثل أربعة طلبات دمج في ثلاثة أسابيع رجعت بأخطاء في الاختبارات وخطأ الضريبة الذي وصل للعملاء، والأثر على النظام والفريق والمواعيد وعليك، مثل عشر ساعات إصلاح في أسبوعين وتأخر مهمتك، وما فعلته أنت، أي أنك تحدثت معه وساعدته في جلستين وما تغير، وما تطلبه، وهو في الغالب أن يعرف المدير، وأن يقرر هو، وأن يوضح لك ما المتوقع منك في المراجعة من الآن. ولاحظ أن ما تطلبه لا يتضمن عقوبة ولا نقلاً ولا فصلاً، فهذه قرارات المدير، وإذا طلبتها أنت فقد خرجت من دورك وأضعفت كلامك. ولا تكتب للمدير رسالة طويلة في المحادثة الجماعية، ولا ترسل له قائمة بكل أخطاء زميلك منذ انضمامه، ولا تجمع توقيعات الزملاء، لأن كل هذا يحول البلاغ إلى حملة. وإذا سألك المدير عن رأيك في الشخص نفسه، فأعد الحديث إلى الوقائع: «ما أعرف السبب، اللي أعرفه إن...». ### ماذا يحدث بعد أن تخبر المدير؟ (After You Raise It) الجزء الذي يحبط أكثر الزملاء أنهم يخبرون المدير ثم لا يرون شيئاً يتغير لأسابيع، فيظنون أن المدير تجاهلهم. والحقيقة في الغالب أن المدير بدأ عملاً لن تراه، لأن ما يحدث بين المدير والموظف في هذه المرحلة سري ويجب أن يكون سرياً: محادثات فردية، وتوضيح للتوقعات، وتدريب، وربما خطة تحسين أداء PIP مكتوبة، وكل هذا يأخذ أسابيع أو أشهراً، والمدير لا يخبر بقية الفريق عنه، احتراماً للموظف، وحماية للشركة. ودليل GitLab مثلاً يطلب من المدير أن يتحدث مع فريق علاقات الموظفين Team Member Relations مبكراً، وأن يوثق كل محادثة تدريب ويشاركها مع الموظف، وأن يلتقي به أسبوعياً، وكل هذا يحدث بعيداً عن الفريق. ولذلك لا تسأل المدير بعد أسبوع «وش صار في موضوع فلان؟»، لأنه لن يجيبك، ولا يجب أن يجيبك، وإنما اسأل عن عملك أنت: «هل أستمر في مراجعة طلبات المدفوعات، أو تبغى أحد ثاني يراجع معي؟»، أو «إذا تأخرت مهمة فلان مرة ثانية، وش تبغاني أسوي؟». وإذا تكرر الأثر بعد ذلك، فأخبر المدير بالواقعة الجديدة كما هي، دون أن تقول «قلت لك». وإذا مرت أشهر والأثر كما هو، والمدير لا يبدو أنه يعمل شيئاً، فهذه مشكلة مختلفة، تخص المدير وليس زميلك، ولها مقالات عن المدير الذي لا يفهم عمل فريقه أو يحبطه نضع روابطها في آخر المقال. ## الحالة الثالثة: الحد الأدنى من الجهد في جهة حكومية (Minimum Effort) في إدارة تقنية المعلومات في جهة حكومية، يعمل فريق صغير من موظفين ومهندسين من شركة متعاقدة Contractor على تطوير بوابة خدمات إلكترونية. وزميلك في الفريق موظف منذ سنوات، يعرف الأنظمة جيداً، ولكنه يرد على كل طلب بأنه «من شغل المتعاقد»، ويحضر الاجتماعات دون أن يقول شيئاً، ويحول كل تذكرة Ticket تصله إلى غيره، وعندما تعطلت خدمة يعرفها جيداً في نهاية الأسبوع لم يرد على الهاتف، وتحملت أنت الإصلاح مع مهندس المتعاقد حتى الفجر. ### ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse) ما يحدث عادة في هذه البيئة أن الجميع يعرف، ولا أحد يتكلم، لأن الشخص «من زمان هنا» ولأن التغيير بطيء، فيتوزع عمله على من يهتم، ويصبح الزملاء المتحمسون هم من يحترقون. وما يزيد الموقف سوءاً أن تتحول إلى صورة معاكسة منه، فتأخذ كل شيء حتى تحترق، أو أن تتوقف أنت أيضاً عن الاهتمام لأنك ترى أنه لا فرق بين من يعمل ومن لا يعمل، وهذا بالضبط الانتقال الذي وصفه Felps في تجربته، أو أن تواجهه بحدة أمام مهندسي المتعاقد فيصبح الخلاف علنياً. ### ما الذي ينجح؟ (What Works) هذه الحالة مختلفة عن الحالتين السابقتين، لأن زميلك يعرف العمل، والمشكلة في الغالب ليست مهارة، ولكنك لا تعرف إن كانت رغبة أم شيئاً في البيئة، فربما وعد بترقية لم تحدث، أو أخذت منه مسؤوليات سابقة للمتعاقد فشعر أنه بلا دور، وكل هذا ليس شيئاً تحله أنت. والذي ينجح أن تجعل المسؤوليات واضحة ومكتوبة، فتطلب من رئيس القسم توزيعاً مكتوباً للمسؤوليات Ownership لكل خدمة، يتضمن من المسؤول الأول ومن البديل في المناوبة، لأن هذا الطلب مشروع ويخص الجميع وليس زميلك وحده. ثم ترد على التذاكر التي تحول إليك وهي ليست مسؤوليتك بإعادتها حسب التوزيع، بأدب ودون تعليق. وبعد عطل نهاية الأسبوع تكتب تقرير الحادثة Incident Report بالوقائع: من اتصل بمن ومتى، ومن رد، وكم استغرق الإصلاح، دون أي حكم، فهذا التقرير يصل إلى رئيس القسم ويقول ما يجب قوله دون أن تقوله أنت. وفي هذه الحالة لم يتغير زميلك كثيراً، ولكن تغير وضعك أنت: أصبحت مسؤولياتك مكتوبة، وأصبح من يتصل في المناوبة معروفاً، وأصبح رئيس القسم يعرف من التقارير ما يحدث، وما يفعله بهذه المعرفة قراره هو. وهذا مهم أن تقبله، فليس كل قصة تنتهي بأن يتحسن الزميل أو يغادر، وبعضها ينتهي بأن تحمي عملك ووقتك وتتوقف عن حمل ما ليس لك. ### عبارات تقولها أو تكتبها (What to Say) لرئيس القسم، في طلب عام: > «نحتاج جدول مسؤوليات مكتوب لكل خدمة في البوابة: المسؤول الأول والبديل في المناوبة. في عطل الخميس الماضي ما كان واضح مين نتصل عليه، وتأخر الإصلاح ثلاث ساعات.» عند إعادة تذكرة ليست من مسؤوليتك: > «حسب جدول المسؤوليات، خدمة المواعيد عند فلان. رجعت له التذكرة، وإذا احتاج أي معلومة مني أنا موجود.» لزميلك مباشرة، إذا أردت أن تقول شيئاً: > «الخميس اتصلت عليك أكثر من مرة عشان خدمة المواعيد، وأنت أكثر واحد يعرفها. إذا ما تقدر ترد في نهاية الأسبوع، خلنا نتفق مين البديل، بس ما أبغى أكتشف هذا والخدمة طايحة.» ## حماية عملك وسمعتك (Protecting Your Work) عندما تعمل بجانب زميل ضعيف الأداء، فإن خطراً حقيقياً يقع عليك أنت: أن يختلط عملك بعمله، فيحسب عليك خطؤه، أو يحسب له جهدك، أو تصبح أنت الشخص المرهق الغاضب في عيون الفريق. وبعض العادات البسيطة تحميك: - **اجعل الملكية واضحة:** كل تذكرة لها مسؤول واحد، وإذا أخذت جزءاً من عمله فليكن في تذكرة باسمك، أو في تعليق واضح في تذكرته، وليس في الخفاء. - **لا تدفع على فرعه إلا وأنت تقول ذلك:** إذا اضطررت لكتابة كود في طلب دمجه، فاكتب في الطلب «أضفت هذا الإصلاح بسبب موعد الإصدار»، حتى يكون سجل Git والتقييم صادقين. - **اكتب التسليم Handover:** عندما يعتمد عملك على عمله، اكتب ما تحتاجه منه وموعده في التذكرة، فإذا تأخر يكون التأخير واضح المصدر دون أن تشتكي. - **لا تتحدث عنه في المجموعات الجانبية:** الكلام عنه في الواتساب أو في الاستراحة يصل غالباً، ويجعلك طرفاً في خلاف بدلاً من أن تكون شاهداً على وقائع. - **لا تأخذ فضل عمله:** إذا ساعدته في شيء، فالعمل عمله، وإذا كان لك جزء حقيقي فاذكره بدقة، كما نشرح في مقال سرقة الجهد والنميمة. - **احم وقتك:** المساعدة لها حد، وعندما تتجاوز ما اتفقت عليه مع قائد الفريق، فاذكر ذلك قبل أن يتأخر عملك. والسمعة التي تريدها في هذا الموقف ليست «الشخص الذي يصلح كل شيء» ولا «الشخص الذي يشتكي من زملائه»، وإنما الشخص الذي يساعد بوضوح، ويقول الوقائع لمن يجب، ويعمل عمله جيداً. وهذه السمعة تبنى بالسلوك نفسه في كل مرة، وليس بموقف واحد. ## عندما تكون مخطئاً في حكمك (When You Were Wrong) نعود إلى الحالة الأولى، لأن فيها جزءاً لم نذكره بعد. فبعد شهر من جلسات البرمجة الثنائية، وتحسن طلبات الدمج، عرفت من زميلك نفسه، في حديث عابر، أن والده كان في المستشفى طوال تلك الأسابيع الثلاثة، وأنه كان يقضي الليالي هناك، ويعمل من هاتفه في الممرات، ولم يقل لأحد لأنه لا يحب أن يتحدث عن أموره الخاصة، وأن مديركما كان يعرف، وأعطاه مرونة في الوقت، ولم يخبر الفريق احتراماً لخصوصيته. أي أن كل ما رأيته كان صحيحاً كوقائع، ولكن التفسير الذي كنت تبنيه في رأسك «ما يهتم» أو «ضعيف» كان خطأً. ![مقارنة بين ما رآه الزميل وما كان يحدث فعلاً في الحالة الأولى: رأى طلبات دمج بأخطاء متكررة والحقيقة أن الخدمة انتقلت دون تسليم ولا توثيق، ورأى تأخراً في الرد مساءً والحقيقة أن والده في المستشفى وكان يعمل من الممرات، ورأى أن المدير لا يفعل شيئاً والحقيقة أن المدير كان يعرف وأعطاه مرونة دون أن يخبر الفريق، والخلاصة أن الوقائع كانت صحيحة والتفسير كان خطأ](https://arabroot.io/content/images/2026/10/weak-colleague-04-seen-vs-real.webp) الوقائع التي تراها صحيحة غالباً، والتفسير الذي تبنيه حولها هو ما يخطئ وهذه القصة ليست نادرة، والسبب أن الظروف الشخصية، مثل المرض في العائلة، أو الطلاق، أو مشكلة مالية، أو مرض الشخص نفسه، أو حتى ضغط مهمة من إدارة أخرى، لا تظهر للزملاء، ودليل GitLab نفسه ينصح الموظف أن يخبر مديره بالظروف التي تؤثر على عمله دون أن يضطر لذكر التفاصيل، فيعرف المدير ويبقى الفريق لا يعرف. ولذلك فإن العادة التي ذكرناها في البداية، أي أن تتحدث عن الوقائع وليس عن الشخص، ليست أدباً فقط، وإنما حماية لك من أن تقول شيئاً تندم عليه. فلو كنت قلت في القناة «فلان ما يهتم» في تلك الأسابيع، لكانت الجملة الآن عبئاً عليك، أما الجملة «طلبات الدمج الأخيرة فيها أخطاء في الاختبارات» فبقيت صحيحة، وساعدت في حل المشكلة. وعندما تكتشف أنك كنت مخطئاً، فلا تحتاج أن تعتذر عن شيء لم تقله، ولكن إذا كنت قلت شيئاً عن الشخص لأحد، فصحح ذلك عند نفس الشخص: «كنت قايل لك إن فلان ما يهتم، طلعت غلطان، كان عنده ظرف». وهذه الجملة الصغيرة تفعل الكثير لسمعة زميلك ولسمعتك أنت. ## وإذا كنت أنت الزميل الضعيف؟ (When It Is You) قد تقرأ هذا المقال وتجد نفسك في مكان الزميل، لا في مكان من يراجع له، فتعرف أن طلباتك ترجع كثيراً، وأن زملاءك بدؤوا يأخذون مهامك، وأنك تقول «تقريباً خلصت» وأنت لا تعرف كم بقي. والخطوة الأولى أن تقول ذلك قبل أن يقوله غيرك، فإذا كان عندك ظرف شخصي فأخبر مديرك بأن هناك ظرفاً يؤثر على عملك، ومتى بدأ، وتقديرك لمتى يتحسن، دون أن تضطر لذكر التفاصيل، وهذه نصيحة دليل GitLab نفسه، الذي يقول إن تأجيل هذا الحديث حتى يكتشف المدير ضعف الأداء بنفسه يضيع ثقة كنت ستحتاجها. وإذا كانت المشكلة مهارة، فاطلب تدريباً أو جلسات مع زميل يعرف الخدمة، وقل بوضوح أين تتوقف. وإذا كانت المشكلة أن الدور لا يناسبك، فقل ذلك لمديرك كطلب، وليس كشكوى. وإذا كنت مرهقاً لدرجة أن كل شيء صار ثقيلاً، فقد يكون ما تمر به احتراقاً، وله مقال مستقل. وإذا جاءك زميل يتحدث معك كما شرحنا في هذا المقال، فهو في الغالب يحاول أن يساعدك قبل أن يذهب للمدير، فاستمع، واشكره، وقل ما تستطيع أن تقوله عن سياقك، واطلب المساعدة المحددة التي تحتاجها. ## أخطاء شائعة (Common Mistakes) - **الإصلاح الصامت:** تصلح عمله في الليل دون أن تقول، فيبدو في التقييم بخير، وتبدو أنت متأخراً في عملك. - **الحكم على الشخص بدلاً من وصف السلوك:** «ضعيف» و«ما يهتم» أحكام لا تعرف إن كانت صحيحة، و«آخر أربعة طلبات رجعت بأخطاء» وقائع لا تختلف عليها. - **الكلام في المجموعات الجانبية:** يصل غالباً، ويحولك من شاهد إلى طرف في خلاف. - **تجاوز الحديث المباشر دون سبب:** المدير سيسألك «كلمته؟»، وزميلك سيشعر أنه فوجئ. - **طلب عقوبة من المدير:** النقل والفصل وخطة تحسين الأداء قرارات المدير، وطلبها منك يضعف كلامك. - **التعليقات الحادة في المراجعة:** «مرة ثانية؟» و«كالعادة» يراها الجميع، ولا تعلم شيئاً. - **المساعدة بلا حد:** شهور من الدعم دون تغيير ليست كرماً، وإنما تأجيل للمشكلة. - **انتظار التحديثات عن زميلك:** ما يحدث بينه وبين المدير سري، واسأل عن عملك أنت. - **التوقف عن الاهتمام:** أن تصبح مثله لأنك ترى أنه لا فرق، فيصبح في الفريق شخصان بدلاً من شخص. ## الأداة: نص المحادثة وسلم الخطوات (Peer Conversation Script) الأداة العملية في هذا المقال ملف `lab/peer-conversation.md`، وفيه أربعة أجزاء: سجل وقائع قصير تكتب فيه ما تراه بالتواريخ قبل أن تتكلم مع أحد، ونص للحديث المباشر مع زميلك، ونص للحديث مع المدير، وأسئلة تسألها نفسك قبل كل خطوة. والفكرة أن تمر بالخطوات بالترتيب، وألا تقفز إلى الأخيرة لأنك غاضب. ![سلم من خمس خطوات للتعامل مع زميل ضعيف: أولاً سجل الوقائع بالتواريخ لمدة أسبوعين دون أحكام، ثانياً غير ما في دائرتك مثل طريقة المراجعة وتوقف عن الإصلاح الصامت، ثالثاً تحدث معه مباشرة بصيغة الموقف والسلوك والأثر واسأل عن السياق، رابعاً ساعده لمدة محددة ببرمجة ثنائية وقائمة فحص، خامساً إذا لم يتغير شيء أو كان الأثر كبيراً أخبر المدير بالوقائع والأثر وما فعلته ثم اتركه له](https://arabroot.io/content/images/2026/10/weak-colleague-05-steps.webp) كل خطوة تعطي زميلك فرصة، وتعطيك أنت أساساً أقوى للخطوة التالية ```markdown ## 1. سجل الوقائع (أسبوعان قبل أي حديث) | التاريخ | ما حدث (واقعة، رابط) | الأثر (على النظام، الموعد، وقتي) | ما فعلته أنا | |---|---|---|---| | | | | | ## 2. الحديث المباشر مع زميلي - الموقف: "في ..." - السلوك: "لاحظت إن ..." - الأثر: "وهذا خلاني / خلى ..." - السؤال: "وش اللي يصعب عليك فيها؟ وش اللي يساعدك؟" - ثم أسكت وأسمع. - ما اتفقنا عليه، وموعد المراجعة: ## 3. الحديث مع المدير (إذا لم يتغير شيء خلال 2-3 أسابيع، أو الأثر كبير) - الوقائع بالتواريخ: - الأثر: - ما فعلته (الحديث، المساعدة): - ما أطلبه: أن تعرف، وأن توضح لي دوري في المراجعة من الآن. ## 4. أسئلة قبل كل خطوة - هل أصف سلوكاً أم أحكم على شخص؟ - هل هذا أداء ضعيف أم أسلوب مختلف عن أسلوبي؟ - هل أعرف كل السياق؟ (غالباً لا) - هل أكلم من يستطيع أن يفعل شيئاً؟ ``` في الملف أعلاه لاحظ التالي: - الجزء الأول يطلب أسبوعين من الوقائع قبل أي حديث، لأن الذاكرة تحتفظ بالمواقف التي أغضبتك وتنسى الأيام العادية، والسجل يعطيك صورة أعدل. - عمود «ما فعلته أنا» يذكرك بأن جزءاً من الحل في يدك، مثل التوقف عن الإصلاح الصامت، وهو ما سيسألك عنه المدير. - الجزء الثاني ينتهي بالسكوت والسماع، لأن السياق الذي لا تعرفه يظهر في الغالب في هذه اللحظة. - الجزء الثالث لا يحتوي خانة «ما أقترحه من عقوبة»، لأن هذا ليس دورك. - الجزء الرابع أسئلة تمنعك من أن تتحول إلى الشخص الذي يشتكي، أو من أن تحكم قبل أن تعرف. ## قائمة تحقق (Checklist) | إذا لاحظت | جرب | | ------------------------------------- | -------------------------------------------------------------------- | | تصلح طلبات دمج زميلك بنفسك | توقف، واكتب المشكلة وسببها ومثالاً في التعليق، وأعده إليه | | غاضب وتريد أن تقول «ضعيف» | اكتب الوقائع بالتواريخ أسبوعين قبل أي حديث | | «تقريباً خلصت» كل يوم | اسأل عن الخطوة العالقة، واقترح تقسيم المهام الطويلة للفريق كله | | تساعده كثيراً ولا يتغير شيء | حدد وقت المساعدة، وبعد أسبوعين أو ثلاثة ارفع الأمر للمدير | | أثر على العملاء أو موعد مهم | أخبر قائد الفريق Team Lead بالخطر في وقته، ولا تحميه بليلة عمل صامتة | | تريد أن تخبر المدير | وقائع، أثر، ما فعلته، ما تطلبه، في الاجتماع الفردي One-on-One | | لا ترى تغييراً بعد أن أخبرت المدير | لا تسأل عن زميلك، واسأل عن دورك أنت | | تذاكر ليست مسؤوليتك تحول إليك | اطلب توزيع مسؤوليات Ownership مكتوباً، وأعد التذاكر حسبه | | اكتشفت أن عنده ظرفاً لم تعرفه | صحح ما قلته عنه عند نفس الشخص | | الزميل عدائي أو مسيء، وليس ضعيفاً فقط | هذا موقف آخر: راجع مقال الزميل الصعب وسجل الوقائع فيه | ومقالات هذه المسارات تكمل بعضها، فالزميل الصعب والشلل في العمل والنميمة وسرقة الجهد كلها مواقف قريبة من هذا الموقف ولكن بأدوات مختلفة: [![](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/workplace-cliques-cover-cover.webp)دليلالتكتلات داخل الشركة In-group Bias: كيف تتعامل معهاكيف تفرق بين الصداقة في العمل والتكتل الذي يوظف ويرقي من دائرته، وماذا يفعل من هو خارجها، وما يجب على المدير وما يقوله نظام العمل.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D9%83%D8%AA%D9%84%D8%A7%D8%AA-%D8%AF%D8%A7%D8%AE%D9%84-%D8%A7%D9%84%D8%B4%D8%B1%D9%83%D8%A9-in-group-bias-%D9%83%D9%8A%D9%81-%D8%AA%D8%AA%D8%B9%D8%A7%D9%85%D9%84-%D9%85%D8%B9%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/gossip-credit-stealing-cover-cover.webp)دليلالشائعات ونسبة جهدك لغيرك Credit Stealing: ماذا تفعل؟كيف ترد على كلام عنك في غيابك وعلى من يعرض عملك باسمه، بعبارات هادئة وأثر مكتوب يجعل عملك مرئياً دون أن تمدح نفسك.](https://arabroot.io/articles/%D8%A7%D9%84%D8%B4%D8%A7%D8%A6%D8%B9%D8%A7%D8%AA-%D9%88%D9%86%D8%B3%D8%A8%D8%A9-%D8%AC%D9%87%D8%AF%D9%83-%D9%84%D8%BA%D9%8A%D8%B1%D9%83-gossip-%D9%88-credit-stealing/)[![](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/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/burnout-developers-cover-cover.webp)دليلالاحتراق الوظيفي Burnout عند المبرمجين: العلامات والأسبابما تقوله منظمة الصحة العالمية عن الاحتراق الوظيفي، ومن أين يأتي في الفرق التقنية، وما يفعله المهندس لنفسه وقائد الفريق لفريقه.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D8%B1%D8%A7%D9%82-%D8%A7%D9%84%D9%88%D8%B8%D9%8A%D9%81%D9%8A-burnout-%D8%B9%D9%86%D8%AF-%D8%A7%D9%84%D9%85%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/manager-doesnt-understand-cover-cover.webp)دليلمديرك لا يفهم عملك التقني: كيف تشرح الأثر Business Impactكيف تترجم طلبك التقني إلى أثر يقرر به مديرك، وتتفاوض على التقديرات والدين التقني بخيارات واضحة بدل الصدام.](https://arabroot.io/articles/%D9%85%D8%AF%D9%8A%D8%B1%D9%83-%D9%84%D8%A7-%D9%8A%D9%81%D9%87%D9%85-%D8%B9%D9%85%D9%84%D9%83-%D8%A7%D9%84%D8%AA%D9%82%D9%86%D9%8A-%D9%83%D9%8A%D9%81-%D8%AA%D8%B4%D8%B1%D8%AD-%D8%A7%D9%84%D8%A7%D8%AB%D8%B1/)[![](https://arabroot.io/content/images/2026/10/manager-demotivates-cover-cover.webp)دليلمدير يحبطك: الإدارة الدقيقة Micromanagement والتجاهلكيف تتعامل مع مدير يراقب كل سطر أو يتجاهلك أو ينتقدك أمام الفريق، بعبارات تقولها ومذكرة أسبوعية تعيد لك قراراتك.](https://arabroot.io/articles/%D9%85%D8%AF%D9%8A%D8%B1-%D9%8A%D8%AD%D8%A8%D8%B7%D9%83-%D8%A7%D9%84%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%AF%D9%82%D9%8A%D9%82%D8%A9-micromanagement-%D9%88%D8%A7%D9%84%D8%AA%D8%AC%D8%A7%D9%87%D9%84/) ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - زميل واحد ضعيف الأداء يؤثر على الفريق كله لأن العمل مترابط، وأخطر علامة أن يبدأ الفريق في العمل من حوله بصمت، فتختفي المشكلة عن المدير ويحملها الآخرون. - قسم المسؤولية إلى ثلاث دوائر: عملك وكلامك ومراجعتك لك، ومعايير الفريق تقترحها، والتشخيص والتوقعات والقرارات للمدير وحده. - تحدث عن الوقائع وليس عن الشخص، لأنك لا ترى السياق كله، والوقائع تبقى صحيحة مهما كان السبب. - ساعد دون أن تحمل: اشرح ولا تكتب، وحدد وقت المساعدة، واجعله يقود في البرمجة الثنائية، وتوقف عن الإصلاح الصامت. - تحدث معه مباشرة أولاً، ثم ارفع الأمر للمدير إذا لم يتغير شيء أو كان الأثر كبيراً، بوقائع وأثر وما فعلته، دون أن تطلب عقوبة، واسأل بعدها عن دورك أنت لا عن زميلك. - احم عملك بملكية واضحة وتسليم مكتوب، ولا تتحدث عنه في المجموعات الجانبية، وإذا اتضح أنك كنت مخطئاً فصحح ما قلته. ## سجل التحديثات - أكتوبر 2026: كتابة المقال، والتحقق من صفحة GitLab عن ضعف الأداء، والفصل الخامس من كتاب Software Engineering at Google، وإرشادات Google لمراجعة الكود، وحلقة This American Life رقم 370 عن تجربة Will Felps، بتاريخ 31 أكتوبر 2026.