جودة عمل ضعيفة Poor Quality: أخطاء تتكرر وكود يعاد كتابته

قائدة فريق Team Lead في شركة تقنية متوسطة الحجم تبني منصة لتوصيل طلبات المطاعم، تفتح صباح الأحد قائمة الأعطال Incidents من الأسبوع الماضي فتجد ثلاثة أعطال في خدمة الطلبات، وكلها جاءت من تغييرات كتبها نفس المهندس، وهو مهندس انضم قبل خمسة أشهر بخبرة ثلاث سنوات، ويعمل ساعات طويلة، ويرد على الرسائل بسرعة، ولكن طلبات الدمج Pull Requests التي يرسلها تعود إليه في كل مرة بعشرين ملاحظة، وأحد زملائه صار يعيد كتابة أجزاء من كوده بصمت قبل الإصدار Release حتى لا يتأخر الفريق. وفي اجتماع التخطيط الأخير اقترح أحد المهندسين، بنصف مزاح، أن «تمر مهامه على شخص ثاني قبل المراجعة»، وضحك الجميع، وهو أيضاً ضحك.

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

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

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

ما معنى جودة ضعيفة باستمرار؟ (Persistent Poor Quality)

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

والعلامات التي يمكن أن تراها وتقيسها، بدلاً من الانطباع العام، هي:

• جولات المراجعة Review Rounds: طلبات الدمج تحتاج أربع أو خمس جولات قبل الموافقة، بينما يحتاج زملاؤه جولة أو اثنتين في مهام مشابهة.
• الخلل الذي يهرب Escaped Defects: أخطاء لا يلتقطها هو ولا المراجعة، فتظهر في مرحلة الاختبار QA أو في الإنتاج.
• التراجع Revert: تغييرات تسحب بعد نشرها لأنها أوقفت شيئاً آخر.
• إعادة العمل Rework: زملاء يعيدون كتابة أجزاء من كوده، أحياناً بطلب من المدير، وأحياناً بصمت.
• الالتفاف حوله Working Around: الفريق يتوقف عن إعطائه المهام الحساسة، أو يضيف مراجعاً ثانياً لكل ما يكتبه دون أن يقال له.

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

من يدفع ثمن الجودة الضعيفة؟ (Cost of Poor Quality)

المدير الذي يرى الأعطال في لوحة القياس Dashboard يرى جزءاً صغيراً من الثمن فقط. فالجزء الأكبر يذهب في أماكن لا يقيسها أحد: ساعات المراجعة التي يقضيها المهندس الأول Senior Engineer في كتابة الملاحظات نفسها مرة بعد مرة، والزميل الذي يعيد كتابة الجزء الصعب ليلة الإصدار، والمناوب On-call الذي يستيقظ في الثالثة فجراً بسبب تغيير كان يمكن أن تلتقطه الاختبارات Tests، والعميل الذي وصله الطلب الخطأ.

وهناك ثمن ثالث أقل وضوحاً، وهو المعيار نفسه. فإذا رأى الفريق أن طلبات الدمج الضعيفة تمر بعد جولات كثيرة دون أن يتحدث أحد مع صاحبها، فسوف يفهم أن المعيار المكتوب، إن وجد، ليس مهماً، وأن من يكتب عملاً جيداً يدفع ضريبة من يكتب عملاً ضعيفاً. والأبحاث عن أثر عضو واحد سلبي في المجموعة، وأشهرها مراجعة Felps وMitchell وByington عام 2006، وصفت ثلاثة أنواع من السلوك تضر المجموعة، أحدها حجب الجهد Withholding Effort، وأن أثرها ينتقل لسلوك الآخرين، وموضوع الأثر على الفريق مفصل في مقال التفاحة الفاسدة Bad Apple في هذه المرحلة. ولاحظ هنا أن الجودة الضعيفة ليست بالضرورة حجباً للجهد، فالمهندس في قصتنا يعمل ساعات أطول من الجميع، وهذا بالتحديد ما يجعل التشخيص مهماً.

