> ## 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.

# كيف تقيم أداء المطورين دون أن تقيس الأشياء الخطأ؟
- URL: https://arabroot.io/articles/كيف-تقيم-اداء-المطورين-دون-قياس-الاشياء-الخطا/
- Published: 2026-10-14T15:30:00.000Z
- Updated: 2026-10-15T16:28:19.000Z
- Description: ماذا تقيس في أداء المطور والفريق، ولماذا تضلل أرقام مثل عدد الأسطر وطلبات الدمج، وكيف تقلل تحيز من يقيم.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, الفرق والمنتج, استراتيجية تقنية

في قصة [Kent Beck في Facebook](https://arabroot.io/articles/%D9%82%D8%B5%D8%A9-kent-beck-%D9%81%D9%8A-facebook/#fired) وصف صاحب TDD مهندساً يقترب من نهاية دورة تقييم مدتها ستة أشهر، ويحتاج إلى «win» يكتبه في مراجعته، فيطلق تجربة ترفع عدد الرسائل 0.2% دون أن ينظر إلى أضرارها، والسبب كما قال Beck أن أحداً لن يتخذ قراراً جيداً يجعل تقييمه هو أصعب. وهذه هي المشكلة التي يبدأ منها كل من يسأل «كيف أقيم أداء فريقي؟»، فطريقة التقييم ليست أداة محايدة تقرأ الأداء، وإنما هي حافز يغير ما يفعله الناس، فإذا قست الشيء الخطأ فسوف يتحسن الشيء الخطأ، وقد لخصنا ما يتعلمه المدير من القصة في فقرة [دروس المهندسين والمديرين](https://arabroot.io/articles/%D9%82%D8%B5%D8%A9-kent-beck-%D9%81%D9%8A-facebook/#lessons).

وهذه سلسلة من ثلاثة مقالات تجيب عن السؤال كاملاً: ماذا تقيس، ثم متى وكيف تقيم، ثم بأي أداة.

المواضيع في السلسلة:

- كيف تقيم أداء المطورين دون أن تقيس الأشياء الخطأ؟ (الموضوع الحالي)
- [دورة تقييم أداء الفريق التقني: متى وكيف تقيم؟](https://arabroot.io/articles/%D8%AF%D9%88%D8%B1%D8%A9-%D8%AA%D9%82%D9%8A%D9%8A%D9%85-%D8%A7%D8%AF%D8%A7%D8%A1-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82-%D8%A7%D9%84%D8%AA%D9%82%D9%86%D9%8A-%D9%85%D8%AA%D9%89-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%8A%D9%85/)
- [أدوات تقييم الأداء ومقاييس فرق التطوير](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%AA%D9%82%D9%8A%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D8%AF%D8%A7%D8%A1-%D9%88%D9%85%D9%82%D8%A7%D9%8A%D9%8A%D8%B3-%D9%81%D8%B1%D9%82-%D8%A7%D9%84%D8%AA%D8%B7%D9%88%D9%8A%D8%B1/)

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

- الفرق بين النشاط والمخرجات والنتائج والأثر، وأيها تقيم.
- لماذا تضلل أرقام مثل عدد الأسطر وال commits ونقاط القصة.
- ماذا تقيس على مستوى الفرد والفريق والمؤسسة.
- مقاييس الفريق: DORA وإطار SPACE وتجربة المطور DevEx.
- مصفوفة الكفاءات Competency Matrix والسلالم الوظيفية المنشورة.
- ما الذي يغيره الذكاء الاصطناعي في التقييم.
- تحيز من يقيم وكيف تقلله.

## ماذا تقيم بالضبط؟

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

![أربع مراحل من اليمين إلى اليسار: النشاط Activity مثل commits وطلبات الدمج، ثم المخرجات Output مثل الميزات المنشورة، ثم النتائج Outcome مثل مهمة تكتمل أسرع وأخطاء أقل، ثم الأثر Impact مثل عملاء يبقون وإيراد، ومعها أن النشاط سهل العد وسهل التلاعب والأثر أقرب إلى القيمة وأصعب في النسبة لشخص](https://arabroot.io/content/images/2026/10/dev-evaluation-02-chain.webp)

كلما اقتربت من القيمة صعب أن تنسب الرقم إلى شخص واحد

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

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

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

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

### قيم القرار مع النتيجة

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

- إيقاف إطلاق ميزة بعد أن ظهرت لها أضرار، حتى لو كانت ترفع الرقم المستهدف.
- التراجع Rollback السريع عن نشر سيئ بدلاً من محاولة إصلاحه في الإنتاج.
- تقسيم تغيير خطير إلى خطوات صغيرة خلف مفتاح ميزة Feature Flag، كما في [الإطلاق التدريجي](https://arabroot.io/articles/%D9%85%D9%81%D9%87%D9%88%D9%85-feature-flags-%D9%88%D8%A7%D9%84%D8%A7%D8%B7%D9%84%D8%A7%D9%82-%D8%A7%D9%84%D8%AA%D8%AF%D8%B1%D9%8A%D8%AC%D9%8A-gradual-rollout/).
- تقليل خطر أمني أو تشغيلي قبل أن يتحول إلى حادثة.
- العمل غير المرئي Invisible Work مثل توجيه زميل جديد وكتابة التوثيق ومراجعة الكود بعناية.

## لماذا تضلل أرقام النشاط؟

كل رقم من أرقام النشاط يرتفع بقرار من الشخص نفسه دون أن يتغير شيء للمستخدم، وهذه فكرة تعرف بقانون Goodhart، وتذكرها صفحة [مقاييس DORA](https://dora.dev/guides/dora-metrics/?ref=arabroot.io) أول خطأ في استخدام المقاييس: إذا جعلت المقياس هدفاً فسوف يحاول الفريق التلاعب به. والجدول التالي يلخص أشهر هذه الأرقام:

| الرقم                                    | كيف يرتفع دون قيمة                                                                                                                                                                       | ما يفيد فيه فعلاً                           |
| ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
| عدد الأسطر Lines of Code                 | كود مكرر، أو كود يولده الذكاء الاصطناعي دون حاجة، والحذف الجيد يظهر كرقم سالب                                                                                                            | لا شيء تقريباً في التقييم                   |
| عدد ال commits                           | تقسيم التغيير الواحد إلى commits كثيرة                                                                                                                                                   | معرفة هل يدمج الفريق تغييرات صغيرة باستمرار |
| نقاط القصة Story Points والسرعة Velocity | تضخيم التقدير، كما شرحنا في [السرعة كمقياس أداء](https://arabroot.io/articles/agile-%D9%88-scrum-%D9%88-kanban-%D8%A8%D9%84%D8%A7-%D8%B4%D8%B9%D8%A7%D8%B1%D8%A7%D8%AA/#velocity-as-kpi) | تخطيط الفريق لنفسه فقط                      |
| عدد طلبات الدمج Pull Requests            | تقسيم الميزة إلى طلبات صغيرة جداً، وسوف نرى ذلك بالأرقام في المختبر                                                                                                                      | تشخيص حجم الدفعات وزمن المراجعة للفريق      |
| عدد التذاكر المغلقة                      | اختيار التذاكر السهلة وترك الصعبة لغيرك                                                                                                                                                  | معرفة أين يذهب وقت الفريق                   |
| ساعات العمل والرد السريع                 | الحضور الطويل والرد في منتصف الليل                                                                                                                                                       | اكتشاف الإرهاق Burnout، لا مكافأته          |

ولاحظ أن هذه الأرقام ليست كلها بلا فائدة، فورقة SPACE نفسها تضعها في بعد النشاط Activity، ولكنها تقول بوضوح إنها «should never be used in isolation either to reward or to penalize developers»، أي لا تستخدم وحدها لمكافأة المطورين أو معاقبتهم، والسبب أن ارتفاعها قد يعني أنظمة أفضل وقد يعني أن المطور يعوض بالساعات عن خطة سيئة، والرقم لا يخبرك أيهما. وهي الفكرة نفسها التي شرحناها في [المقاييس التي تبدو جيدة Vanity Metrics](https://arabroot.io/articles/%D9%85%D9%82%D8%A7%D9%8A%D9%8A%D8%B3-%D8%A7%D9%84%D9%85%D9%86%D8%AA%D8%AC-%D9%88%D8%AA%D8%AD%D9%84%D9%8A%D9%84%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AE%D8%AF%D8%A7%D9%85-product-metrics/#vanity) للمنتج: إذا ارتفع الرقم ولم يتغير أي قرار، فهو رقم للعرض.

وقد بنينا في [مختبر مقال الأدوات](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%AA%D9%82%D9%8A%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D8%AF%D8%A7%D8%A1-%D9%88%D9%85%D9%82%D8%A7%D9%8A%D9%8A%D8%B3-%D9%81%D8%B1%D9%82-%D8%A7%D9%84%D8%AA%D8%B7%D9%88%D9%8A%D8%B1/#lab-break) الميزة نفسها مرتين، مرة في أربعة طلبات دمج ومرة في ستة عشر، فارتفع عدد الطلبات أربع مرات، وانخفض زمن التغيير Change Lead Time من 28 ساعة إلى ساعة واحدة، بينما بقي الوقت من أول سطر إلى وصول الميزة للمستخدم 14 يوماً في الحالتين.

## ماذا تقيس على كل مستوى؟

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

![ثلاثة مستويات: المؤسسة تقيس نتائج المنتج والعمل مثل رضا العملاء والعودة والإيرادات، والفريق يقيس طريقة التسليم بمقاييس DORA والتدفق واستبيان SPACE، والفرد يقيم بالنتائج والسلوك مقابل مصفوفة الكفاءات وأدلة العمل وآراء الزملاء وجودة القرارات، وبجانبها قائمة أرقام لا تستخدم لتقييم الفرد مثل عدد الأسطر وال commits ونقاط القصة وطلبات الدمج](https://arabroot.io/content/images/2026/10/dev-evaluation-01-levels.webp)

الخطأ الأشهر أن تنزل مقياساً من مستوى الفريق إلى الفرد

في الصورة أعلاه لاحظ التالي:

- كل مستوى له قرارات مختلفة: المؤسسة تقرر الأولويات، والفريق يقرر كيف يعمل، والمدير يقرر مع الفرد التطوير والترقية.
- مقاييس الفريق تناقش في الاستعادة Retrospective مع الفريق كله، ولا تكتب في تقييم أحد.
- تقييم الفرد يعتمد على أدلة مكتوبة طوال الفترة، وليس على رقم تخرجه أداة في آخر الفترة.

## مقاييس الفريق: DORA وSPACE وDevEx

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

| الإطار             | السؤال الذي يجيب عنه                                            | مصدر البيانات                       |
| ------------------ | --------------------------------------------------------------- | ----------------------------------- |
| مقاييس DORA        | كيف يسلم الفريق التغيير إلى الإنتاج؟                            | سجل النشر والحوادث                  |
| إطار SPACE         | ما الأبعاد التي يجب أن تنظر إليها معاً حتى لا تخدعك واحدة منها؟ | أدوات واستبيانات معاً               |
| تجربة المطور DevEx | ما الذي يعطل المطور في يومه؟                                    | استبيانات أساساً، مع بيانات الأنظمة |

### مقاييس DORA

شرحنا مقاييس DORA وطريقة حسابها في [مقال DevOps وSRE وهندسة المنصات](https://arabroot.io/articles/%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86-devops-%D9%88-sre-%D9%88-platform-engineering/#dora)، والذي يهمنا هنا أمران: أن ما يعرف بالمقاييس الأربعة Four Keys أصبح خمسة، وأنها مصممة للفريق والخدمة لا للفرد. فحسب [صفحة تاريخ المقاييس](https://dora.dev/insights/dora-metrics-history/?ref=arabroot.io) بدأت DORA سنة 2014 بأربعة مقاييس، هي تكرار النشر وزمن التغيير Change Lead Time ومتوسط وقت الاستعادة MTTR ونسبة فشل التغيير، وفي 2023 أعيدت تسمية MTTR وتعريفه ليصبح وقت التعافي من النشر الفاشل، وفي 2024 أضيف مقياس خامس. والجدول التالي يبين المقاييس كما في [صفحة المقاييس الحالية](https://dora.dev/guides/dora-metrics/?ref=arabroot.io):

| المجموعة                                                    | المقياس                                                  | ماذا يقيس                                                        |
| ----------------------------------------------------------- | -------------------------------------------------------- | ---------------------------------------------------------------- |
| السرعة Throughput                                           | زمن التغيير Change Lead Time                             | من دخول التغيير إلى نظام إدارة النسخ حتى نشره في الإنتاج         |
| تكرار النشر Deployment Frequency                            | عدد مرات النشر في فترة، أو الوقت بين نشرين               |                                                                  |
| وقت التعافي من النشر الفاشل Failed Deployment Recovery Time | كم يستغرق التعافي من نشر فشل واحتاج إلى تدخل فوري        |                                                                  |
| عدم الثبات Instability                                      | نسبة فشل التغيير Change Fail Rate                        | نسبة النشرات التي تحتاج إلى تدخل فوري، مثل التراجع أو إصلاح عاجل |
| نسبة إعادة العمل Deployment Rework Rate                     | نسبة النشرات غير المخطط لها التي سببتها حادثة في الإنتاج |                                                                  |

وتقول الصفحة نفسها إن المقاييس تطبق على مستوى التطبيق أو الخدمة، وإن مقارنة تطبيقات مختلفة جداً مضللة، وإن الهدف «to improve your team's performance over time, not to compete against other teams»، أي أن يتحسن الفريق مع الوقت لا أن يتنافس مع غيره. ولذلك فالقاعدة عندنا أوضح: لا تقم بحساب مقاييس DORA لكل مطور، والسبب أن النشر والتعافي عمل فريق، والمطور الذي يعمل على الخدمة الأصعب سوف يظهر أسوأ دائماً.

### إطار SPACE

نشرت Nicole Forsgren من GitHub وMargaret-Anne Storey من جامعة Victoria وأربعة باحثين من Microsoft Research سنة 2021 ورقة [The SPACE of Developer Productivity](https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/?ref=arabroot.io) في مجلة ACM Queue، وتبدأ الورقة بأساطير منتشرة عن إنتاجية المطور، منها أنها نشاط فقط، وأنها أداء فردي فقط، وأن مقياساً واحداً يكفي، ثم تقترح خمسة أبعاد تبينها الصورة التالية:

![خمسة أبعاد: الرضا والراحة Satisfaction and well-being، والأداء Performance، والنشاط Activity، والتواصل والتعاون Communication and collaboration، والكفاءة والتدفق Efficiency and flow، لكل منها تعريف ومثال، وتحتها ثلاث قواعد: ثلاثة أبعاد على الأقل، ومقياس واحد من رأي الناس، والنتائج مجمعة للفريق](https://arabroot.io/content/images/2026/10/dev-evaluation-03-space.webp)

الأبعاد الخمسة كما في الورقة، والقواعد الثلاث من فقرة طريقة الاستخدام فيها

والقواعد الثلاث في أسفل الصورة هي أهم ما في الورقة لمن يقيم فريقاً، وهذا تفصيلها كما في [نص الورقة](https://web.archive.org/web/20260422043016/https://queue.acm.org/detail.cfm?id=3454124):

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

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

### تجربة المطور DevEx

وفي مايو 2023 نشر Abi Noda وMargaret-Anne Storey وNicole Forsgren وMichaela Greiler في المجلة نفسها ورقة [DevEx: What Actually Drives Productivity](https://web.archive.org/web/20260321034012/https://queue.acm.org/detail.cfm?id=3595878)، وهي تنظر من الجهة الأخرى: بدلاً من أن تسأل كم أنتج المطور، تسأل ما الذي يعطله. وتختصر الورقة تجربة المطور في ثلاثة أبعاد:

- **حلقات التغذية الراجعة Feedback Loops:** كم ينتظر المطور نتيجة البناء والاختبار والمراجعة.
- **العبء الذهني Cognitive Load:** كم يحتاج من جهد ليفهم نظاماً سيئ التوثيق أو أدوات كثيرة.
- **حالة التركيز Flow State:** هل يجد وقتاً متصلاً للعمل دون مقاطعة.

ويجدر أن تعرف أن Noda وGreiler من شركة DX التي تبيع أداة لقياس تجربة المطور، وهذا لا يلغي قيمة الورقة، ولكنه سبب لتقرأ أي رقم تسويقي يبنى عليها بحذر، وسوف نتحدث عن الأداة نفسها في [مقال الأدوات](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%AA%D9%82%D9%8A%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D8%AF%D8%A7%D8%A1-%D9%88%D9%85%D9%82%D8%A7%D9%8A%D9%8A%D8%B3-%D9%81%D8%B1%D9%82-%D8%A7%D9%84%D8%AA%D8%B7%D9%88%D9%8A%D8%B1/#eng-tools). والدرس لمن يقيم فريقه أن جزءاً كبيراً مما يبدو ضعفاً في أداء فرد هو في الحقيقة احتكاك في النظام، مثل بناء يأخذ أربعين دقيقة أو مراجعة تنتظر يومين، وهذا لا يحل في مراجعة الأداء وإنما في طريقة العمل.

## مصفوفة الكفاءات Competency Matrix والسلم الوظيفي

إذا كان تقييم الفرد يقوم على السلوك مقابل مستوى مكتوب، فأنت تحتاج إلى هذا المستوى المكتوب أولاً، وهو ما يسمى مصفوفة الكفاءات Competency Matrix أو السلم الوظيفي Career Ladder. وقد شرحنا في [مقال المقابلات](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%AF%D9%8A%D8%B1-%D9%85%D9%82%D8%A7%D8%A8%D9%84%D8%A9-%D8%AA%D9%82%D9%86%D9%8A%D8%A9-%D8%AA%D9%83%D8%B4%D9%81-%D9%85%D8%B3%D8%AA%D9%88%D9%89-%D8%A7%D9%84%D9%85%D8%B1%D8%B4%D8%AD/#levels) معنى المبتدئ والمتوسط والخبير والقائد التقني بحجم المشكلة والغموض والموازنة، والمصفوفة هي الجدول نفسه بعد أن يصبح أداة للتقييم والترقية، والصورة التالية تبين شكلها:

![جدول أعمدته المستويات مبتدئ ومتوسط وخبير وقائد تقني، وصفوفه الكفاءات التسليم والجودة والتشغيل والتعاون والقرارات، وفي كل خلية سلوك مثل يسلم ميزة كاملة إلى الإنتاج أو يقود حل العطل ويمنع تكراره، وتحته ملخص إطاري Dropbox وGitLab المنشورين](https://arabroot.io/content/images/2026/10/dev-evaluation-05-matrix.webp)

كل خلية سلوك تستطيع أن تراه في العمل وتكتب دليله

وبعض الشركات نشرت سلالمها الوظيفية للمهندسين، ومنها اثنتان تستحقان القراءة قبل أن تكتب سلمك:

- **إطار Dropbox:** في [صفحة Dropbox Engineering Career Framework](https://dropbox.github.io/dbx-career-framework/?ref=arabroot.io) مستويات لمهندس البرمجيات من IC1 إلى IC7، ومسؤوليات أساسية في أربعة أعمدة هي Results وDirection وTalent وCulture، ومسؤوليات حرفة خاصة بكل تخصص. وتقول الصفحة صراحة إن الإطار «not a promotion checklist»، أي ليس قائمة شروط للترقية، وإن الشركة تقيس نجاح مهندسيها بالأثر على العمل بدرجة كبيرة.
- **إطار GitLab:** في [دليل GitLab المنشور](https://handbook.gitlab.com/handbook/engineering/careers/matrix/?ref=arabroot.io) مستويات من Intern وAssociate إلى Staff وPrincipal، وفي [صفحة المستوى Senior](https://handbook.gitlab.com/handbook/engineering/careers/matrix/senior/?ref=arabroot.io) مثلاً ثلاث مجموعات: كفاءات قيادية وكفاءات تقنية ومواءمة مع قيم الشركة، ويرث كل مستوى كفاءات المستوى الذي قبله.

ولا تقم بنسخ سلم شركة كبيرة كما هو لفريق من ثمانية أشخاص، والسبب أن مستويات مثل Principal لا معنى لها عندك، وأن كثرة الخلايا تجعل التقييم ملء استمارة. والأفضل أن تبدأ بثلاثة أو أربعة مستويات وأربع كفاءات كما في الصورة، وأن تكتب كل خلية كسلوك يمكن رؤيته، مثل «يقود حل العطل ويمنع تكراره»، لا كصفة مثل «متمكن»، وأن تستخدم للدرجات مقياساً بأوصاف سلوكية مثل [مقياس الدرجات في المقابلة](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%AF%D9%8A%D8%B1-%D9%85%D9%82%D8%A7%D8%A8%D9%84%D8%A9-%D8%AA%D9%82%D9%86%D9%8A%D8%A9-%D8%AA%D9%83%D8%B4%D9%81-%D9%85%D8%B3%D8%AA%D9%88%D9%89-%D8%A7%D9%84%D9%85%D8%B1%D8%B4%D8%AD/#rubric)، فهذا ما يسمى المقياس المرتبط بالسلوك Behaviourally Anchored Rating Scale واختصاراً BARS.

وقد يتساءل البعض: أين المكان المناسب لأفكار مثل ملكية النتيجة والحديث مع المستخدمين؟ والإجابة أنها تدخل في المصفوفة إذا كانت جزءاً من الدور عندك، كما في دور [مهندس المنتج Product Engineer](https://arabroot.io/articles/%D9%85%D9%87%D9%86%D8%AF%D8%B3-%D8%A7%D9%84%D9%85%D9%86%D8%AA%D8%AC-product-engineer/#career)، وملكية الخدمة في الإنتاج كما في [مقال المسؤولية عند تعطل الإنتاج](https://arabroot.io/articles/%D9%85%D9%86-%D9%8A%D8%AA%D8%AD%D9%85%D9%84-%D8%A7%D9%84%D9%85%D8%B3%D8%A4%D9%88%D9%84%D9%8A%D8%A9-%D8%B9%D9%86%D8%AF%D9%85%D8%A7-%D9%8A%D8%AA%D8%B9%D8%B7%D9%84-%D8%A7%D9%84%D8%A7%D9%86%D8%AA%D8%A7%D8%AC/)، فالمصفوفة تكتب لدور حقيقي في فريقك لا لمطور مثالي.

## ماذا يغير الذكاء الاصطناعي في التقييم؟

جمعنا ما تقوله الدراسات عن أثر الذكاء الاصطناعي على المطورين في [مقال Agile في عصر الذكاء الاصطناعي](https://arabroot.io/articles/agile-%D9%81%D9%8A-%D8%B9%D8%B5%D8%B1-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A/#evidence-summary)، وخلاصتها أن المهمة الصغيرة تنجز أسرع وأن التسليم في بيانات DORA للسنتين 2024 و2025 أقل استقراراً. وأثر ذلك على التقييم مباشر:

- **أرقام النشاط فقدت ما تبقى من معناها:** الأداة تكتب مئات الأسطر في دقيقة، فعدد الأسطر والطلبات يقيس الآن من يستخدم الأداة أكثر، لا من يعمل أفضل.
- **المراجعة أصبحت عملاً أساسياً:** من يراجع كود الأداة بجدية يمنع أخطاء لا تظهر في أي عداد، كما شرحنا في [مراجعة كود الذكاء الاصطناعي](https://arabroot.io/articles/%D9%85%D8%B1%D8%A7%D8%AC%D8%B9%D8%A9-%D9%83%D9%88%D8%AF-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A-%D8%AF%D9%88%D9%86-%D8%A7%D9%86-%D8%AA%D8%B5%D8%A8%D8%AD-%D8%B4%D9%83%D9%84%D9%8A%D8%A9/)، فاجعل جودة المراجعة جزءاً من كفاءة التعاون.
- **المسؤولية لا تنتقل إلى الأداة:** من يدمج الكود يملكه، وما يحدث بعد النشر من حوادث وإعادة عمل جزء من تقييم الفريق كما في [جودة كود الذكاء الاصطناعي](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%AC%D9%88%D8%AF%D8%A9-%D8%A7%D9%84%D9%83%D9%88%D8%AF-code-quality-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%8A%D8%B3%D9%87%D8%A7/#ai-code).
- **لا تجعل نسبة استخدام الأداة هدفاً:** لا تقم بمكافأة من «يستخدم الذكاء الاصطناعي أكثر»، والسبب أنه رقم يرتفع بسهولة ولا يقول شيئاً عن النتيجة.

## تحيز من يقيم وكيف تقلله

المشكلة التي يتجاهلها أغلب من يصمم نظام تقييم أن الدرجة تقول عن المقيم بقدر ما تقول عن الشخص المقيم أو أكثر. ففي دراسة نشرها Scullen وMount وGoff سنة 2000 في مجلة Journal of Applied Psychology على مجموعتين من آلاف المديرين، حصل كل واحد منهم على تقييم من سبعة أشخاص هم مديران وزميلان ومرؤوسان والمدير نفسه، وجاء 62% و53% من الاختلاف في الدرجات من الميول الخاصة لكل مقيم، بينما جاء من أداء الشخص نفسه 21% و25% فقط، كما في [ملخص الدراسة](https://www.semanticscholar.org/paper/0a73fb7d291a407656d4ee4a9b1eb19514abe157?ref=arabroot.io). والصورة التالية تبين أشهر صور هذا التحيز، وما يقلل كل واحد منها:

![خمسة تحيزات: الحداثة Recency يقللها سجل أدلة طوال الفترة، والهالة Halo تقللها درجة لكل كفاءة مع دليلها، والتشابه Similar-to-me يقلله وصف سلوكي مكتوب وأكثر من مقيم، والتساهل أو التشدد Leniency و Severity يقلله اجتماع المعايرة، والنزعة الوسطى Central Tendency يقللها مقياس زوجي الدرجات، وتحتها أن 62% و53% من الاختلاف في الدرجات جاء من ميول المقيم في دراسة سنة 2000](https://arabroot.io/content/images/2026/10/dev-evaluation-04-bias.webp)

علاج التحيز في طريقة التقييم نفسها، لا في نية المدير

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

1. **سجل أدلة طوال الفترة:** ملاحظات قصيرة بعد كل اجتماع 1:1 ومشروع، ويكتب الموظف سجله أيضاً كما في [التقييم الذاتي](https://arabroot.io/articles/%D8%AF%D9%88%D8%B1%D8%A9-%D8%AA%D9%82%D9%8A%D9%8A%D9%85-%D8%A7%D8%AF%D8%A7%D8%A1-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82-%D8%A7%D9%84%D8%AA%D9%82%D9%86%D9%8A-%D9%85%D8%AA%D9%89-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%8A%D9%85/#self-review).
2. **درجة لكل كفاءة مع دليل:** بدلاً من درجة واحدة عامة، وهذا يكسر أثر الهالة.
3. **أكثر من مصدر:** آراء الزملاء ومن يعمل معهم الشخص من فرق أخرى.
4. **المعايرة Calibration بين المديرين:** اجتماع يقارن فيه المديرون درجاتهم بالأدلة قبل أن تصبح نهائية، وقد شرحناه في [مقال الدورة](https://arabroot.io/articles/%D8%AF%D9%88%D8%B1%D8%A9-%D8%AA%D9%82%D9%8A%D9%8A%D9%85-%D8%A7%D8%AF%D8%A7%D8%A1-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82-%D8%A7%D9%84%D8%AA%D9%82%D9%86%D9%8A-%D9%85%D8%AA%D9%89-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%8A%D9%85/#calibration)، وبنينا له محاكاة في [مقال الأدوات](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%AA%D9%82%D9%8A%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D8%AF%D8%A7%D8%A1-%D9%88%D9%85%D9%82%D8%A7%D9%8A%D9%8A%D8%B3-%D9%81%D8%B1%D9%82-%D8%A7%D9%84%D8%AA%D8%B7%D9%88%D9%8A%D8%B1/#calibration-sim).

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

## أخطاء شائعة

- **لوحة لكل مطور:** عرض عدد ال commits والطلبات لكل شخص يحول الأرقام إلى منافسة، حتى لو قلت إنها «للاطلاع فقط».
- **مقاييس DORA في مراجعة الفرد:** هي مقاييس للخدمة والفريق، ونقلها إلى الفرد يعاقب من يعمل على الأصعب.
- **الأثر وحده:** يكافئ الحظ والمشاريع السهلة، ويعاقب القرار الجيد بعدم الإطلاق كما في قصة Beck.
- **مصفوفة منسوخة:** سلم شركة من آلاف المهندسين لا يناسب فريقاً صغيراً.
- **صفات بدل السلوك:** كلمات مثل «مبادر» و«متمكن» دون مثال يمكن رؤيته.
- **التقييم من الذاكرة:** ما حدث في آخر شهر يغطي على السنة كلها.
- **تجاهل العمل غير المرئي Invisible Work في التقييم:** التوجيه والتوثيق والمراجعة لا تظهر في الأدوات، فإذا لم تكتبها لن يراها أحد.

## الخلاصة

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

- طريقة التقييم حافز يغير سلوك الفريق، فإذا قست الشيء الخطأ فسوف يتحسن الشيء الخطأ.
- قيم الفرد بالنتائج التي ساهم فيها وبالسلوك مقابل مستوى مكتوب، وقيم القرار مع النتيجة.
- أرقام النشاط مثل الأسطر وال commits والطلبات ونقاط القصة لا تستخدم وحدها لمكافأة أحد أو معاقبته.
- مقاييس DORA الحالية خمسة، وهي للفريق والخدمة، وإطار SPACE يطلب ثلاثة أبعاد على الأقل ومقياساً من رأي الناس، وDevEx يسأل ما الذي يعطل المطور.
- مصفوفة الكفاءات Competency Matrix مكتوبة كسلوك يمكن رؤيته، وأصغر من سلالم الشركات الكبيرة.
- جزء كبير من الدرجة يأتي من المقيم نفسه، والعلاج سجل أدلة ودرجة لكل كفاءة وأكثر من مصدر ومعايرة Calibration بين المديرين.

وفي [المقال التالي](https://arabroot.io/articles/%D8%AF%D9%88%D8%B1%D8%A9-%D8%AA%D9%82%D9%8A%D9%8A%D9%85-%D8%A7%D8%AF%D8%A7%D8%A1-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82-%D8%A7%D9%84%D8%AA%D9%82%D9%86%D9%8A-%D9%85%D8%AA%D9%89-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%8A%D9%85/) بإذن الله سوف نبني دورة التقييم نفسها: كل كم تقيم، وكيف تكتب الأهداف والتقييم الذاتي وآراء الزملاء، وكيف تدير اجتماع المعايرة، وماذا تفعل عندما لا يكون الأداء كما يجب.

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

- أكتوبر 2026: كتابة المقال، ومراجعة صفحتي مقاييس DORA وتاريخها في dora.dev، وورقتي SPACE (ACM Queue، فبراير 2021) وDevEx (ACM Queue، مايو 2023)، وإطاري Dropbox وGitLab المنشورين، وملخص دراسة Scullen وMount وGoff (2000)، مع رسومات لمصفوفة الكفاءات Competency Matrix وسلسلة النشاط والأثر والمستويات وإطار SPACE والتحيزات.