مطاردة الأشباح: كيف تكشف المساهمة الفعلية للمطوّرين

«Ghost engineers» — واحد من كل عشرة مطوّرين لا ينجز تقريبًا أي عمل مفيد، بل يكتفي بتقديم عرض مقنع لانشغاله. وقد تبقى الأسباب الحقيقية لهذا الخمول — العمل في وظيفة أخرى، أو الاحتراق الوظيفي، أو التهرّب الصريح من العمل — مخفية عن الإدارة لوقت طويل جدًا. (دراسة ستانفورد لعام 2024: سلسلة المنشورات الأصلية)

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

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

وربما يجدر بنا أن نتركهم وشأنهم — هؤلاء الأشباح. ففي النهاية، لن تشعر الشركة حتى بنقص ذلك المال.

لكن هناك مشكلة صغيرة…

عندما أتحدث عن ضعف الأداء، لا أقصد حالة يجلس فيها أحمد ويكدّ ويتعب ثم ينجز أقل من خالد بنسبة 10%. أقصد شيئًا آخر: في كل اجتماع stand-up، يضطر الفريق كله إلى سماع قصة مؤثرة جديدة — خذلهم الفريق الآخر، وكانت صياغة المهمة غامضة، ولم تصطف النجوم. لكن المهمة ستكون جاهزة غدًا بالتأكيد. هذا وعد.

إلا أن «غدًا» هذا كان بالأمس وقبل الأمس — وأصبح الآن تقليدًا.

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

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

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

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

هل يستطيع المدير اكتشاف المشكلة مبكرًا — أن يرى الانحراف، ويطلب السياق، ويتقصّى الأمر قبل أن يفقد الفريق صبره وتخسر الشركة وقتها ومالها؟

مع خبرة كافية، يمكن التعرّف إلى هذه الحالات مسبقًا من خلال أنماط سلوكية معروفة:

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

لكن التحقق من الشكوك يحتاج إلى آثار رقمية.

لنلقِ نظرة على أشهر أدوات قياس أداء التطوير، وعلى مدى قدرتها على كشف الأشباح.

وقبل المقارنة، يجب أن أوضح تضارب المصالح البديهي: أنتم تقرؤون المدوّنة الرسمية لـ DevGhost، وأنا مؤسس المنتج. لذلك فهذا تحليل من وجهة نظر الكاتب، لا دراسة مستقلة.

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

DORA: سرعة الإصدارات وموثوقيتها

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

هذا تقييم جيد لعملية delivery، لكنه ليس تقييمًا للمساهمة الفردية. فإذا كان شخص واحد يؤدي عمل ثلاثة بينما يختبئ آخر خلف النتيجة الإجمالية للفريق، فلن تخبرك DORA بذلك.

كما أن هذه المقاييس مريحة للغاية بوصفها مؤشرات KPI. ففي شركة عملت فيها، كنا نستنزفها منذ عام 2018: نلوّن كل لوحات المعلومات بالأخضر بنجاح، ويبقى الجميع سعداء. نموذج DORA الحالي.

الاختبارات والعيوب: ما مدى جودة العمل؟

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

لكن هذه الإشارات لا تقول شيئًا عن الحجم. فتعديل صغير واحد لا تشوبه شائبة سيحوّل كل المؤشرات إلى اللون الأخضر — وسيبقى الشبح غير مرئي.

Jira وstory points: كم مهمة أُغلقت؟

تعرض Jira المهام المغلقة وstory points، لكن الفريق نفسه هو من يضع التقديرات. فالعمل نفسه قد يُقدّر بثلاث نقاط أو بثلاث عشرة، وقد يُقسّم إلى خمس مهام أو يُجمع في مهمة واحدة.

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

وهي ملائمة لمؤشرات KPI أيضًا. تُدخل البيانات وتُنقل المهام فقط من أجل اجتياز quality gates. كثير من العمل اليدوي عديم الفائدة.

