فن إنهاء ما تبدأه في عصر الفوضى الذكية Limit WIP

ما هو Limit WIP؟

تحديد العمل الجاري (Limit WIP) قاعدة تضع سقفًا لعدد المهام المسموح بوجودها في مرحلة واحدة من العمل في الوقت نفسه. لا يبدأ الفريق مهمة جديدة قبل أن تنتهي مهمة قائمة وتفسح لها المجال. و WIP اختصار لـ Work In Progress، أي العمل الذي بدأ ولم ينتهِ بعد.

الفكرة بسيطة حتى يكاد الناس يستخفون بها. تخيّل مطبخ مطعم فيه ثلاثة طهاة. لو دخل عشرون طلب دفعة واحدة وبدأ كل طاهٍ يحضّر من كل شيء قليلًا، ستخرج الأطباق باردة ومتأخرة. أما لو قرر المطبخ ألا يزيد ما هو قيد التحضير عن ست طلبات، فسيخرج كل طبق أسرع وأسخن. إن تحديد سقف العمل لم يُبطئ المطبخ، بل جعله يعمل بإيقاع يقدر عليه.

وفي لوحة كانبان يظهر الحد رقمًا فوق العمود، مثل "قيد التنفيذ (٣)". إذا امتلأ العمود، لا تُسحب إليه مهمة جديدة حتى تخرج واحدة منه.

من أين جاء Limit WIP؟

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

١- مصنع تويوتا: نظام السحب

في أعقاب الحرب العالمية الثانية وجدت تويوتا نفسها أمام موارد شحيحة ومخزون مكلف. ابتكر المهندس تايتشي أونو نظامًا قائمًا على السحب (Pull): لا تنتج محطة قطعة جديدة إلا حين تطلبها المحطة التالية. وكانت بطاقة كانبان (وهي كلمة يابانية تعني "لوحة إشارة") هي الإذن بالبدء. عدد البطاقات المتاحة هو الحد الأقصى للعمل الجاري. هذا هو Limit WIP في أقدم شكل له.

٢- قانون ليتل: الرياضيات تتكلم

في عام ١٩٦١ أثبت الأكاديمي جون ليتل من جامعة MIT علاقة رياضية بين عدد العناصر قيد المعالجة ومتوسط الوقت الذي يقضيه كل عنصر في النظام. وقد أعطى هذا القانون ممارسة المصنع أساسًا رياضيًا: حين تقلّ المهام المفتوحة في نظام مستقر، يقصر زمن الدورة. لم تعد القاعدة حدسًا بل قانونًا رياضيًا مثبتًا.

٣- أندرسون: من المصنع إلى فريق البرمجة

في أوائل القرن الحادي والعشرين طبّق ديفيد أندرسون هذه الأفكار على فرق البرمجة، وجمعها لاحقًا في كتابه "Kanban" الصادر عام ٢٠١٠. الانتقال لم يكن نسخًا حرفيًا. ففريق البرمجة لا يصنع قطعًا متماثلة، لكن المبدأ صمد: العمل غير المكتمل عبء يتراكم، والعلاج أن تحدّ ما تبدأ به لا أن تضاعف الجهد. ومن هنا صار Limit WIP إحدى الممارسات الأساسية في كانبان للمعرفة والتقنية.

لماذا ينجح Limit WIP؟

ينجح لأن زمن الدورة (الوقت من بدء المهمة حتى انتهائها) يتناسب مع عدد المهام المفتوحة، ولأن كل مهمة إضافية تسرق تركيز الفريق من المهام التي كان ينبغي أن تنتهي أولًا. هذان سببان منفصلان يعملان معًا.

السبب الأول: معادلة ليتل

لنفترض فريقًا يُنجز ٥ مهام في الأسبوع. إن كان لديه ٢٠ مهمة مفتوحة فمتوسط المهمة يحتاج ٤ أسابيع من البداية إلى النهاية. وإن خفض المفتوح إلى ١٠ مهام مع بقاء المعدل كما هو، نزل المتوسط إلى أسبوعين. لم نضغط أحدًا ولم نزد ساعة عمل. كل ما فعلناه أننا قلّلنا ما نبدأه في وقت واحد.

السبب الثاني: كلفة تبديل السياق

