مقاييس وأنظمة التسليم الهندسي

ما تقيسه يشكل ما تُحسّنه فرقك. المقاييس الخاطئة تخلق حوافز ضارة -- قياس أسطر الكود يكافئ الإسهاب، وقياس نقاط القصة المكتملة يكافئ تضخيم النقاط. المقاييس الصحيحة تُنير ما إذا كانت مؤسستك الهندسية تُسلّم قيمة بشكل مستدام. تختبر مقابلات مدير الهندسة بشكل متكرر ما إذا كنت تفهم أي المقاييس مهمة وكيف تستخدمها دون تحويلها إلى أسلحة.

مقاييس DORA

تأتي أكثر المقاييس الهندسية المُصادق عليها بدقة من فريق DORA (بحث وتقييم DevOps) في Google. هذا البحث، بقيادة نيكول فورسغرين وجيز هامبل وجين كيم، نُشر في كتاب "Accelerate" (2018) ومدعوم بسنوات من بيانات الاستطلاعات من آلاف المؤسسات. يحدد البحث أربعة مقاييس رئيسية تتنبأ بكل من الأداء التنظيمي وقدرة تسليم البرمجيات:

المقياس	ما يقيسه	الأداء المتميز	الأداء المنخفض
تكرار النشر	كم مرة يُنشر الكود إلى الإنتاج	حسب الطلب، عدة مرات يومياً	بين مرة شهرياً ومرة كل ستة أشهر
وقت التسليم للتغييرات	الوقت من إيداع الكود إلى تشغيله في الإنتاج	أقل من ساعة	بين شهر وستة أشهر
معدل فشل التغيير	نسبة عمليات النشر التي تسبب فشلاً يتطلب معالجة	0-15%	46-60%
وقت استعادة الخدمة (MTTR)	كم يستغرق التعافي من فشل في الإنتاج	أقل من ساعة	بين شهر وستة أشهر

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

عند مناقشة مقاييس DORA في المقابلات، اذكر ثلاث نقاط رئيسية:

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

تتبع السرعة

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

المزالق الشائعة مع السرعة:

مقارنة السرعة بين الفرق. فريق A يكمل 40 نقطة في كل سبرنت وفريق B يكمل 25 نقطة لا يقول شيئاً عن الإنتاجية النسبية. كل فريق يُعاير نقاط القصة بشكل مختلف.
استخدام السرعة كمقياس أداء. عندما يستخدم المديرون السرعة لتقييم الفرق، تُضخّم الفرق تقديرات النقاط لتبدو منتجة. يصبح المقياس بلا معنى.
تجاهل تباين السرعة. فريق يبلغ متوسطه 30 نقطة في السبرنت لكنه يتأرجح بين 15 و45 لديه مشكلة قابلية تنبؤ تستحق التحقيق.

الاستخدام الصحيح للسرعة هو حساب متوسط متحرك (عادةً على مدى 3-5 سبرنتات) واستخدامه كمدخل للتنبؤ. إذا كان المتوسط المتحرك 32 نقطة وقائمة المهام للمعلم التالي تحتوي على 128 نقطة، يمكنك التنبؤ بنحو أربعة سبرنتات من العمل.

إنشاء خارطة الطريق

تربط خرائط الطريق الهندسية بين الاستراتيجية والتنفيذ. تجيب على ثلاثة أسئلة: ماذا نبني؟ لماذا يهم؟ متى سيكون جاهزاً؟

هيكل خارطة طريق عملي يستخدم ثلاثة آفاق زمنية:

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

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

عند بناء خرائط الطريق، انتبه لهذه الفخاخ الشائعة:

كل ميزات، لا بنية تحتية. إذا لم تحتوِ خارطة الطريق على أي استثمار في تحسينات المنصة أو الديون التقنية أو الموثوقية، سيتباطأ الفريق بمرور الوقت.
لا تبعيات مُعلَّمة. أشر إلى التبعيات بين الفرق بشكل صريح. ميزة تتطلب عملاً من ثلاثة فرق تحتاج تنسيقاً، ويجب أن تعكس خارطة الطريق ذلك.
لا هوامش سعة. خطط لنحو 70% من السعة. الـ 30% المتبقية تمتص العمل غير المخطط وحوادث الإنتاج وتعديلات النطاق.

