كان الفريق يفعل بالضبط ما طُلب منه.

ما قيل لنا

كانت إحدى مؤسسات التطوير تعاني من مشكلة في الإنتاجية.

كان العمل يستغرق وقتًا أطول من المتوقع. كانت الميزات تصل إلى مرحلة المراجعة لكنها لا تُقبل. وكانت الإصدارات تتأخر.

من جانب المنتج، بدا التفسير بسيطًا: فريق التطوير لا يسلّم باستمرار ما طُلب منه.

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

ما لاحظناه

كان الفريق يعمل بشكل تكراري (iterative).

قبل التنفيذ، كانت تُناقش قصة (story) ويُحدَّد السلوك المتوقع منها. ثم يقوم فريق التطوير بتنفيذ ذلك السلوك خلال السبرنت (sprint).

لم يكن المهندسون يتجاهلون تلك المتطلبات.

بل كانوا ينفذونها.

ظهرت المشكلة لاحقًا.

أثناء المراجعة، كان يصبح أحيانًا سلوك لم يكن جزءًا من معايير القبول المتفق عليها ضروريًا لقبول العمل.

على سبيل المثال، قد تحدد إحدى القصص سير عمل معين لعملية محددة.

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

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

وأثناء المراجعة، قد يتحول التوقع إلى أن يتعافى النظام نفسه من الفشل، دون الحاجة إلى تدخل المستخدم.

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

كان بإمكان كل طلب أن يكون معقولًا بمفرده.

لم تكن تلك هي المشكلة.

النمط

لم تكن التوقعات الجديدة تُعامَل كتعديلات على المواصفات.

بل كانت تُعامَل كدليل على أن فريق التطوير فشل في تنفيذ المواصفات الأصلية بشكل صحيح.

غيّر هذا التمييز كل شيء.

من منظور مالك المنتج (product owner)، لم تكن الميزة المطلوبة قد اكتملت.

ومن منظور فريق التطوير، كانت معايير القبول المتفق عليها قد نُفذت — وكانت متطلبات جديدة تظهر بعد التنفيذ.

وصفت المؤسسة التأخير الناتج بأنه ضعف في إنتاجية الهندسة.

لكن التسلسل الملحوظ للعمل كان مختلفًا:

1. كان يتم الاتفاق على معايير القبول.
2. كان فريق التطوير ينفذها.
3. كانت تظهر توقعات جديدة أثناء المراجعة.
4. لم تُصنَّف التوقعات الجديدة كتعديلات.
5. وبالتالي كان التنفيذ الأصلي يُعامَل باعتباره غير مكتمل.
6. أطال العمل الإضافي وقت التسليم.
7. وكان يُعزى التأخير إلى إنتاجية الهندسة.

فرضيتنا

لم يكن فريق التطوير يعاني في الأساس من مشكلة إنتاجية.

كان النظام المستخدم لتحديد ما إذا كان العمل مكتملًا غير مستقر.

كان بإمكان الفريق استيفاء معايير القبول القائمة عند بدء التنفيذ، ومع ذلك يفشل في المراجعة، لأن المعايير الفعلية كانت قد تغيرت بحلول وقت تقييم العمل.

يخلق ذلك مشكلة إنتاجية يصعب حلها بشكل خاص.

تحسين سرعة كتابة الكود لا يحل المشكلة.

تحسين الأدوات لا يحلها.

مطالبة المطورين بتقدير أدق لا تحلها.

وحتى جعل الفريق أسرع بشكل كبير لن يؤدي إلا إلى وصوله بشكل أسرع إلى هدف متحرك.

لماذا كان من الصعب رؤية المشكلة

لم يكن على أحد أن يكون غير صادق حتى ينشأ هذا النظام.

كان بإمكان مالك المنتج أن يعتقد بصدق أن السلوك الإضافي كان جزءًا واضحًا مما طُلب أصلًا.

وكان بإمكان المطورين أن يعتقدوا بصدق أنهم نفذوا بالضبط ما تم الاتفاق عليه.

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

لكن لا هذا ولا ذاك كان يصف، بمفرده، ما كان يحدث للعمل فعليًا.

لذا لم نكن بحاجة إلى تحديد أي تفسير كان صحيحًا.

قارنّا معايير القبول القائمة قبل التنفيذ بالتوقعات المطبَّقة أثناء المراجعة.

وكان الفرق ملحوظًا.

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

كانت المشكلة المُبلَّغ عنها هي انخفاض إنتاجية الهندسة.

أما المشكلة الملحوظة فكانت أن شروط قبول العمل المكتمل يمكن أن تتغير بعد أن يكون العمل قد نُفذ بالفعل.

ونتيجة لذلك، كان يمكن تصنيف عمل مطابق للمواصفات المتفق عليها على أنه غير مكتمل.

كان يُقاس أداء الفريق وفق متطلبات لم تكن بالضرورة موجودة عند بدء العمل.

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

لم يكن المطورون يفشلون في تلبية معايير القبول. بل كانت معايير القبول تتحرك بعد إنجاز العمل.

وجهة نظر Pulsar

لو قبلنا بالتشخيص الأصلي، لكنا بدأنا بالسؤال عن كيفية جعل فريق التطوير أسرع.

لكننا بدلًا من ذلك تتبّعنا العمل من الاتفاق إلى التنفيذ إلى المراجعة.

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

كانت المشكلة المُعلنة هي إنتاجية الهندسة. أما المشكلة الملحوظة فكانت في مكان آخر.