ضعف الأداء Underperformance: المهارة أم الرغبة أم البيئة؟

لنفرض أنك استلمت قبل شهر إدارة فريق الواجهة الخلفية Backend في شركة متوسطة تبني برمجيات لإدارة الشحن Logistics، وفيها حوالي ستين مهندساً، وترك لك المدير السابق قبل انتقاله ملاحظة قصيرة عن كل شخص في الفريق. وعن أحد المهندسين كتب سطراً واحداً: «أداؤه ضعيف، لا يلتزم بما يعد به في دورة العمل Sprint، والتعديلات التي يسلمها ترجع من فريق ضمان الجودة QA، أقترح البدء في خطة تحسين الأداء PIP». وعندما فتحت نظام التذاكر وجدت أن الملاحظة صحيحة في ظاهرها: المهندس انضم قبل ثمانية أشهر، ولم يكمل في آخر ثلاث دورات عمل أكثر من نصف ما التزم به، وتعديله الأخير على خدمة تتبع الشحنات رجع من الاختبار مرتين.

والطريق الأسهل أمامك أن تأخذ الملاحظة كما هي، فالمدير السابق يعرف الفريق أكثر منك، والأرقام تؤيده، والخطة الرسمية موجودة. ولكن قبل أن تفعل، هناك سؤال لم تجب عنه الملاحظة ولا الأرقام: لماذا؟ هل هذا مهندس لا يعرف كيف يفعل ما يطلب منه؟ أم يعرف ولا يريد؟ أم أن شيئاً في طريقة عمل الفريق نفسه، أو في حياته، أو في إدارته السابقة، يجعله يفشل مهما حاول؟ هذه الأسئلة الثلاثة هي ما نسميه في هذا المقال المهارة Skill والرغبة Will والبيئة Context، والإجابة عنها هي الفرق بين خطة تساعد الشخص فعلاً، وخطة تعاقبه على شيء ليس بيده.

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

وسوف نناقش في هذا المقال ما يلي:

• لماذا لا يكفي أن تعرف أن الأداء ضعيف، والخطآن اللذان يقع فيهما أغلب المديرين.
• الأسباب الثلاثة: البيئة والمهارة والرغبة، وكيف يقسمها دليل GitLab.
• نموذج Thomas Gilbert الذي يقول افحص البيئة قبل الشخص، وسؤال Mager وPipe عن المهارة.
• ترتيب الأسئلة قبل الحكم، والعلامات التي تضلل.
• محادثة التشخيص في الاجتماع الفردي One-on-One، وما يقوله الموظف من جهته.
• مصفوفة المهارة والرغبة Skill/Will Matrix، وماذا تفعل في كل خانة.
• ثلاث حالات: توقعات غير واضحة في شركة متوسطة، وفجوة مهارة في شركة ناشئة، وظرف شخصي في جهة حكومية.
• عندما تكون الرغبة هي السبب فعلاً، وعندما تكون أنت السبب.
• ورقة التشخيص وسكربت صغير يرتب الأسئلة، مع تشغيله على الحالات.

لماذا التشخيص قبل الحكم؟ (Why Diagnose First)

عندما يرى المدير أداءً ضعيفاً يقع غالباً في واحد من خطأين متعاكسين. الخطأ الأول أن يتجاهل المشكلة على أمل أن تتحسن وحدها، وهو ما يسميه كتاب Software Engineering at Google في فصله عن قيادة الفرق نمط «تجاهل ضعيفي الأداء» Ignore Low Performers، ويقول عنه إن الأمل ليس استراتيجية. والخطأ الثاني عكسه تماماً: أن يقفز من «الأداء ضعيف» إلى «الشخص ضعيف» مباشرة، فيبدأ إجراءً رسمياً أو يقرر في داخله أن هذا الشخص لا يصلح، دون أن يسأل لماذا. والخطأ الثاني أخطر في رأيي، لأنه يبدو كأنه حزم وشجاعة، وهو في الحقيقة اختصار للتفكير.

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

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

الأسباب الثلاثة: البيئة والمهارة والرغبة (Context, Skill, Will)

أغلب أدلة الإدارة تقسم أسباب الأداء الضعيف إلى قسمين. فـدليل GitLab عن ضعف الأداء Underperformance، وهو من أوضح الأدلة المنشورة للعامة، يقسمه إلى أداء ضعيف سببه المهارة Skill-based وأداء ضعيف سببه الرغبة Will-based. ويصف الأول بأنه شخص لديه الدافع للنجاح، ولكن ينقصه شيء من القدرة التقنية، أو المهارات الشخصية، أو القدرة على ترتيب الأولويات، أو فهم كيف ينجز المهام المطلوبة في دوره. ويصف الثاني بأنه شخص لديه المهارات اللازمة للنجاح، ولكن تنقصه الرغبة في الأداء، ويظهر ذلك في نقص الدافع والانخراط، أو في سلوك غير مهني مع زملائه، أو في سلوك يعطل نجاح غيره.

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

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