إدارة التبعيات

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

تكتيكات لإدارة التبعيات:

لوحات التبعيات. حافظ على لوحة مشتركة (مادية أو رقمية) حيث تُتتبع كل تبعية بين الفرق مع مالك وحالة وتاريخ مستهدف.
مزامنات التبعيات المنتظمة. اجتماع وقوف أسبوعي لمدة 15 دقيقة حيث تُبرز الفرق العوائق وتُحدّث حالة التبعيات. هذا يلتقط المشاكل مبكراً عندما يكون حلها رخيصاً.
هندسة معمارية تقلل التبعيات. استثمر في APIs والأنظمة المدفوعة بالأحداث وتجريدات المنصة التي تسمح للفرق بالعمل بشكل مستقل. أفضل إدارة للتبعيات هي وجود تبعيات أقل.
تسلسل العمل لتقليل الحجب. عند التخطيط لربع سنة، حدد العناصر التي ستفتح الطريق لفرق أخرى وأعطها الأولوية مبكراً.

وضع OKR للهندسة

نشأت OKRs (الأهداف والنتائج الرئيسية) على يد آندي غروف في Intel وانتشرت على يد جون دوير في Google، وتوفر إطاراً لربط العمل الهندسي بنتائج الأعمال.

الهيكل واضح ومباشر:

الهدف: غاية نوعية وملهمة. مثال: "اجعل واجهة API الخاصة بنا الأسرع والأكثر موثوقية في الصناعة."
النتائج الرئيسية: 2-4 نتائج قابلة للقياس تشير إلى ما إذا كان الهدف يتحقق. مثال: "تقليل زمن استجابة API عند المئوي 99 من 800 مللي ثانية إلى 200 مللي ثانية" أو "تحقيق وقت تشغيل 99.95% لجميع نقاط النهاية من المستوى الأول."

الأخطاء الشائعة التي يرتكبها مديرو الهندسة مع OKRs:

نتائج رئيسية قائمة على المخرجات. "شحن طبقة التخزين المؤقت الجديدة" هو مُخرَج. "تقليل زمن استجابة قراءة قاعدة البيانات بنسبة 60%" هو نتيجة. النتائج الرئيسية القائمة على النتائج تسمح للفرق بإيجاد أفضل حل بدلاً من الارتباط بتنفيذ محدد مسبقاً.
OKRs كثيرة جداً. ثلاثة أهداف بثلاث نتائج رئيسية لكل منها يعني تسعة أهداف قابلة للقياس. هذا بالفعل عند الحد الأعلى. أكثر من ذلك يُشتت التركيز.
تحديد أهداف متحفظة. إذا تحققت كل نتيجة رئيسية بنسبة 100%، فالأهداف لم تكن طموحة بما يكفي. نظام OKR صحي يتوقع تحقيق 60-70% في الأهداف الطموحة.
لا مراجعات منتصف الدورة. OKRs التي تُوضع في بداية الربع وتُراجع فقط في نهايته ليست مفيدة لتصحيح المسار. أجرِ مراجعات في الأسبوعين 3 و6 لتقييم التقدم والتعديل.

عندما يطلب منك المُقابِل وضع OKRs لفريق افتراضي، أظهر الربط بين عمل الفريق والأولويات الاستراتيجية للشركة. أظهر أنك تفكر بمصطلحات النتائج، وليس المخرجات.

لقد أكملت الآن الدروس الأربعة في هذه الوحدة حول تصميم أنظمة القيادة. خُذ اختبار الوحدة لاختبار فهمك للتصميم التنظيمي وتخطيطات الفرق والعمليات الهندسية ومقاييس التسليم. :::