# مهلة تنفيذ التغيير (Lead Time for Changes)

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

- **المجال:** تقنية المعلومات (IT Operations)
- **الوحدة:** يوم
- **تكرار القياس:** شهري
- **الاتجاه المرغوب:** أقل أفضل
- **النوع:** تابع (Lagging)
- **الرابط:** https://kpihub.co/k/it-lead-time-changes

## الهدف

قياس سرعة تحوّل القرار إلى واقع، فهو المؤشر الذي يترجم رشاقة التقنية إلى لغة تفهمها الأعمال.

## لماذا هو مهم

- المسافة بين طلب الأعمال وظهوره هي ما يقيسه العميل الداخلي، لا عدد المهام المنجزة
- المهلة الطويلة تدفع الأقسام إلى حلول جانبية خارج التقنية
- يكشف أن الاختناق غالبًا في الانتظار لا في الكتابة: الكود يُكتب في يوم وينتظر أسبوعين

## المعادلة

```
Lead Time for Changes = Σ (Deployed at − Committed at) ÷ Changes
```

فكّكه إلى مراحل: مراجعة الكود والاختبار والاعتماد والنشر. الإجمالي لا يقول أين يضيع الوقت، وأغلبه في أغلب الفرق يقع في انتظار مراجعة لا في عمل.

## مثال محسوب

‏214 تغييرًا في الشهر بمجموع 1,712 يومًا من الاعتماد إلى الإنتاج. الحساب: 1,712 ÷ 214 = 8 أيام، منها 4.6 انتظارًا لمراجعة الكود.

## النطاق الاسترشادي

أقلّ من يوم في الفرق الناضجة، وأقلّ من أسبوع وضع جيد. وفوق شهر يعني عملية اعتماد تحتاج إعادة تصميم لا مزيدًا من المطوّرين.

## تحليل الاتجاه

- طول مرحلة المراجعة يعالَج بحدود حجم للتغيير لا بمزيد من المراجعين
- ارتفاعها مع نموّ الفريق نمط معروف: التنسيق ينمو أسرع من الإنتاجية
- انخفاضها مع ارتفاع فشل التغيير يعني تخطّي خطوات لا تحسين عملية

## أسئلة تشخيصية

- أين تقضي التغييرات أطول وقت؟ الجواب يوجّه كل الإصلاح
- ما متوسط حجم التغيير؟ التغييرات الكبيرة تنتظر أطول دائمًا
- كم اعتمادًا بشريًّا لكل تغيير؟ وهل يتناسب مع مخاطرته؟

## نصائح عملية

- ضع حدًّا لحجم التغيير الواحد، فهو أسرع طريق لتقصير المراجعة
- اربط عدد الاعتمادات بمخاطرة التغيير لا بحجمه
- قِس المراحل لا الإجمالي، فالإجمالي لا يوجّه أي قرار

## العرض المناسب

- شلال المراحل من الاعتماد إلى الإنتاج
- مبعثر: حجم التغيير أفقيًّا والمهلة رأسيًّا
- توزيع المهل لكشف الذيل الطويل

## تحذيرات وفخاخ

- قياس الإجمالي وحده يجعل الإصلاح عشوائيًّا
- تقصيرها بتخطّي المراجعة يرفع فشل التغيير والحوادث معًا
- معالجتها بتوظيف مطوّرين بينما الاختناق في الانتظار لا في الكتابة

## أثر التغيير

- خفض انتظار المراجعة من 4.6 يوم إلى يوم يقصّر المهلة الكلّية من 8 أيام إلى 4.4
- أربعة أيام أقلّ تعني أن طلب الأعمال يظهر في الأسبوع نفسه لا في الذي يليه
- حدّ حجم التغيير يعالج غالبًا أكبر مرحلة بقرار واحد بلا أدوات جديدة

## احسبه في أداتك

### Excel

```excel
=AVERAGE(Chg[Deployed] - Chg[Committed])
```

### Power BI (DAX)

```dax
Lead Time For Changes =
AVERAGEX (
    'Change',
    DATEDIFF ( 'Change'[CommittedAt], 'Change'[DeployedAt], DAY )
)
```

### Tableau

```
AVG( DATEDIFF('day', [Committed At], [Deployed At]) )
```

### SQL

```sql
SELECT product,
       AVG(deployed_at::date - committed_at::date) AS lead_days,
       AVG(review_wait_days)                       AS review_days,
       AVG(change_size_lines)                      AS avg_change_size
FROM   code_change
WHERE  deployed_at BETWEEN :from_date AND :to_date
GROUP  BY product
ORDER  BY lead_days DESC;
```

---

المصدر: [KPIHub](https://kpihub.co/k/it-lead-time-changes) · مرجع عربي مجاني لمؤشرات الأداء.