البيئة قبل الشخص: نموذج Gilbert (Behavior Engineering Model)

الفكرة القائلة إن تبدأ بالبيئة ليست جديدة. ففي عام 1978 نشر عالم النفس Thomas Gilbert كتابه Human Competence، ووضع فيه ما يسمى نموذج هندسة السلوك Behavior Engineering Model، وهو جدول من ست خانات يقسم أسباب الأداء إلى صفين: صف للبيئة وصف للشخص، وفي كل صف ثلاثة أعمدة: المعلومة Information، والوسائل Instrumentation، والدافع Motivation.

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

وأمثلة الصف الأعلى في الفرق التقنية كثيرة. فمن المعلومة: مهندس لا يعرف أن «مكتمل» في هذا الفريق يعني أن الاختبارات Tests مكتوبة والتوثيق محدث، لأن تعريف الإنجاز Definition of Done غير مكتوب في أي مكان. ومن الوسائل: مهندس ينتظر يومين كل أسبوع صلاحية على بيئة الاختبار Staging، أو يعمل على جهاز لا يستطيع تشغيل النظام كاملاً محلياً. ومن الدافع: مهندس لاحظ أن من ينهي مهامه بسرعة يأخذ مهام زملائه المتأخرين، فتعلم بهدوء ألا ينهي بسرعة. وفي كل هذه الأمثلة، إذا بدأت بسؤال الشخص عن مهارته أو رغبته فستصل إلى استنتاج خاطئ، وسيعرف هو أنه خاطئ، وسيفقد ثقته بك.

هل يستطيع لو اضطر؟ سؤال Mager and Pipe (Could They Do It)

وبعد البيئة يأتي سؤال المهارة، وأبسط طريقة لطرحه جاءت من كتاب Robert Mager وPeter Pipe بعنوان Analyzing Performance Problems الصادر عام 1970، وهو كتاب صغير في تحليل مشاكل الأداء. والسؤال الذي اشتهر منه: لو كانت حياته تعتمد على هذا العمل، هل يستطيع أن يفعله؟ والفكرة من السؤال أنه يفصل بين «لا يستطيع» و«لا يفعل». فإذا كان الجواب «لا، حتى لو اضطر لن يعرف كيف يكتب هذا الاستعلام Query بكفاءة»، فأنت أمام فجوة مهارة، والعلاج تعلم. وإذا كان الجواب «نعم، فعلها قبل ستة أشهر في مشروع آخر»، فالمهارة موجودة، والسبب في مكان آخر، في البيئة أو في الرغبة.

وفي العمل التقني تستطيع أن تجيب عن هذا السؤال بأدلة أكثر من أغلب المهن، لأن العمل مسجل. فارجع إلى سجل Git وطلبات الدمج Pull Requests القديمة وابحث هل أنجز مثل هذا العمل بنجاح من قبل، وانظر في المراجعات هل كانت الملاحظات عليه تقنية في الصميم، مثل أخطاء في التصميم والمنطق، أم ملاحظات عن أشياء نسيها مثل الاختبارات والتوثيق، فالأولى تشير إلى مهارة، والثانية تشير غالباً إلى توقع غير واضح أو عجلة. وانتبه أن مهارة الشخص ليست شيئاً واحداً، فقد يكون ممتازاً في كتابة الكود وضعيفاً في تقدير الوقت Estimation، أو قوياً في الواجهة الخلفية وجديداً على قواعد البيانات Databases، والتشخيص يكون لكل مهمة وليس للشخص كله.

ترتيب الأسئلة قبل الحكم (Diagnosis Order)

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

1. هل يعرف التوقع بالضبط؟ ليس «هل قلت له»، وإنما هل هو مكتوب، وهل أعاده بكلماته، وهل يعرف ماذا يعني «مكتمل» وبأي جودة ومتى. وهل يأتيه التوقع من مصدر واحد، أم من مدير ومدير منتج Product Manager وقائد فريق آخر في نفس الوقت.
2. هل عنده الوقت والأدوات؟ هل نصف أسبوعه في اجتماعات؟ هل يحمل المناوبة On-call وحده؟ هل ينتظر صلاحيات أو بيئات؟ هل المهام التي يأخذها أكبر من غيرها بشكل منهجي؟
3. هل تغير شيء قريباً؟ مدير جديد، فريق جديد، مشروع ألغي، ظرف شخصي. والتغير المفاجئ في أداء شخص كان جيداً يأتي في الغالب من هنا.
4. هل يستطيع لو اضطر؟ سؤال المهارة، بأدلة من عمله السابق.
5. هل سمع الفجوة ووافق على خطة ولم ينفذها؟ سؤال الرغبة، ولا يأتي إلا بعد أن تكون الأسئلة الأربعة قد أجيبت.

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