العقل لا ينتقل بين مهمة وأخرى بلا ثمن. المهندس جيرالد واينبرج قدّم قاعدة تقريبية شهيرة: من يعمل على مشروعين معًا يضيع نحو ٤٠% من وقته في التبديل بينهما، ومع ثلاثة يضيع نحو ٦٠%. هذه أرقام تقديرية و لكن النتيجة المؤكدة: كلما زادت المهام المفتوحة قل الناتج الفعلي.

ما الذي يتغير في الواقع؟

أهم ما في الجدول الصف الرابع. الحد لا يصلح المشكلات، لكنه يكشفها. حين يمتلئ عمود المراجعة وتتوقف المهام، نسأل السؤال الصحيح: لماذا توقفت هنا؟

كيف تطبّق Limit WIP خطوة بخطوة؟

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

1. ارسم تدفق العمل الحقيقي. لوحة بأعمدة تعكس ما يحدث: قائمة انتظار، تنفيذ، مراجعة، اختبار، تمّ. لا ترسم النظام المثالي الذي تتمناه.

2. قِس الوضع الحالي. عد المهام المفتوحة لدى كل عمود وكل عضو. أغلب الفرق تكتشف هنا أن الرقم أكبر بكثير من عدد الأشخاص.

3. اختر حدًا مبدئيًا. نقطة بداية شائعة: عدد أعضاء الفريق المشتغلين على هذا العمود، أو أقل منه بواحد. فريق من أربعة يبدأ بحد ٣ أو ٤ في عمود التنفيذ. هذه نقطة انطلاق وليست قانونًا.

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

5. عندما يمتلئ العمود، لا تسأل كيف نبدأ، بل أين يتوقف العمل؟ المبرمج المنتظر يراجع كود زميله بدل أن يفتح مهمة جديدة، ومن ينتظر من فريق الجودة يشارك في الاختبار بدلا من أن ينتظر.

6. راقب مؤشرين فقط: متوسط زمن الدورة (Cycle Time) وعدد ما أُنجز (Throughput) أسبوعيًا. إن تحسنا فالحد يعمل.

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

أخطاء تتكرر

أكثر ما يُفشل التطبيق هو حد يُكتب ثم يُتجاهل بـ"استثناء هذه المرة". استثناء واحد يعلّم الفريق أن الحد لا يعني شيئًا. وخطأ آخر هو القفز إلى حد ضيّق جدًا من اليوم الأول، فيكرهه الناس قبل أن يروا نتائجه.

لماذا Limit WIP أهم الآن في عصر الذكاء الاصطناعي؟

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

الكود رخيص، لكن القرار ما زال غاليًا

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

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

ماذا يحدث إذا لم تضع حدًا؟

• تكدّس في المراجعة. تنتج الأدوات طلبات دمج أسرع من قدرة الناس على قراءتها، فيتراكم العمل أمام مراجع واحد.

• مراجعة سطحية. حين تكثر الطلبات، يبدأ الناس بالموافقة السريعة لأن القائمة لا تنتهي. وهذا طريق مباشر إلى أخطاء تصل إلى الإنتاج ودين تقني ينمو.

• تشتت المبرمج. من يدير عشرة مسارات متوازية يتنقل بينها مثل من يتنقل بين عشرة مشاريع، وتعود كلفة تبديل السياق كما كانت.

• سرعة وهمية. كل شيء "قارب الانتهاء" ولا شيء منتهٍ فعلًا. اللوحة مليئة بما هو قيد التنفيذ، وعمود "تم" فارغ.

كيف تطبّق الحد في فريق يستخدم الذكاء الاصطناعي؟

1. ضع حدًا لعمود المراجعة قبل عمود التنفيذ. هذا العمود هو الاختناق الجديد. مثلاً: لا أكثر من طلبين مفتوحين لكل مراجع.

2. حدّد عدد المسارات المتوازية لكل شخص من الوكلاء أو المهام المساعدة. جرّب اثنين أو ثلاثة، ثم قرّر بالقياس لا بالحماس.

3. عرّف "تم" بأنه مدموج ومختبر ومفهوم، لا مجرد أن الكود يعمل على جهاز شخص واحد.

4. اسأل قبل كل مهمة جديدة: هل هذا أهم ما يمكن أن ننجزه الآن؟ فالقدرة على البدء سهلة، لكن القدرة على الاختيار هي المهارة النادرة.

الحد هنا لا يبطئ الذكاء الاصطناعي. هو يمنع أن تتحوّل سرعته إلى سرعة في صنع الفوضى.