والثمن الأخير يدفعه المهندس نفسه، وهو الأقسى. فعندما يتأخر المدير في الكلام، يسمع المهندس عن المشكلة أول مرة في تقييم الأداء Performance Review في آخر السنة، وقد صار الحكم جاهزاً والفرصة ضاعت. ويصف كتاب Software Engineering at Google في فصل قيادة الفريق تجاهل ضعيف الأداء بأنه من الأنماط السيئة Antipatterns عند القادة، ويذكر شعار فريق SRE عندهم: «الأمل ليس استراتيجية Hope is not a strategy»، ويقول إن أكثر مكان يستخدم فيه الأمل كاستراتيجية هو التعامل مع ضعيف الأداء، فالقائد يتمنى أن يتحسن وحده أو أن يغادر وحده. ويضيف الكتاب ملاحظة مهمة: إذا تعاملت مع المشكلة مبكراً فقد تجد أن الشخص يحتاج فقط توجيهاً أو تشجيعاً، وإذا انتظرت طويلاً فسوف تكون العلاقة بينه وبين الفريق قد ساءت لدرجة لا تستطيع معها مساعدته.

قبل الحكم: هل المعيار مكتوب أصلاً؟ (Quality Bar)

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

والمعيار المكتوب، أو تعريف الإنجاز Definition of Done كما تسميه فرق كثيرة، لا يحتاج أن يكون طويلاً. خمسة أو ستة بنود تكفي: حجم طلب الدمج، وما يجب أن يحتويه وصفه، وأي اختبارات مطلوبة، وأن يكون خط النشر CI/CD Pipeline أخضر قبل طلب المراجعة، وخطة تراجع Rollback لأي تغيير يمس قاعدة البيانات أو واجهة خارجية API. وحجم طلب الدمج بالذات له أثر كبير على الجودة، وتقول إرشادات Google لطلبات التغيير الصغيرة إن التغيير الصغير يراجع أسرع وبعمق أكبر وأقل احتمالاً أن يدخل أخطاء، وإن 100 سطر غالباً حجم معقول، و1000 سطر غالباً كبير جداً، مع ترك التقدير للمراجع.

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

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

لماذا تتكرر الأخطاء؟ (Skill, Will, Context)

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

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

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

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

اقرأ النمط، لا الحادثة (Defect Patterns)

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

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

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

الحالة الأولى: مهندس يعمل كثيراً ويخطئ كثيراً (Mid-size Company)

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

ماذا يحدث عادة؟ (What Usually Happens)

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

ما الذي يزيده سوءاً؟ (What Makes It Worse)

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

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

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

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

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

بداية المحادثة في الاجتماع الفردي:

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

عندما تعرض النمط:

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

عند الاتفاق:

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

وبعد التحسن، لا تكتف بعبارة عامة:

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

الحالة الثانية: شركة ناشئة تكافئ السرعة (Startup Speed Culture)

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

ماذا يحدث عادة؟ (What Usually Happens)

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

ما الذي يزيده سوءاً؟ (What Makes It Worse)

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

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

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

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

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

المؤسس للفريق كله:

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

للمهندس الذي لم يلتزم بعد الاتفاق:

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

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

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

ماذا يحدث عادة؟ (What Usually Happens)

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

ما الذي يزيده سوءاً؟ (What Makes It Worse)

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

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

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

وبعد شهرين خرج والدها من المستشفى، وعادت جودة عملها لما كانت عليه، والمهم أن الثقة بينها وبين مديرها خرجت أقوى، لأنها رأت كيف تصرف في أصعب وقت.

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

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

وإذا أخبرتك بظرف:

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

المحادثة الأولى عن الجودة (The Quality Conversation)

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

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

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

خطة تحسين قصيرة قبل أي إجراء رسمي (Coaching Plan)

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

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

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

المراجعة دون أن تتحول لمحاكمة (Code Review)

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

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