علامات تضلل (Misleading Signs)

بعض العلامات تبدو كأنها تشير إلى سبب، وهي في الحقيقة تشير إلى غيره، وهذه أشهرها في الفرق التقنية:

• الصمت يبدو كأنه رغبة ضعيفة: المهندس الذي لا يتكلم في الاجتماعات ولا يسأل قد يبدو غير مهتم، وكثيراً ما يكون جديداً يخاف أن يظهر أنه لا يعرف، أو يعمل بلغة ثانية لا يرتاح فيها، أو تعلم في فريق سابق أن السؤال له ثمن. وهذا ما رأيناه في مقال متلازمة المحتال Impostor Syndrome المنشور في هذا المسار.
• البطء يبدو كأنه مهارة ناقصة: المهندس الذي يأخذ ضعف الوقت قد يكون بطيئاً لأنه لا يعرف، أو لأنه يأخذ دائماً المهام الغامضة التي لا يريدها أحد، أو لأن المهام تتغير أثناء العمل عليها، أو لأنه الوحيد الذي يكتب اختبارات في فريق لا يكتبها.
• الأخطاء المتكررة تبدو كأنها إهمال: الأخطاء التي ترجع من الاختبار قد تأتي من عجلة، وقد تأتي من بيئة تطوير Development Environment مختلفة عن بيئة الاختبار، أو من متطلبات غامضة يفهمها كل شخص بطريقة.
• الاعتراض يبدو كأنه سلوك سيئ: المهندس الذي يعترض كثيراً على القرارات قد يكون صعباً، وقد يكون الوحيد الذي يرى مشكلة حقيقية، والفرق بينهما في طريقة الاعتراض وليس في وجوده.
• الأداء الممتاز السابق يخفي المشكلة: والعكس أيضاً، فالشخص الذي كان ممتازاً تعطيه وقتاً أطول قبل أن تسأل، مع أن التغير المفاجئ هو بالضبط ما يحتاج سؤالاً مبكراً.

محادثة التشخيص (Diagnostic Conversation)

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

وابدأ بالوقائع، لأنها الشيء الوحيد الذي لا يمكن الخلاف عليه، فتذكر ما حدث في آخر دورات العمل بالأرقام والتذاكر، دون أي تفسير. ثم اسأل عن البيئة، وأهم سؤال هنا «وش اللي تفهمه إنه المطلوب منك بالضبط؟»، لأن الفرق بين جوابه وبين ما في رأسك هو أول ما ستكتشفه. ثم اسأل عن العوائق، ثم عن الجزء الأصعب في العمل، ثم اترك باباً مفتوحاً لأي ظرف شخصي دون أن تطلب تفاصيل. وانتبه للصمت بعد كل سؤال، فلا تملأه بإجابة من عندك، لأن أهم ما يقال في هذه المحادثات يقال بعد ثوان من الصمت.

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