الـ commits وأسطر الكود: حقائق بلا سياق

لا يعتمد Git على تقديرات الفريق، ولذلك يبدو عدّ الـ commits والأسطر أمرًا مغريًا. لكن خمسة commits قد لا تمثل سوى تعديل صغير واحد، في حين قد يمثل squash commit واحد أسبوعًا كاملًا من العمل.

يؤدي التنسيق والتوليد والنسخ ونقل الكود إلى تضخيم عدد الأسطر، بينما قد لا يتجاوز إصلاح معقد عشرة أسطر.

Swarmia وLinearB وWaydev: النظام الهندسي كله في مكان واحد

تجمع Swarmia وLinearB وWaydev بيانات Git ونظام تتبع المهام وCI/CD. ويرى المديرون مقاييس DORA، وقوائم انتظار المراجعة، وزمن مرور التغييرات، ونتائج الاستبيانات.

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

GitClear: ما الذي يبقى بعد ضوضاء الكود؟

يميّز GitClear بين الكود المضاف والمنقول والمنسوخ، ويستبعد الملفات المولّدة، ويأخذ في الحسبان ما إذا كان الكود الجديد قد أُعيدت كتابته أو حُذف لاحقًا.

ومن ذلك ينتج Diff Delta — وحدة GitClear الخاصة للتغييرات الجوهرية التي بقيت في قاعدة الكود. فالكود المنسوخ أو الذي يُرمى سريعًا يحمل وزنًا أقل من تغيير مدمج يستمر في العمل في بيئة الإنتاج. كيف يعمل Diff Delta.

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

لقد اقتربنا. تنشر الخدمة معايير مرجعية، لكن Diff Delta يظل وحدة خاصة بها: رقم مثل 10,000 لا يقول الكثير من دون مقارنة مناسبة وفهم للمنهجية. ولا توجد هنا نقطة مرجعية واضحة من قبيل «100% هو المستوى الطبيعي». معايير Diff Delta المرجعية.

BlueOptima: السؤال نفسه على نطاق المؤسسات

أعرف BlueOptima من تجربة مباشرة. بدأت العمل مع المنصة عام 2019، وكانت تلك التجربة هي ما ألهمني لبناء منتجي الخاص.

تحلل خوارزمية Coding Effort كل تغيير في الكود المصدري باستخدام مجموعة من المقاييس الساكنة، وتأخذ في الحسبان حجمه وتعقيده وعلاقته ببقية الكود، ثم تعبّر عن النتيجة بالساعات.

ويتيح ذلك مقارنة المطوّرين من فرق وتقنيات مختلفة، بما في ذلك مقارنتهم بمعيار عالمي. وبالنسبة إليّ، كانت هذه أول محاولة مقنعة للإجابة لا عن سؤال «كم سطرًا كتب هذا المطوّر؟»، بل عن سؤال «كم من العمل الجوهري تمثله هذه التغييرات؟». منهجية BlueOptima، المعيار العالمي.

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

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

المقياس نفسه، من دون مناقصة

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

كنت أريد الإجابة نفسها التي قدمتها BlueOptima — كم من العمل الجوهري يقف خلف التغييرات — ولكن في صورة يستطيع مالك شركة ناشئة أو فريق صغير استخدامها من دون مناقصة، أو عملية نشر طويلة، أو فريق من المستشارين.

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

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

يقارن Ghost% هذا التقدير بالإنتاج المتوقع من مطوّر متوسط الخبرة، مع احتساب مقدار الوقت الذي يخصصه الشخص فعلًا للتطوير. وتعني نسبة 100% أن النتيجة متوافقة مع المستوى الطبيعي. أما النتيجة الأقل فهي سبب للبحث في الأسباب؛ والنتيجة الأعلى تستحق الدراسة وربما تحويلها إلى ممارسة فضلى.

