ارسم تدفق القيمة وزمن الانتظار

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

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

لا تبدأ بإضافة أداة جديدة. اسأل الفريق عن حدث البداية والنهاية: هل يبدأ القياس من طلب العمل، أم من التزام التغيير في مستودع الشيفرة؟ هذان مقياسان مختلفان. في هذا الدرس نقيس من قبول طلب تغيير روتيني إلى وصوله للإنتاج، بما في ذلك الانتظار قبل العمل. أما «زمن التغيير» في مقياس DORA فيبدأ من الالتزام إلى النشر؛ إذا قارنت الرقمين دون تسمية الحدين صنعت تعارضًا مصطنعًا. اكتب كذلك هل «اليوم» يوم تقويمي أم يوم عمل. في المثال التالي كل يوم انتظار يساوي ثماني ساعات عمل للمقارنة التعليمية؛ لا تحول الناتج إلى وعد زمني حقيقي قبل فحص العطل ونهاية الأسبوع.

| المرحلة | عمل مباشر | انتظار قبل العمل | سبب الانتظار المرصود | | --- | ---: | ---: | --- | | فرز الطلب | 0.5 ساعة | يومان | اجتماع فرز أسبوعي | | البناء والاختبار المحلي | 4 ساعات | يوم واحد | بدء العمل حسب سعة الفريق | | مراجعة التغيير | ساعة واحدة | أربعة أيام | طابور مراجعين اثنين | | إطلاق الإنتاج | 0.5 ساعة | يومان | نافذة إصدار مجمعة |

مجموع العمل المباشر 0.5 + 4 + 1 + 0.5 = 6 ساعات. مجموع الانتظار 2 + 1 + 4 + 2 = 9 أيام عمل، أي 72 ساعة على افتراض ثماني ساعات في اليوم. زمن العبور المشاهد في هذا التمثيل 78 ساعة عمل، أو 9.75 يوم عمل مكافئًا. **نسبة وقت العمل إلى زمن العبور** هي 6 ÷ 78 = 7.7% تقريبًا. هذه النسبة وصف لهذا المسار وتعريفه، وليست هدفًا عالميًا؛ قد يكون بعض الانتظار مشروعًا لإتاحة فحص مستقل أو توقيت آمن. لكنها توجه السؤال إلى الانتظار الطويل بدل مكافأة الفريق على خفض البناء من أربع ساعات إلى ثلاث.

يوجد دليل إضافي: يصل إلى طابور المراجعة 12 تغييرًا أسبوعيًا، بينما يستطيع المراجعون إكمال 10 مراجعات بالمستوى المطلوب. إن بقي الطلب والسعة ثابتين، يزيد المتبقي بمعدل تغييرين كل أسبوع. هذا لا يثبت أن كل تغيير ينتظر أربعة أيام بالضبط؛ ترتيب الأولويات وحجم التغييرات يغيران انتظار الفرد. لكنه يثبت أن الطابور لا يستقر من تلقاء نفسه. تسريع البناء وحده قد يجعل الوصول إلى المراجعة أبكر قليلًا، لكنه لا يرفع سعة المراجعة، فيتراكم العمل أمامها. لذلك نفرق بين **تأخير عابر** بسبب حادثة مؤقتة و**قيد سعة** حين يزيد الوارد باستمرار على المنجز.

قارن بديلين. البديل أ هو شراء أداة توليد تقلص وقت البناء ساعة لكل تغيير. إذا بقيت أوقات الانتظار كما هي، يهبط مجموع العمل إلى خمس ساعات وزمن العبور إلى 77 ساعة عمل؛ التحسن النظري في المسار ساعة واحدة، وتظل المراجعة تختنق. البديل ب تدريب مراجع مؤهل إضافي مع الاحتفاظ بمتطلبات الاختبار والفصل المناسب للأدوار، لترتفع سعة المراجعة التجريبية من 10 إلى 14 تغييرًا أسبوعيًا. حينها يمكن أن ينخفض المتبقي بمعدل تغييرين أسبوعيًا بعد استقبال 12 جديدًا، لكن زمن الانتظار الجديد ليس معلومًا قبل التجربة، وقد تنتقل العقدة إلى نافذة الإطلاق. اختر تجربة ب المحدودة أولًا، لأن الدليل يشير إلى طابور المراجعة، وراقب معها الأخطاء المعادة للمطورين وجودة المراجعة. لا تُلغِ فحصًا رقابيًا لازمًا لمجرد تحسين الزمن.

تجربة التحسين تحتاج تعريفًا دقيقًا. ابدأ بأربعة أسابيع من تغييرات روتينية متشابهة، وسجّل لكل تغيير أوقات الدخول والخروج من الفرز والبناء والمراجعة والإطلاق، وعدد مرات إعادته، ونوع الخطأ الذي اكتشفه المراجع، وهل سبب الإطلاق عطلًا يتطلب تدخلًا. بعد إضافة السعة، قارن توزيع زمن انتظار المراجعة لا المتوسط وحده؛ قد تتحسن الحالات السهلة فيما تنتظر الحالات المعقدة أطول. راقب وصول الطلب؛ إذا ارتفع من 12 إلى 16 أسبوعيًا فلن تكفي سعة 14 للاستقرار. احفظ حق الفريق في إيقاف تجربة توسع إن تدهورت جودة القرار أو تعذر الفصل بين مُنشئ التغيير ومراجعه حين يكون هذا الفصل قيدًا معتمدًا.

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