من جهة الموظف (The Employee's Side)

وإذا كنت أنت المهندس الذي يشعر أن أداءه لا يرضي مديره، أو تعرف أن شيئاً في حياتك يؤثر على عملك، فدليل GitLab يقول للموظف شيئاً واضحاً: أخبر مديرك فوراً إذا كانت هناك ظروف في حياتك تجعلك أقل فاعلية، ولا يلزمك أن تذكر التفاصيل إن لم ترد، ولكن قل له متى بدأت، وإلى أي حد تؤثر على عملك، ومتى تتوقع أن تتحسن. ويضيف أنك إذا أجلت هذه المحادثة حتى يكتشف مديرك ضعف الأداء بنفسه فقد خسرت ثقة كانت ستفيدك في هذه الفترة. وهذا صحيح في أي شركة، فالمدير الذي يعرف مبكراً يستطيع أن يرتب مرونة أو يعيد توزيع العمل، أما المدير الذي يكتشف بعد ثلاثة أشهر فيبدأ بسؤال «ليش ما قلت لي؟».

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

مصفوفة المهارة والرغبة (Skill/Will Matrix)

بعد أن تعرف السبب، يبقى سؤال كيف تتعامل مع الشخص في كل مهمة، وهنا تفيدك أداة معروفة في التدريب الإداري اسمها مصفوفة المهارة والرغبة Skill/Will Matrix، من كتاب Max Landsberg بعنوان The Tao of Coaching. والمصفوفة تضع المهارة على محور والرغبة على محور آخر، وتعطي لكل خانة من الأربع أسلوباً مختلفاً للمدير:

• رغبة عالية ومهارة منخفضة، أي وجهه Guide: مهندس متحمس وجديد على المهمة، يحتاج شرحاً وأمثلة وعملاً ثنائياً Pair Programming ومراجعة قريبة، ويحتاج أن ترى تقدمه وتقوله له، لأن حماسه هو ما سيوصله.
• رغبة عالية ومهارة عالية، أي فوضه Delegate: أعطه المسؤولية والقرار، وتابع النتائج وليس الخطوات، ولا تقم بإدارته بالتفاصيل Micromanagement لأنك ستخسر رغبته.
• رغبة منخفضة ومهارة منخفضة، أي وجهه بوضوح Direct: توقع مكتوب بخطوات صغيرة ومواعيد، ومتابعة أسبوعية، وفي نفس الوقت ابحث عن سبب انخفاض الرغبة، لأنه كثيراً ما يكون نتيجة لضعف المهارة نفسه، فمن يفشل كثيراً يفقد رغبته.
• رغبة منخفضة ومهارة عالية، أي حفزه Excite: وهذه أصعب خانة، لأن الشخص يستطيع ولا يفعل. اسأل ما الذي تغير، واربط العمل بما يهمه، وإذا لم ينجح ذلك فوضح له بصراحة ثمن الاستمرار، وهنا قد تصل إلى خطة تحسين الأداء.

ولاحظ شيئين في استخدام المصفوفة. الأول أنها لكل مهمة وليست للشخص، فنفس المهندس قد يكون في خانة التفويض في الواجهة الخلفية وفي خانة التوجيه في قاعدة البيانات. والثاني أن كتاب Software Engineering at Google يصف التعامل مع ضعيف الأداء بأنه يحتاج إدارة بالتفاصيل مؤقتة، مع كثير من التواضع والاحترام والثقة، ويقترح مدة محددة، مثل شهرين، وأهدافاً صغيرة قابلة للقياس تعطي فرصة لنجاحات كثيرة صغيرة، واجتماعاً أسبوعياً لمتابعة التقدم. وكلمة «مؤقتة» هنا هي المهم، فالإدارة بالتفاصيل أداة للخانة الحمراء لفترة، وليست أسلوباً دائماً.

الحالة الأولى: توقعات غير واضحة في شركة متوسطة (Unclear Expectations)

نعود إلى مهندس الواجهة الخلفية في شركة الشحن. في الاجتماع الفردي الأول بدأ المدير الجديد بالوقائع، ثم سأل: «وش اللي تفهمه إنه المطلوب منك بالضبط؟». وكان الجواب مفاجئاً: المهندس يأخذ مهامه من ثلاثة مصادر، من دورة العمل التي يخطط لها الفريق، ومن مدير منتج خدمة التتبع الذي يرسل له طلبات «صغيرة وعاجلة» مباشرة، ومن قائد فريق التكاملات Integrations الذي يحتاج تعديلات في نفس الخدمة لعميل كبير. وكان المهندس يعطي الأولوية لمن يتصل أخيراً، فتتأخر مهام دورة العمل، ويرى المدير السابق التأخير ولا يرى الطلبات الجانبية لأنها لا تمر بنظام التذاكر. وأما رجوع التعديلات من الاختبار، فاكتشف المدير أن الفريق ليس عنده تعريف مكتوب للإنجاز Definition of Done، وأن المهندس كان يظن أن كتابة اختبارات التكامل Integration Tests مسؤولية فريق ضمان الجودة. والمدير السابق لم يقل له أي شيء من ذلك، وإنما كتب ملاحظة لمن بعده.

ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse)

ما يحدث عادة في هذه الحالة أن يأخذ المدير الجديد الملاحظة كما هي ويبدأ خطة تحسين أداء، وهنا يصبح الوضع ظالماً بشكل واضح: الخطة تحاسب المهندس على التزامات دورة العمل، وهو ما زال يتلقى طلبات من مصدرين آخرين لا تعرفهما الخطة، فيفشل فيها، ويثبت الفشل الحكم الأول. وما يزيد الموقف سوءاً أن يعرف المهندس بالملاحظة من طرف ثالث قبل أن يسمعها من مديره، أو أن يطلب منه المدير أن «يقول لا» لمدير المنتج وقائد التكاملات، فيضعه في مواجهة مع أشخاص أعلى منه بدل أن يتولى المدير ذلك بنفسه.