يفترض المعيار المرجعي عمدًا العمل من دون ذكاء اصطناعي. ولا يحاول DevGhost تحديد من كتب مقطعًا بعينه — إنسان أم Copilot أم وكيل ذاتي التشغيل. بل يقيّم التغييرات النهائية: كم من الجهد كان سيحتاجه مطوّر متوسط الخبرة لإنشائها والتحقق منها من دون مساعدة الذكاء الاصطناعي؟

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

ومن يحكم على الحَكَم؟

السؤال الأوضح هو: لماذا ينبغي أن نثق أصلًا بتقدير تصنعه آلة؟ الإجابة القصيرة: لا ينبغي أن نثق به ثقة عمياء.

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

وقد يخطئ DevGhost أيضًا. ليست ميزته امتلاك الحقيقة المطلقة، بل تقييم كل التغييرات بالمقياس نفسه — من دون محاباة أو إرهاق أو رأي مسبق في صاحب التغيير.

لذلك فإن Ghost% إشارة، لا حكم نهائي. قد تعني النتيجة المنخفضة مساهمة ضعيفة، لكنها قد تُفسّر أيضًا بمسؤوليات قيادة الفريق، أو العمل المعماري، أو الإرشاد، أو الحوادث، أو العوائق.

يشير الرقم إلى المكان الذي يستحق طرح السؤال. ولا يزال على المدير البحث عن الإجابة — لكنه يستند الآن إلى رأي ثانٍ مستقل، لا إلى الحدس وحده.

«أنا أعرف أصلًا كيف يعمل كل فرد في فريقي»

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

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

لاحقًا، عندما بدأ المطوّرون يغادرون، اتضح أنهم كانوا طوال تلك الفترة يبنون منتجاتهم الخاصة بالتوازي. لم يكن بوسع DevGhost معرفة السبب. لقد أظهر فقط ما لم يظهر في عدد الـ commits أو pull requests أو المحادثات اليومية على Slack: كان حجم عملهم أقل من المتوقع بوضوح.

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

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

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

ماذا لو قدّم مطوّر واحد إنتاج ثلاثة؟

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

إذا كان مطوّر ما يقدّم باستمرار أضعاف متوسط الإنتاج، فمن المفيد معرفة كيف يحقق ذلك بالضبط.

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

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

يساعد Ghost% المرتفع على العثور على المطوّرين الذين تحقق شراكتهم مع الوكلاء نتائج قوية بالفعل — وفهم الممارسات التي يستطيع بقية الفريق تبنيها.

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

لا تحوّلوا المقياس إلى عصا

ينتهي كل مقياس إلى المصير نفسه: عاجلًا أم آجلًا يحاول أحدهم تحويله إلى KPI. ولا يصلح Ghost% لذلك.

اجعل Ghost% مؤشر KPI للفريق، وسيبدأ الناس بتحسين عملهم من أجله. انشر ترتيبًا، وستختفي الثقة. حوّل النتيجة إلى زر للفصل، وستصبح الأخطاء حتمية.

سأضع أربع قواعد:

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

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

إذا تأكدت المشكلة، فلا بد من خطة تحسين محددة وإعادة تقييم بعد مدة متفق عليها.

رفض المقاييس لا يلغي تقييم الناس. إنه لا يفعل سوى استبدال الأرقام بالانطباعات، والقصص التي تُروى في اجتماعات stand-up، وتفضيلات المدير الشخصية.

تحتاج السرعة والجودة وحجم العمل إلى أدوات مختلفة. تُظهر DORA كيف تتحرك التغييرات نحو الإنتاج. وتُظهر الاختبارات والعيوب الجودة. ويضيف DevGhost تقديرًا للعمل الكامن خلف تغييرات الكود.

ولا ينبغي لأي من هذه المقاييس أن يتخذ القرار بدلًا من المدير.

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

كيف تقيّمون حجم عمل المطوّرين — وأين ترسمون الحد بين الشفافية المفيدة والمراقبة؟