وافقت البيانات على ذلك، في البداية.

ما قيل لنا

قيل لنا إن أحد المهندسين كان أداؤه دون المستوى المطلوب.

جاءت هذه المخاوف من قيادتَي المنتج والهندسة.

وُصِف المهندس بأنه يستغرق وقتًا طويلًا جدًا في التسليم، ويعترض على القرارات بشكل متكرر، ويُخل بانسجام الفريق.

كانت المؤسسة تفكر في إخراج هذا المهندس من الفريق.

بدت الأدلة واضحة.

من وقت تكليفه بالعمل في GitHub وحتى فتح طلب سحب (pull request)، كان هذا المهندس غالبًا يستغرق وقتًا أطول مما كنا نتوقعه للتنفيذ نفسه.

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

ما لاحظناه

أظهر GitHub الوقت المنقضي.

لكنه لم يُظهر ما كان يفعله المهندس خلال ذلك الوقت.

لذا تتبّعنا العمل في Slack.

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

لم تكن هذه اعتراضات عشوائية.

بل كانت محاولات لفهم خلفية المتطلب أو اقتراح بديل قبل بدء التنفيذ.

كان مالك المنتج يتعامل عمومًا مع هذه الأسئلة والاقتراحات باعتبارها غير ضرورية.

عندما كان يُرفض اقتراح ما، كان المهندس يبدأ التنفيذ فورًا.

وعندما كان سؤال أو اقتراح لا يلقى أي رد، لم يكن المهندس ينتظر إلى ما لا نهاية.

وبعد ثلاثة أيام عمل، كان يعلن أنه لم يتلقَّ أي رد، وأن التنفيذ سيمضي بناءً على الطلب الأصلي.

وعندها فقط كانت تبدأ أعمال كتابة الكود.

النمط

كانت المؤسسة تقيس كامل الوقت بين التكليف والتسليم باعتباره وقت تنفيذ هندسي.

لكن جزءًا كبيرًا من هذا الوقت كان يُنفق قبل بدء التنفيذ.

كان المهندس يحاول توضيح القصد، ومساءلة الافتراضات، أو اقتراح بديل.

لم تكن هذه الأنشطة تُحتسب كعمل مفيد.

بل كانت تُفسَّر على أنها تأخير.

وقد شكّل هذا التفسير أيضًا سمعة المهندس.

بدا طرح الأسئلة وكأنه مقاومة.

وبدا اقتراح البدائل وكأنه رفض لاتباع التعليمات.

وبدا انتظار قرار منتج لم يُحسم بعد وكأنه بطء في التنفيذ.

وهكذا استُخدم السلوك نفسه دليلًا على عدة أحكام سلبية بشأن الشخص.

ثم وجدنا إشارة أخرى

بعض اقتراحات المهندس التي رُفضت أو جرى تجاهلها لم تختفِ.

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

وكان الاقتراح الذي عُومل سابقًا باعتباره غير ضروري قد يعود لاحقًا كمتطلب رسمي.

كان لذلك أهمية.

إذ أظهر أن أسئلة المهندس واقتراحاته البديلة لم تكن مجرد عرقلة.

بل كان بعضها على الأقل يحدد تحسينات كانت مؤسسة المنتج ستريدها في نهاية المطاف على أي حال.

فرضيتنا

لم يكن المهندس يعاني في الأساس من مشكلة في الكفاءة.

كانت المؤسسة قد أوجدت بيئة يُكافَأ فيها نوع واحد من السلوك الهندسي فوق كل الأنواع الأخرى:

تنفيذ التعليمات كما وردت تمامًا.

كان التشكيك في المواصفة يُنتج تأخيرًا.

وكان اقتراح بديل يُنتج احتكاكًا.

وكان انتظار التوضيح يزيد من زمن التنفيذ المُقاس (lead time).

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

لم يكن النظام يقيس مجرد سرعة التسليم.

بل كان يكافئ بشكل غير مباشر الالتزام بالتعليمات.

لماذا بدا التشخيص الأصلي مقنعًا

لم يكن الحكم الأصلي مبنيًا على بيانات وهمية.

فقد كان الوقت المنقضي أطول فعلًا.

وهذا ما جعل هذه الحالة مثيرة للاهتمام.

دعم مصدر واحد من الأدلة استنتاج المؤسسة.

ولو توقفنا عند GitHub، لكنا وصلنا إلى الاستنتاج نفسه.

لكن هذا المقياس كان يجيب عن سؤال واحد فقط:

كم من الوقت انقضى بين التكليف والتسليم؟

ولم يكن يجيب عن:

• متى بدأ التنفيذ فعليًا؟
• ماذا حدث قبل التنفيذ؟
• من كان ينتظر من؟
• ما القرارات التي ظلت معلقة؟
• ما القيمة التي كانت تُخلق خارج الكود نفسه؟

ما أظهرته الأدلة

كان المهندس أبطأ إذا قِسنا فقط وقت التسليم المنقضي.

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

وبمجرد أن فصلنا التنفيذ عن التوضيح والاقتراح واتخاذ القرار ووقت الانتظار، تغيّر معنى هذا الرقم.

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

لم يكن إخراج المهندس من الفريق ليُصلح ذلك النمط.

بل كان سيُزيل فقط الشخص الذي جعل سلوكه هذا النمط ظاهرًا.

لم تكن البيانات خاطئة. كان التفسير ناقصًا.

وجهة نظر Pulsar

لا نبدأ بالحكم على ما إذا كان شخص ما جيدًا أو سيئًا في عمله.

بل نتتبّع العمل.

في هذه الحالة، أظهر GitHub أن التسليم استغرق وقتًا أطول.

وأظهر Slack السبب.

وأظهرت قرارات المنتج اللاحقة أن جزءًا من السلوك المفترض أنه غير ضروري كان في الواقع يحدد قيمة حقيقية.

لم تكن أي من هذه الملاحظات كافية بمفردها لسرد القصة كاملة.

لكنها معًا غيّرت التشخيص.

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