ما الذي ينجح؟ (What Works)

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

ولكن بقي شيء واحد لم يتغير: التوثيق. فالتعديلات صارت تمر بالاختبار، ولكن ملفات التوثيق للتكاملات لم تحدث في ثلاث مرات متتالية، مع أنها مكتوبة في التعريف الجديد ومع أنه وافق عليها. وهنا فقط، بعد أن أزيلت أسباب البيئة وتأكد أن المهارة موجودة، وصل المدير إلى سؤال الرغبة، فسأله مباشرة عن التوثيق. وقال المهندس بصراحة إنه يرى التوثيق مضيعة للوقت لأن «محد يقرأه». فشرح له المدير أن فريق الدعم Support يستخدمه في كل مكالمة مع العملاء، وأن غيابه كلفهم في الشهر الماضي ثلاث تذاكر تصعيد Escalations، وقال بوضوح إن التوثيق جزء من العمل، وأنه سيتابعه كل أسبوع. وتغير السلوك في الأسبوع التالي، ولم يحتج المدير أي خطة رسمية. وبعد ستة أشهر كان هذا المهندس من أكثر من يعتمد عليهم الفريق في خدمة التتبع.

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

عبارات تقولها (What to Say)

«قرأت ملاحظات المدير السابق، بس أبغى أكون صريح معك: ما راح أعتمد عليها، أبغى أفهم بنفسي. وش اللي تفهمه إنه المطلوب منك بالضبط؟ ومن يعطيك الشغل؟»

«موضوع الطلبات اللي تجيك مباشرة من مدير المنتج وفريق التكاملات، هذا مو شغلك تحله، هذا شغلي أنا. أنا بأتكلم معهم هالأسبوع، ومن الآن أي طلب يجيك برا الحوادث حوله لي.»

«التوثيق صار مكتوب في تعريف الإنجاز، ووافقنا عليه سوا، وثلاث مرات ما تحدث. أبغى أفهم ليش، لأن فريق الدعم يعتمد عليه في كل مكالمة.»

الحالة الثانية: فجوة مهارة في شركة ناشئة (Skill Gap)

في شركة ناشئة تبني تطبيقاً لحجز ملاعب رياضية، وظف المؤسس التقني مهندسة بمسمى مهندس متوسط Mid-level بعد أن أنهت معسكراً تدريبياً Bootcamp مكثفاً، لأنها كانت ممتازة في المقابلة ولأن الشركة كانت تحتاج شخصاً بسرعة. وبعد ثلاثة أشهر كانت المهام تأخذ منها ضعف الوقت المقدر، وطلبات الدمج ترجع بملاحظات كثيرة عن تصميم الكود، وكانت لا تسأل في القناة أبداً، والمؤسس بدأ يقول للآخرين إنها «ما عندها جدية».

ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse)

ما يحدث عادة في الشركات الناشئة أن الوقت ضيق، فلا أحد يملك ساعات ليعلم أحداً، فيبقى الشخص يغرق وحده، ويقرأ الآخرون صمته وبطأه كقلة اهتمام. وما يزيد الموقف سوءاً أن تعطى مهاماً أكبر «لتثبت نفسها»، أو أن يعيد زميل كتابة عملها بصمت كل مرة بدل أن يشرح لها ما الخطأ، فلا تتعلم شيئاً، وتشعر في نفس الوقت أن عملها لا قيمة له.

ما الذي ينجح؟ (What Works)

عندما طبق المؤسس سؤال Mager وPipe، أي هل تستطيع أن تفعل هذا لو اضطرت، كان الجواب واضحاً من سجل Git: لم تكتب من قبل خدمة بهذا الحجم، ولم تعمل على قاعدة بيانات فيها أكثر من بضعة جداول، والملاحظات في المراجعات كانت عن التصميم والمنطق، وليس عن النسيان. والبيئة كانت سليمة، والتوقع واضح، والرغبة واضحة من ساعات عملها الطويلة. أي أن هذه فجوة مهارة، والمستوى الذي وظفت عليه كان خطأ في التوظيف وليس خطأ منها.

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

عبارات تقولها (What to Say)

«أبغى أكون واضح من البداية: أنا شايف إنك تشتغلين كثير، والمشكلة مو في الجهد. المشكلة إن المهام اللي أعطيناك أكبر من الخبرة اللي عندك الحين، وهذا غلطنا في التوظيف أكثر منه غلطك.»

«القاعدة من اليوم: إذا قعدتي نص ساعة على شي وما تقدمتي، اكتبي في القناة وش تحاولين تسوين ووش جربتي. هذا مو ضعف، هذا جزء من الشغل.»