وإذا كانت الأدوات الآلية، مثل أدوات فحص جودة الكود Static Analysis والمراجعة بمساعدة الذكاء الاصطناعي AI Code Review، يمكن أن تلتقط جزءاً من الأخطاء المتكررة قبل أن يراها إنسان، فاستخدمها للفريق كله، لأنها تجعل الملاحظة تأتي من أداة محايدة بدل أن تأتي كل مرة من نفس الزميل. وهذه الأدوات مشروحة في مقالات جودة الكود في الموقع.

إذا كنت أنت المهندس (The Engineer's Side)

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

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

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

متى يصبح الأمر خطة رسمية؟ (When to Escalate)

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

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

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

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

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

الأداة: سجل الأنماط وخطة التحسين (Defect Log and Plan)

الأداة في هذا المقال جزءان في مجلد lab/. الأول قالب في ملف lab/quality-plan-template.md فيه معيار الجودة المكتوب، وجدول سجل الأنماط، وأسئلة التشخيص قبل المحادثة، ونص المحادثة الأولى، وخطة ستة أسابيع. والثاني سكربت Node صغير في ملف lab/defect-patterns.mjs لا يحتاج أي مكتبة، يقرأ سجل طلبات الدمج بصيغة CSV ويطبع أين يتركز الخلل. وفي المجلد ملف lab/prs-sample.csv فيه بيانات مثال لـ 24 طلب دمج لمهندس واحد خلال ثمانية أسابيع، وهي بيانات كتبناها لتوضيح الطريقة وليست من فريق حقيقي. والسجل بهذا الشكل:

week,pr,lines,rounds,defect,found,reverted
1,101,640,4,requirements,production,yes
1,102,90,1,none,none,no
1,103,820,5,edge-case,qa,no
2,104,410,3,requirements,qa,no

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

node defect-patterns.mjs prs-sample.csv

تكون النتيجة:

PRs: 24, with a defect: 12 (50%), reverted: 3

By defect type:
  requirements    5  42%
  edge-case       4  33%
  tests-missing   2  17%
  integration     1  8%

By where it was found:
  review          5
  qa              4
  production      3

By PR size (lines changed):
  < 250          PRs 17  defect rate  29%  avg rounds 1.5
  250-499        PRs  2  defect rate 100%  avg rounds 3.0
  >= 500         PRs  5  defect rate 100%  avg rounds 4.4

By period (weeks):
  weeks 1-4      PRs 12  defect rate  75%  production 3  avg lines 407
  weeks 5-8      PRs 12  defect rate  25%  production 0  avg lines 171

ولنقرأ النتيجة جزءاً جزءاً:

• السطر الأول: نصف طلبات الدمج فيها خلل، وثلاثة سحبت بعد النشر. هذا الرقم وحده يقول إن هناك مشكلة، ولكنه لا يقول ما هي، ولو توقفت عنده لكانت المحادثة «نصف شغلك فيه أخطاء» دون أي اتجاه.
• حسب نوع الخلل: 42% من الأخطاء فهم خاطئ للمتطلبات. هذا أول سؤال للمدير عن التذاكر، قبل أي سؤال للمهندس، و33% حالات حدية، وهذه مهارة في الاختبار يمكن تعليمها.
• حسب مكان الظهور: خمسة أخطاء التقطتها المراجعة، وهذا جيد ومتوقع، وأربعة وصلت للاختبار، وثلاثة وصلت للإنتاج، وهذه الثلاثة هي التي تهم العميل وتستحق أن تذكر بالتحديد في المحادثة.
• حسب حجم التغيير: هنا أوضح نمط في البيانات. الطلبات التي أقل من 250 سطراً فيها خلل في 29% منها، ومتوسط جولات مراجعتها 1.5، أما كل الطلبات التي تجاوزت 250 سطراً ففيها خلل، ومتوسط جولاتها يصل إلى 4.4. وهذا يتفق مع ما تقوله إرشادات Google عن التغييرات الصغيرة، ويجعل أول هدف في الخطة واضحاً: تقسيم العمل.
• حسب الفترة: في الأسابيع الأربعة الأولى، قبل الخطة، كان الخلل في 75% من الطلبات وثلاثة وصلت للإنتاج، ومتوسط حجم الطلب 407 أسطر. وفي الأسابيع الأربعة التالية، مع الخطة، انخفض الخلل إلى 25% ولم يصل شيء للإنتاج، وانخفض متوسط الحجم إلى 171 سطراً. وهذا الجزء هو ما تعرضه في لقاء نهاية الخطة.

والمشكلة العملية التي تظهر عادة مع هذا السجل أن يكتب كل شخص نوع الخلل بكلماته، مرة requirements ومرة req ومرة spec، فيعدها السكربت أنواعاً مختلفة. ولترى أثر ذلك، في المجلد ملف lab/prs-messy.csv هو نفس بيانات المثال بعد أن غيرنا اسم النوع في سطرين فقط، وعندما نشغل السكربت عليه:

node defect-patterns.mjs prs-messy.csv

PRs: 24, with a defect: 12 (50%), reverted: 3

By defect type:
  edge-case       4  33%
  requirements    3  25%
  tests-missing   2  17%
  req             1  8%
  integration     1  8%
  spec            1  8%

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

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

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

ومقالات الموقع التالية تكمل هذا الموضوع، من صياغة الملاحظة الصعبة، إلى جودة الكود وأدواتها، إلى تقييم الأداء:

دليلكيف تعطي الملاحظات الصعبة Feedback وتتلقاهالماذا يخفض بعض الملاحظات الأداء بدلاً من أن يرفعه، وكيف تقول الملاحظة الصعبة بوضوح واهتمام وتتلقاها دون أن تدافع.دليلما هي جودة الكود Code Quality وكيف تقيسها؟ما الذي يجعل الكود سهل التغيير، وماذا تقيس أدوات الفحص فعلاً، ولماذا يحتاج كود الوكلاء الأذكياء إلى بوابة جودة.دليلمراجعة كود الذكاء الاصطناعي دون أن تصبح شكليةكيف تراجع طلبات الدمج التي يكتبها الذكاء الاصطناعي بحسب خطرها، وتترك للبوابات الآلية ما تستطيع قياسه.دليلأنواع الاختبارات للمبتدئين: من Unit إلى E2E مع Playwrightما الذي يكشفه كل نوع من الاختبارات وما الذي يفوته، وكم اختباراً تكتب من كل نوع، وأين يعمل كل منها في خط CI.دليلكيف تقيم أداء المطورين Developer Performance دون قياس الأشياء الخطأ؟ماذا تقيس في أداء المطور والفريق، ولماذا تضلل أرقام مثل عدد الأسطر وطلبات الدمج، وكيف تقلل تحيز من يقيم.دليلتقييم أداء تراه ظالماً Performance Review: كيف تعترض؟ماذا تفعل في الأيام الأولى بعد تقييم لا يعكس سنتك، وكيف تعترض بالأدلة دون أن تخسر علاقتك بمديرك، ومتى يكون التقييم عادلاً.دليلاللوم بعد العطل Blame: حين يلومك الفريق على ما لم تسببهماذا تقول في الساعة الأولى بعد عطل نسب إليك، وكيف توثق الحقائق بخط زمني، ومتى تصعد اللوم المتكرر ومتى تغادر.دليلالاحتراق الوظيفي Burnout عند المبرمجين: العلامات والأسبابما تقوله منظمة الصحة العالمية عن الاحتراق الوظيفي، ومن أين يأتي في الفرق التقنية، وما يفعله المهندس لنفسه وقائد الفريق لفريقه.

الخلاصة

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

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

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

• أكتوبر 2026: كتابة المقال، والتحقق من فصلي قيادة الفريق ومراجعة الكود في كتاب Software Engineering at Google، وإرشادات Google لمعيار المراجعة وطلبات التغيير الصغيرة، ودليل GitLab عن ضعف الأداء، وفصل ثقافة المراجعة بعد الحوادث في كتاب Google SRE، ومراجعة Felps وزملائه لعام 2006، وتشغيل سكربت الأداة على بيانات المثال، بتاريخ 31 أكتوبر 2026.