كان الباكولوج في السابق قائمة يسحب منها أنت وعدد قليل من زملائك. تقرأ البند الأول، تفهمه، ثم تنفّذه. كان الفرز سريعاً لأن السؤال الوحيد كان «من لديه وقت؟». أما الآن فأصبح بعض هذه البنود قابلاً للالتقاط بواسطة وكيل برمجي بدلاً من إنسان، فتحوّل الطابور الهادئ إلى مصدر لأخطاء صغيرة مكلفة: يبدأ وكيل العمل على مهمة لم يكمل أحد كتابتها، ويلتقط وكيلان عملاً متداخلاً، ويمتلئ عمود «منجز» بمخرجات لم يطلبها أحد.
المشكلة ليست في الوكلاء، بل في أن الباكولوج المصمم للبشر غيّر وظيفته بهدوء. فتوقف عن كونه قائمة مهام وأصبح طابور إرسال قادراً على إطلاق التنفيذ. وبمجرد أن يصبح بند واحد قادراً على تحريك عمل حقيقي، فإن لحظة نقل المهمة ولحظة تحديد من يملكها تحملان تبعات لم تكن موجودة من قبل.
هذه هي الطبقة التي تعمل فيها Sharkly. أنت تملك وكلاء برمجة بالفعل، وSharkly يحوّلهم إلى فريق بمنح الباكولوج معنى مشتركاً. المهمة (Task) هي وحدة العمل الأساسية، والباكولوج (Backlog) هو حيث ينتظر العمل غير المُلتزم به، والفرز (Triage) طابور استقبال مخصص تبقى فيه العناصر الواردة حتى يقرر أحدهم. تستعرض هذه المقالة كيفية فرز باكلوج مختلط من البشر والوكلاء دون أن يتحول هذان الطابوران إلى فوضى، وتنتهي بقائمة تحقق يمكنك تطبيقها اليوم.
ما الذي يعنيه الباكولوج والفرز عندما يصبح الوكلاء قادرين على تنفيذ العمل
هناك تعريفان يقوم عليهما معظم ما هنا، فاحرص على ضبطهما بدقة.
الباكولوج هو مجموعة العمل غير المُلتزم به: مهام موجودة لكن لم يقرر أحد البدء فيها بعد. والفرز هو قرار الاستقبال المتخذ بشأن العناصر الجديدة أو غير الواضحة: اقبله، ارفضه، ضع عليه علامة تكرار، أو أجّله إلى وقت لاحق. لطالما أدى البشر الاثنين بشكل غير رسمي. والتغيير هو أن نتيجة الفرز في فريق من البشر والوكلاء أصبحت تشمل «أي وكيل سينفّذ هذا؟»، كما أن الالتزام بالمهمة نفسه أصبح قادراً على إطلاق دورة تشغيل.
وهذا هو الحد الذي يربك الناس أولاً: إسناد وكيل إلى مهمة في الباكولوج لا يبدأ تشغيله. فالباكولوج منطقة انتظار يُجهَّز فيها العمل قبل التنفيذ. ولا تبدأ دورة التشغيل إلا عندما تخرج المهمة من الباكولوج إلى حالة جاهزة للعمل، ويتوفر حاسوب (Computer) وبيئة تشغيل (Runtime). لذا فإن «إسناد الوكيل» و«تشغيل الوكيل» حدثان منفصلان، وتقف حالة الباكولوج بينهما كبوابة.
وهناك حد آخر يستحق الذكر صراحةً: الوكلاء لا يحتفظون بباكولوج خاص بهم. فلا يوجد طابور خفي يعمل عليه الوكيل بمفرده. كل عنصر سيتعامل معه الوكيل موجود على اللوحة المشتركة، وهذا ما يجعل الفرز ممكناً بدلاً من التخمين.
أين يتوقف الإعداد اليدوي عن التوسّع
جدول بيانات مع لوحة كانبان وبضع نوافذ طرفية يكفي لشخص واحد ووكيلين. لكنه يتوقف عن التوسّع عند نقاط متوقعة، وكل نقطة منها تظهر في صورة فشل محدد.
عمود الحالة لا يعني شيئاً للوكلاء. ف على لوحة يدوية، نقل بطاقة إلى «قيد التنفيذ» مجرد ملاحظة لزملائك، ولا شيء يُنفَّذ. وهكذا تتباعد اللوحة عن العمل الفعلي: تقول البطاقة «قيد التنفيذ» بينما أنهى الوكيل المهمة منذ ساعة، أو «قائمة المهام» بينما الوكيل غارق في ثلاث commits لأن أحدهم أطلقه من الطرفية. لا أحد يثق باللوحة، فلا أحد يستخدمها.
قرارات الفرز تعيش في رأس شخص واحد. فمن يستقبل الطلبات الواردة يتذكر أن خطأً ما أُبلغ عنه سابقاً، وأن ميزة رُفضت في الربع الماضي، وأن مهمة تحتاج إلى مدخلات التصميم أولاً. وعندما يغيب ذلك الشخص، تُنشأ عناصر مكررة ويبدأ الوكلاء عملاً كان ينبغي رفضه عند الاستقبال. فالطابور بلا ذاكرة.
ويُحدَّد الإسناد والنطاق في اللحظة المتعجلة نفسها. النطاق الغامض أمر يمكن تحمّله عندما يلتقط إنسان مهمة ويسأل سؤالاً. أما الوكيل فلا يتوقف ليسأل، بل يعمل بما أعطيته إياه ويعود بنتيجة واثقة خاطئة. فقد انتقلت تكلفة الفرز السطحي من «ارتباك زميل للحظات» إلى «إحراق الوكيل دورة تشغيل ودورة مراجعة في الشيء الخطأ».
فرز باكلوج مختلط، خطوة بخطوة
هذا هو التسلسل الذي يبقي باكلوج البشر والوكلاء صادقاً. وكل خطوة تسمّي الفشل الذي تمنعه.
1. أفرغ طابور الاستقبال قبل أن تلمس الباكولوج. تصل الطلبات الجديدة إلى الفرز، لا إلى الباكولوج مباشرة. وتعامل مع كل عنصر بأحد أربعة قرارات: القبول، أو الرفض، أو وضع علامة تكرار، أو التأجيل. الفرز طابور استقبال، وليس مرشّحاً محفوظاً ولا أداة لبناء النماذج، لذا يكون القرار صريحاً ومسجّلاً. الفشل الذي يمنعه: أن يتحول العمل المرفوض والمكرر بهدوء إلى مهام حقيقية يلتقطها وكيل لاحقاً.
2. صُغ المهمة قبل أن تصبح مؤهلة للوكيل. العنصر المقبول يصبح مهمة (Task)، لكنه يبقى في الباكولوج بينما تكتب معايير القبول، وتربط المستودع، وتدوّن القيود. هذه هي الخطوة التي يتخطاها الناس تحت ضغط الوقت. الفشل الذي يمنعه: أن يعمل وكيل على عنوان من سطر واحد ويعود بمخرجات تطابق الكلمات حرفياً وتخطئ المقصود.
3. حدّد المسؤول، وتعامل مع سؤال «أي وكيل؟» كخيار حقيقي. بعض المهام تريد إنساناً. وبعضها يريد وكيلاً، وفيما بين الوكلاء يعتمد الوكيل المناسب على المهمة: فإعادة الهيكلة، وكتابة الاختبارات، وتحديث التوثيق ليست الوظيفة نفسها. وجّه المهمة عن قصد بدلاً من اللجوء تلقائياً إلى أي وكيل عاطل. ويشرح دليلنا لتوجيه مهام وكلاء البرمجة كيفية اتخاذ هذا القرار. الفشل الذي يمنعه: أن تستهلك بيئة التشغيل الخطأ مهمة لا تناسبها.
4. أبقِها في الباكولوج حتى تصبح جاهزة فعلاً. هذه هي البوابة. يمكن أن تكون المهمة مسندة بالكامل وتبقى في الباكولوج دون أن تبدأ أي دورة تشغيل. استفد من ذلك. ولا تُخرجها حتى يُضبط النطاق وتريد فعلاً أن يبدأ العمل. الفشل الذي يمنعه: أن تطلق مهمة نصف مكتوبة دورة تشغيل لأن أحدهم سحبها إلى العمود الخطأ.
5. التزم بها، ودع دورة التشغيل تبدأ. انقل المهمة إلى حالة جاهزة، أو اسحبها إلى سبرنت (Sprint). وعندما تخرج مهمة لها وكيل جاهز من الباكولوج ويتوفر حاسوب وبيئة تشغيل، يبدأ التنفيذ. الآن أصبح تغيير الحالة والعمل حدثاً واحداً، وهذا هو المغزى كله.
وللفرق التي تعمل بدورات، يوضح تخطيط السبرنت لفرق البشر والوكلاء كيف تحدد خطوة الالتزام نفسها إطاراً زمنياً بدلاً من مهمة واحدة.
حالة الباكولوج تتحول إلى بوابة تنفيذ
التحول الذهني هو هذا: على لوحة البشر، الحالة مجرد وصف للواقع. أما على لوحة البشر والوكلاء، فالحالة رافعة تغيّر الواقع. فنقل المهمة خارج الباكولوج هو الفعل الذي يشغّل الوكيل، لذا أصبح انتظامك في الفرز هو آلية الأمان لديك.
وعند هذه البوابة أيضاً يقع العقد بين البشر والوكلاء. الوكلاء يبحثون وينفذون ويختبرون ويقدّمون التقارير. أما البشر فيقررون ما يدخل الباكولوج، وما يُلتزم به، وما يُشحن. وتتوقف الأتمتة حيث يلزم حكم الفريق. وتُبقي واجهة الخطة (Plan) الباكولوج والسبرنتات والمشاريع في مكان واحد، فيصبح قرار الالتزام مرئياً بدلاً من أن يُدفن في طرفية، ويعود التنفيذ والعوائق والنتائج والمراجعة كلها إلى المهمة بدلاً من أن تتفرق في جلسات خاصة.
لهذا يصبح الحفاظ على نظافة الباكولوج أكثر أهمية مع الوكلاء، لا أقل. فالباكولوج البشري الفوضوي مجرد فوضى، أما الباكولوج الفوضوي مع الوكلاء فهو فوضى تشغّل نفسها أحياناً. وتُبقي اللوحة السياق والملكية والتقدم والنتائج والمراجعة البشرية مرئية من الاستقبال حتى الإصدار، وهذا هو الفرق بين طابور تديره وطابور يديرك. وعندما تتراكم المراجعة بدلاً من الاستقبال، فهذا عنق زجاجة مختلف، نتناوله في لماذا تُعدّ المراجعة البشرية القيد الحقيقي.
يمكنك إدارة هذا كله بجدول بيانات وانضباط يدوي إذا كان حجم العمل منخفضاً. أما إذا كنت تستقبل تدفقاً منتظماً وتشغّل عدة وكلاء، فـ Sharkly يمنحك طابور الفرز، وبوابة الباكولوج، ولوحة مشتركة واحدة، حتى تتوقف هذه القرارات عن السكن في رأسك. ولرؤية أوسع لسير العمل نفسه، اطّلع على دليلنا حول إدارة مهام وكلاء الذكاء الاصطناعي، وعلى الفرق بين الفرز وصندوق الوارد الشخصي.
قائمة تحقق للفرز يمكنك تطبيقها اليوم
طبّق هذه القائمة على لوحتك الحالية. كل «لا» هي موضع سيفاجئك فيه الوكلاء.
- هل تصل الطلبات الجديدة إلى مكان ما قبل الباكولوج؟ إذا كان الاستقبال يذهب مباشرة إلى «قائمة المهام»، فليس لديك خطوة قبول/رفض/تكرار، والتكرار حتمي.
- هل نطاق كل مهمة في الباكولوج جيد بما يكفي لتسليمها لشخص غريب؟ إن لم يكن جيداً بما يكفي لموظف جديد، فهو ليس جيداً بما يكفي لوكيل.
- هل يؤدي نقل المهمة فعلاً إلى بدء شيء؟ إذا كانت تغييرات الحالة مجرد أسماء، فستتباعد اللوحة عن العمل.
- هل الإسناد قرار حقيقي، بما في ذلك أي وكيل؟ اللجوء التلقائي إلى الوكيل العاطل ليس توجيهاً.
- هل يمكنك أن تقول الآن على ماذا يعمل كل وكيل وما الذي ينتظر المراجعة؟ إذا كان الجواب يعيش في ذاكرة أحدهم أو في سجل تمرير الطرفية، فالفرز بلا مصدر حقيقة مشترك.
- هل يعود العمل المنتهي إلى المهمة، لا إلى جلسة خاصة؟ النتائج والعوائق والفروقات (diffs) مكانها السجل المشترك حتى تجد المراجعة ما تتعامل معه.
أصلح أول بندين قبل أن توسّع عدد الوكلاء. فخطوة استقبال نظيفة ونطاق مهمة صادق يمنعان معظم حالات الفشل المكلفة، وما تبقى مجرد تحسينات فوق باكلوج أصبح له معنى بالفعل.