الحالة الثالثة: ظرف شخصي في جهة حكومية (Personal Circumstances)

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

ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse)

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

ما الذي ينجح؟ (What Works)

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

ولاحظ حدود دور المدير هنا: هو ليس طبيباً ولا مستشاراً نفسياً، ودوره أن يسأل، وأن يرتب مرونة مؤقتة لها مدة واضحة، وأن يعرف الموظف بما تقدمه المؤسسة من إجازات أو برامج دعم، وأن يحافظ على سرية ما سمعه، فلا يقول للفريق أكثر من «رتبنا جدول مختلف لفترة». والمرونة لها مدة، لأن المرونة المفتوحة دون حدود تتحول مع الوقت إلى عبء على زملائه، وهذا ظلم لهم.

عبارات تقولها (What to Say)

«لاحظت إن في شي تغير في آخر شهرين، وأنت من أكثر الناس التزام في القسم من سنين، فأكيد في سبب. ما يلزم تقول التفاصيل، بس إذا في شي أقدر أساعد فيه، قل لي.»

«خلنا نرتب جدول مختلف لثلاثة أشهر، ونرجع نشوف الوضع بعدها. وبأكلم الموارد البشرية عن الإجازات المتاحة لك، وهذا الكلام يبقى بيني وبينك.»

عندما تكون الرغبة هي السبب فعلاً (When It Is Really Will)

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

والمحادثة هنا مختلفة عن محادثة التشخيص. فهي محادثة عن خيار، وليست عن مشكلة: «التوقع واضح، والأدوات موجودة، وأنت تقدر تسويه، وسويته قبل. اللي أشوفه إنك تختار ما تسويه، وأبغى أفهم ليش، وأبغاك تعرف إن الاستمرار بهالشكل له نتيجة». ثم توقع مكتوب بموعد، ومتابعة أسبوعية. وكثير من الناس يتغيرون في هذه اللحظة، لأنها أول مرة يسمعون فيها بوضوح أن الأمر جدي. ومن لا يتغير تنتقل معه إلى خطة تحسين الأداء PIP بالتنسيق مع الموارد البشرية، وهي موضوع مقال مستقل في هذه المرحلة. والسلوك السلبي نفسه، أي التذمر والرفض والسخرية، له مقال خاص عن مشكلة السلوك Attitude، لأنه يحتاج طريقة مختلفة في الحديث.

وعندما تكون أنت السبب؟ (When It Is the Manager)

في الحالة الأولى رأينا أن «الأداء الضعيف» كان في جزء كبير منه نتيجة لإدارة سابقة لم تكتب توقعات، ولم تحم مهندسها من أولويات متعارضة، ولم تقل له ملاحظة واحدة قبل أن تكتب عنه لمن بعدها. وهذا أكثر شيوعاً مما يحب المديرون أن يعترفوا به. ودليل GitLab يقول للمديرين بوضوح إن الفشل في معالجة مشاكل الأداء في وقتها ينعكس على أداء المدير نفسه، وله أثر سلبي على المدير والموظف وبقية الفريق.

لذلك اسأل نفسك هذه الأسئلة قبل أن تتحدث عن أداء أحد: هل قلت له بوضوح، بوقائع، أن هناك مشكلة؟ متى آخر مرة أعطيته ملاحظة محددة عن عمله، جيدة أو سيئة؟ هل التوقع مكتوب، أم في رأسي؟ هل أعطيته المهام الصعبة الغامضة لأنه «يتحمل»، ثم حاسبته على التأخر فيها؟ هل ألغيت الاجتماع الفردي معه أكثر مما عقدته؟ فإذا كانت إجابة أي سؤال منها محرجة، فالخطوة الأولى عندك قبل أن تكون عنده. وعلاقة الموظف بمديره كسبب للإحباط لها مقال منشور في هذا المسار عن المدير الذي يحبط فريقه.

التوثيق من اليوم الأول (Documentation)

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

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

أخطاء شائعة (Common Mistakes)

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

الأداة: ورقة التشخيص وسكربت صغير (Diagnosis Worksheet)

الأداة العملية في هذا المقال جزآن في مجلد lab/. الأول ورقة تشخيص في ملف lab/diagnosis-worksheet.md، تملؤها قبل الاجتماع الفردي وبعده، وفيها الأسئلة بالترتيب الذي رأيناه، مع عمود للدليل بجانب كل جواب. والثاني سكربت صغير في lab/diagnose.mjs يعمل بـ Node دون أي مكتبات، يقرأ نفس الأسئلة لأكثر من حالة من ملف cases.json، ويطبع أين تشير الإجابات، ومن أين تبدأ، وما الأسئلة التي ما زالت بلا جواب. والسكربت لا يحكم على أحد، وإنما يجبرك على الترتيب، ويذكرك بما لم تعرفه بعد.

والأسئلة في السكربت مقسمة على الأسباب الثلاثة، ولكل سؤال الجواب الذي يشير إلى مشكلة:

const Q = {
  expectations_written: ['context', 'التوقع مكتوب وواضح (ماذا، بأي جودة، متى)', 'no'],
  single_priority: ['context', 'عنده مصدر واحد للأولويات', 'no'],
  recent_change: ['context', 'تغير شيء في حياته أو عمله قريباً', 'yes'],
  knows_gap: ['context', 'سمع بوضوح من مديره أن هناك فجوة، بوقائع', 'no'],
  could_if_had_to: ['skill', 'يستطيع أن يفعله لو كان ضرورياً جداً', 'no'],
  agreed_plan: ['will', 'وافق على خطة محددة لسدها', 'no'],
  followed_plan: ['will', 'نفذ ما اتفق عليه بعد ذلك', 'no'],
  // ... 12 سؤالاً في الملف الكامل
};

شغلت السكربت على ثلاث حالات من هذا المقال: مهندس الواجهة الخلفية قبل المحادثة الأولى، ومهندسة الشركة الناشئة، ونفس مهندس الواجهة الخلفية بعد ثلاثة أشهر من التوقع المكتوب، وكانت النتيجة:

$ node diagnose.mjs cases.json

== مهندس الواجهة الخلفية بعد ثمانية أشهر (قبل المحادثة)
  البيئة Context ####... 4/7
  المهارة Skill  ....... 0/3
  الرغبة Will    لا يقاس قبل أن يسمع الفجوة
  لا تحكم قبل أن تعرف: تغير شيء في حياته أو عمله قريباً، يطلب المساعدة عندما يتعثر
  ابدأ من البيئة Context: أصلح البيئة أولاً: توقع مكتوب، أولوية واحدة، وقت وأدوات، دور مناسب، أو مرونة لظرف مؤقت

== مهندسة وظفت كمستوى متوسط Mid-level بعد معسكر تدريبي Bootcamp
  البيئة Context ....... 0/7
  المهارة Skill  ###.... 3/3
  الرغبة Will    ....... 0/2
  ابدأ من المهارة Skill: خطة تعلم: تدريب، عمل ثنائي Pair Programming، مهام أصغر، ومراجعة أسبوعية

== نفس مهندس الواجهة الخلفية بعد ثلاثة أشهر من التوقع المكتوب
  البيئة Context ....... 0/7
  المهارة Skill  ....... 0/3
  الرغبة Will    #...... 1/2
  ابدأ من الرغبة Will: محادثة صريحة عن الفجوة والخيار، ثم توقع مكتوب بموعد، وقد تصل إلى خطة تحسين الأداء PIP

في المخرج أعلاه لاحظ التالي:

• في الحالة الأولى أربعة من سبعة أسئلة البيئة تشير لمشكلة: التوقع غير مكتوب، ولم يعده بكلماته، والأولويات من أكثر من مصدر، ولم يسمع الفجوة من مديره. لذلك يقول السكربت ابدأ من البيئة، وهذا ما فعله المدير في الحالة الأولى.
• سطر «الرغبة Will لا يقاس قبل أن يسمع الفجوة» يعني أن السكربت تجاهل أسئلة الرغبة في هذه الحالة، لأن الموظف لم يسمع بعد أن هناك مشكلة، فلا معنى لسؤال هل نفذ خطة لم تعرض عليه.
• سطر «لا تحكم قبل أن تعرف» يعدد الأسئلة التي أجبت عنها بـ unknown، وهي هنا الظرف الشخصي وطلب المساعدة، وهما بالضبط ما تسأل عنه في الاجتماع الفردي.
• في الحالة الثانية البيئة سليمة تماماً 0/7، وأسئلة المهارة الثلاثة كلها تشير لفجوة 3/3، والرغبة سليمة، فالبداية خطة تعلم، وهذا تشخيص الشركة الناشئة.
• في الحالة الثالثة كل شيء سليم إلا أنه وافق على الخطة ولم ينفذها، أي موضوع التوثيق، فيصل السكربت إلى الرغبة لأول مرة، بعد أن أزيلت أسباب البيئة.

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

// A plan he never heard about says nothing about his will: will questions count only after the gap was stated.
if (root === 'will' && c.answers.knows_gap !== 'yes') continue;

ماذا لو أضفنا للحالة الثالثة ظرفاً شخصياً بدأ قبل شهر، أي غيرنا جواب recent_change فقط إلى yes؟ أضفت هذه الحالة إلى الملف وشغلته مرة أخرى:

== ماذا لو: نفس الحالة الثالثة مع ظرف عائلي بدأ قبل شهر
  البيئة Context #...... 1/7
  المهارة Skill  ....... 0/3
  الرغبة Will    #...... 1/2
  ابدأ من البيئة Context: أصلح البيئة أولاً: توقع مكتوب، أولوية واحدة، وقت وأدوات، دور مناسب، أو مرونة لظرف مؤقت

ولاحظ أن الرغبة ما زالت 1 من 2، أي أنه لم ينفذ ما اتفق عليه، ولكن السكربت لم يبدأ منها، وإنما من البيئة، لأن الترتيب في الكود يفحص البيئة أولاً. وهذا هو الدرس نفسه من الحالة الحكومية: عدم التنفيذ في وقت ظرف عائلي لا تقرؤه كرغبة ضعيفة قبل أن تسأل عن الظرف وتعطي مرونة لمدة محددة.

قائمة تحقق (Checklist)

ومقالات المسار المنشورة التالية متصلة بهذا الموضوع، من تقييم المطورين نفسه إلى الملاحظات الصعبة والتقييم الظالم من جهة الموظف:

دليلكيف تقيم أداء المطورين Developer Performance دون قياس الأشياء الخطأ؟ماذا تقيس في أداء المطور والفريق، ولماذا تضلل أرقام مثل عدد الأسطر وطلبات الدمج، وكيف تقلل تحيز من يقيم.دليلدورة تقييم الأداء Performance Review Cycle: متى وكيف تقيم؟كيف ترتب تقييم فريقك على مدار السنة، من اجتماع 1:1 والأهداف إلى المعايرة وخطة تحسين الأداء، مع قوالب جاهزة.دليلكيف تعطي الملاحظات الصعبة Feedback وتتلقاهالماذا يخفض بعض الملاحظات الأداء بدلاً من أن يرفعه، وكيف تقول الملاحظة الصعبة بوضوح واهتمام وتتلقاها دون أن تدافع.دليلتقييم أداء تراه ظالماً Performance Review: كيف تعترض؟ماذا تفعل في الأيام الأولى بعد تقييم لا يعكس سنتك، وكيف تعترض بالأدلة دون أن تخسر علاقتك بمديرك، ومتى يكون التقييم عادلاً.دليلمدير يحبطك: الإدارة الدقيقة Micromanagement والتجاهلكيف تتعامل مع مدير يراقب كل سطر أو يتجاهلك أو ينتقدك أمام الفريق، بعبارات تقولها ومذكرة أسبوعية تعيد لك قراراتك.دليلمتلازمة المحتال Impostor Syndrome: أنواعها عند المهندسينلماذا يشعر مهندسون ناجحون بأنهم خدعوا من حولهم، وما تقوله الأبحاث عن هذا الشعور، وكيف تفرق بينه وبين فجوة حقيقية في المهارة.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• معرفة أن الأداء ضعيف لا تكفي، لأن العلاج يختلف تماماً حسب السبب، وتجاهل المشكلة والقفز إلى الحكم خطآن متعاكسان.
• الأسباب ثلاثة: البيئة Context والمهارة Skill والرغبة Will، ودليل GitLab يقسمها إلى Skill-based وWill-based، والبيئة نفحصها قبلهما.
• نموذج Gilbert يقول ابدأ بالبيئة لأنها الأرخص علاجاً، وسؤال Mager وPipe «هل يستطيع لو اضطر؟» يفصل بين لا يستطيع ولا يفعل.
• الرغبة آخر سؤال وليست أوله، ولا تحكم عليها قبل أن يسمع الشخص الفجوة بوقائع ويوافق على خطة.
• محادثة التشخيص في الاجتماع الفردي أسئلة مفتوحة تبدأ بالوقائع وتنتهي بملخص مكتوب فيه ما سيفعله الطرفان.
• مصفوفة المهارة والرغبة تحدد أسلوبك مع كل مهمة: توجيه، أو تفويض، أو توجيه واضح، أو تحفيز.
• الحالات الثلاث تحسنت لأن التشخيص كان صحيحاً: أولويات متعارضة صنعها مدير سابق، ومستوى توظيف خاطئ، وظرف عائلي احتاج مرونة لثلاثة أشهر.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، والتحقق من دليل GitLab عن ضعف الأداء (آخر تحديث له في 4 سبتمبر 2025)، والفصل الخامس من كتاب Software Engineering at Google، وكتابة سكربت التشخيص وتشغيله بـ Node على أربع حالات، بتاريخ 31 أكتوبر 2026.