كيف تختار بين RICE وWSJF وICE وMoSCoW

الاجتماع الذي يفوز فيه أعلى صوت

لديك 22 بندًا مفتوحًا ومتسع يكفي لستة. يقول أحدهم "العملاء يطلبون هذا باستمرار" بقناعة صادقة، ولا أحد يملك رقمًا يردّ به، فيُطلق البند بعد أسبوعين ليستفيد منه 40 شخصًا تقريبًا.

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

الجواب المختصر: RICE حين تملك بيانات استخدام وتكون القائمة كلها عمل منتج. WSJF حين تضم عملًا في البنية التحتية أو الامتثال أو المخاطر. ICE حين لا تملك بيانات ولا ساعة من الوقت. MoSCoW حين يكون الجمهور عميلًا يحتاج التزامًا واضحًا بالنطاق.

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

الأطر الأربعة، وما يطلبه كل واحد منك

الإطار	المعادلة	ما يجب أن تعرفه	مقياس المخرجات
‏RICE	(Reach x Impact x Confidence) / Effort	عدد المستفيدين في الفترة	بلا سقف، وعامل الوصول يهيمن عليه
‏WSJF	Cost of Delay / Job Size	كم يكلّفك أسبوع من الانتظار	محدود، من 1 إلى 40 تقريبًا
‏ICE	Impact x Confidence x Ease	لا شيء. ثلاثة آراء	من 1 إلى 1000
‏MoSCoW	لا معادلة. أربع سلال	ما الذي يجعل الإصدار بلا معنى	أربع تسميات

خطآن في التعريف يسبّبان معظم الضرر. قيمة Impact في RICE ليست درجة من 1 إلى 10، بل مُعامل من خمس قيم ثابتة: 3 هائل، 2 عالٍ، 1 متوسط، 0.5 منخفض، 0.25 ضئيل. أما Confidence فنسبة مئوية، وEffort يُقاس بشهور العمل الفردية (person-months)، وفق مقال Sean McBride الأصلي على مدونة Intercom. استخدم مقياس 1 إلى 10 بدل ذلك، وتصبح كل أرقامك خاطئة بمقدار رتبة كاملة.

أما تكلفة التأخير في WSJF فهي مجموع ثلاث درجات نسبية: قيمة العمل، والحساسية للوقت، وخفض المخاطر. وهي وحجم العمل يستخدمان مقياس فيبوناتشي المعدّل 1، 2، 3، 5، 8، 13، 20، ويُثبَّت المرجع بإعطاء أصغر بند معروف الدرجة 1.

ويحمل MoSCoW قاعدة لا يكاد أحد يطبّقها. دليل DSDM يحدّ سلة Must بما لا يتجاوز 60% من جهد التسليم، ويُبقي نحو 20% في سلة Could احتياطيًا. وMust اختصار Minimum Usable SubseT: من دونه لا معنى للنشر في موعده.

البنود الاثنا عشر نفسها، محسوبة بأربعة أطر

الوصول هنا عدد المستخدمين في الربع، والجهد بشهور العمل، والمرتبة بين قوسين. وICE هو Impact في Confidence في Ease، كل منها من 1 إلى 10. وWSJF هو قيمة العمل زائد الحساسية للوقت زائد خفض المخاطر، مقسومًا على حجم العمل، والكل بفيبوناتشي.

المهمة	R	I	C	E	RICE	ICE	WSJF	MoSCoW
‏WEB-14 أخطاء 500 عند الدفع	900	3	100%	0.5	5400[1]	810[1]	41.0[1]	Must
‏WEB-19 التحرير الجماعي	2400	1	80%	1.0	1920[2]	336[4]	6.5[4]	Should
‏WEB-27 الوضع الداكن	3000	0.25	100%	0.5	1500[3]	270[5]	4.0[7]	Could
‏WEB-52 التنقّل على الجوال	1800	0.5	80%	0.5	1440[4]	360[3]	7.0[3]	Should
‏WEB-35 بريد الملخص الدوري	1500	0.5	80%	1.0	600[5]	224[6]	3.5[9]	Could
‏WEB-44 التهيئة الأولى	2000	0.5	50%	1.5	333[6]	150[11]	2.7[11]	Could
‏WEB-23 الوضع دون اتصال	400	2	50%	2.0	200[7]	175[9]	4.2[6]	Should
‏WEB-41 حدّ معدل استدعاء API	40	3	100%	1.0	120[8]	420[2]	10.5[2]	Must
‏WEB-31 الاستيراد من Trello	180	2	50%	2.0	90[9]	180[8]	3.7[8]	Won't
‏WEB-12 الدخول الموحّد SSO	120	2	80%	3.0	64[10]	196[7]	3.2[10]	Must
‏WEB-47 روابط مخطط جانت	300	1	50%	4.0	38[11]	50[12]	1.1[12]	Won't
‏WEB-38 تصدير سجل التدقيق	60	1	80%	1.5	32[12]	160[10]	5.3[5]	Should

لا يتّسع الجدول إلا لمدخلات RICE، فإليك صفّين كاملين: خطأ الدفع هو ICE‏ 9 في 10 في 9، وWSJF‏ (13 + 20 + 8) / 1. وتصدير سجل التدقيق هو ICE‏ 4 في 8 في 5، وWSJF‏ (5 + 3 + 8) / 3، أي قيمة قليلة، وبلا استعجال، وأعلى خفض للمخاطر في القائمة كلها. وعمود MoSCoW يلتزم بقاعدة 60% أيضًا: سلة Must تساوي 4.5 من أصل 12.5 شهر عمل في النطاق، وسلة Could تساوي 24%.

بند واحد فقط، وهو خطأ الدفع، يأتي أولًا في الدرجات الرقمية الثلاث. بعده تفترق النتائج، وليس افتراقًا عشوائيًا. يعطي ICE وWSJF الأربعة الأوائل أنفسهم وبالترتيب نفسه، ويشاركهما RICE في ثلاثة منها لكنه يرتّبها ترتيبًا آخر. معامل ارتباط سبيرمان 0.80 بين ICE وWSJF، و0.48 بين RICE وWSJF.

وشذوذ RICE سببه ميكانيكي. فهو يضرب في قيمة وصول خام بلا سقف، فيتفوق بند يخدم 3000 مستخدم على بند يخدم 40 مستخدمًا بهذا الحدّ وحده، بينما يضع ICE وWSJF سقفًا لكل مدخل. كما أن RICE بلا حدّ للمخاطر أصلًا، في حين يحمل WSJF خفض المخاطر في بسطه.

يأتي حدّ معدل استدعاء API الثاني في ICE وWSJF، والثامن في RICE. ويأتي تصدير سجل التدقيق الخامس في WSJF، والأخير تمامًا في RICE، بفارق سبع مراتب. فإذا كان باكلوجك يضم عمل منصة أو أمان أو عملًا لعميل واحد بعينه، فإن RICE يدفنه وWSJF يُظهره. دع هذا يحسم اختيارك قبل أي اعتبار آخر في هذا المقال.

كيف تختار

flowchart TD
  A["Who reads the output"] -->|"a client or an exec"| M["MoSCoW"]
  A -->|"the build team"| B["Do you have reach data"]
  B -->|"no"| I["ICE"]
  B -->|"yes"| C["Infra or compliance work"]
  C -->|"yes"| W["WSJF"]
  C -->|"no"| R["RICE"]

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

وحجم الفريق أقل أهمية مما يُقال. خمسة أشخاص يستطيعون تشغيل RICE. ما لا يستطيعونه هو إبقاء ثلاثين تقديرًا لتكلفة التأخير محدّثة كل ربع، ولهذا ينهار WSJF تحت عشرين مهندسًا تقريبًا.

أين ينكسر كل واحد منها

ينكسر RICE عند عمود الثقة. فهو المدخل الوحيد الذي يستطيع أي شخص تحريكه بلا تبرير، فيصير هو معامل التحايل، ويحصل المشروع الذي يريده أحدهم مسبقًا على 80% بدل 50%.

وينكسر WSJF لأن أحدًا لا يعرف تكلفة التأخير لديه. ‏Don Reinertsen، الذي صاغ النموذج في كتابه The Principles of Product Development Flow، قدّر نسبة مديري المنتجات العاجزين عن ذكر تكلفة التأخير عندهم بنحو 85%، وقدّر تشتّت التقديرات الحدسية بنسبة خمسين إلى واحد. فإذا لم تستطع قول ما يكلّفك أسبوع إضافي من غياب هذه الميزة، فأنت تحسب شعورًا بعلامة قسمة.

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

أما ICE، وهو نموذج Sean Ellis لتجارب النمو، فيتشبّع من الطرف الآخر. السهولة تتوقف عند 10، فما إن يصير الفريق سريعًا في كل شيء حتى يتحول ICE إلى حاصل ضرب Impact في Confidence. وينكسر MoSCoW في اللحظة التي لا يفرض فيها أحد قاعدة 60%: يضع كل شخص علامة Must على بنده، فتنتهي عند 95% من الجهد في سلة Must، ولا تكون التسميات قد قالت لك شيئًا.

هل ما زال عمود الجهد يعني شيئًا؟

الادّعاء الرائج أن وكلاء الذكاء الاصطناعي جعلوا تقديرات الجهد بلا قيمة. جرّبه على الجدول أعلاه، ولن يصمد في معظمه.

التسريع المتساوي لا يراه RICE أصلًا. اقسم كل تقديرات الجهد على العدد نفسه، فتُضرب كل الدرجات فيه، ويبقى الترتيب كما هو. تسريع ثابت بمقدار 2x عبر الصفوف الاثني عشر غيّر صفر مرتبة.

والمكاسب المقيسة لا تحرّك شيئًا يُذكر أيضًا. يذكر Yegor Denisov-Blanch من مجموعة إنتاجية هندسة البرمجيات في Stanford، استنادًا إلى بيانات نحو 100,000 مهندس، مكسبًا يراوح بين 30% و35% في العمل الجديد منخفض التعقيد، وبين 0% و10% في العمل القائم عالي التعقيد. طبّق هذين الرقمين حسب الفئة، فتتحرك 4 بنود من 12 مرتبةً واحدة، وليس فيها بند من السبعة الأوائل.

عدم الاتساق هو ما يزعزع الترتيب فعلًا. وجد استطلاع METR في مايو 2026 أن وسيط التغير المُبلَّغ ذاتيًا في السرعة هو 3x، مقابل نتائج مقيسة بلغت 18% للمطورين العائدين و4% للجدد، وكلا المجالين يتقاطع مع الصفر، وكلاهما أرجح أن يكون حدًا أدنى بالنظر إلى من انسحب من الدراسة. طبّق التسريع المعتقَد 3x على صفوف العمل الجديد وحدها، فيتحرك 10 بنود من 12. الخطر ليس أن يزداد الوكلاء سرعة، بل أن يطبّق فريق واحد معتقداته على الفئات بلا اتساق.

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

أين مكان الدرجة في أداة التتبع

مكان هذه المدخلات هو المهمة نفسها، وإلا انتهت في جدول بيانات يتقادم خلال ثلاثة أسابيع. في Taskfolk يعني ذلك الحقول المخصصة: عشرة أنواع منها الرقم والقائمة المنسدلة. أربعة حقول رقمية لـ RICE، وثلاثة زائد حقل للحجم لـ WSJF، وحقل اختيار واحد لـ MoSCoW، وحقل أخير للدرجة نفسها.

لا شيء يملأ ذلك الحقل الأخير نيابةً عنك. وما إن تصير له قيم حتى يحصل الحقل الرقمي على فلتر مدى بحدّين أدنى وأقصى، في لوحة الفلترة في عرضَي القائمة واللوحة، مُسلسلًا في الرابط بصيغة ?cf.<fieldId>=n:40.. لـ 40 فأكثر، إضافة إلى ?cols=<fieldId> لإظهار العمود. وتقرأ اللوحة والباكلوج والقائمة والجدول الزمني والتقويم المعاملات نفسها، فيضع رابط واحد الجميع على المقطع نفسه من البيانات. وكيف تفلتر المهام وترتّبها يغطي الباقي.

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

الحل العملي هو إسقاط الدرجة على حقل الأولوية المدمج، فهو يقبل الترتيب ويبقى داخل العرض المحفوظ. والدرجة ليست مرتبة على أي حال: ترتيب الباكلوج قرار بشري يستطيع تجاوز أي رقم. والأهداف والنتائج الرئيسية (OKR) المبنية على العمل الحقيقي يغطي الشق المتعلق بالأهداف.

كتابة الدرجة إلى الأداة، وما لا نجيده

نداء واحد لكل مهمة ولكل حقل، والاستجابة تعيد صدى القيمة التي وصلت.

BASE="https://taskfolk.ai/api/v1/workspaces/acme"
curl -X PUT "$BASE/projects/WEB/issues/WEB-41/custom-fields/$FIELD_ID" \
  -H "Authorization: Bearer tfk_live_a1b2..." \
  -H "Content-Type: application/json" \
  -d '{"value": 10.5}'

{ "data": { "field_id": "e2b1...", "value": 10.5 } }

القراءة هي النصف المزعج. كائن المهمة لا يحمل قيم الحقول المخصصة، ونقطة النهاية التي تسرد المهام لا تقبل معامل ترتيب ولا فلتر حقل مخصص، فتصير إعادة الحساب الكاملة هكذا: اسرد المهام، ثم GET لكل واحدة، ثم احسب، ثم PUT لكل واحدة. مقبول كل ربع، لا كل ساعة.

سلّم هذه الحلقة إلى وكيل متصل، لكن حدّد نطاق المفتاح بدل اللجوء إلى سياسة الحقول لكل وكيل، فتلك السياسة تحكم 14 حقلًا مدمجًا في المهمة وليس فيها حقل مخصص واحد. مفتاح بنطاقات issues:read وcustom_fields:read وcustom_fields:write يفي بالغرض. وكيف تستخدم REST API يغطي المفاتيح والنطاقات.

أمران نؤديهما بشكل سيئ. مسار API للحقول المخصصة لا يكتب صفًا في سجل النشاط، فالدرجة التي يكتبها سكربت لا تترك أثرًا في تاريخ المهمة، بينما التعديل نفسه من الواجهة يتركه. ولا وجود لحقل معادلات أصلًا، في حين يشحن Jira Product Discovery حقلًا تربطه الفرق بـ RICE، ويدعم حقل ClickUp دوال IF وDAYS وROUND.

الأداة	حقل المعادلات	السعر، تحقّقنا منه في 27 يوليو 2026
‏Jira Product Discovery	نعم	‏$0 لثلاثة منشئين، ثم $10 أو $25 لكل منشئ
‏ClickUp	نعم	‏$0، ثم $7 أو $12 لكل مستخدم بفوترة سنوية
‏Linear	لا حقول مخصصة إطلاقًا	‏$0، ثم $10 أو $16 لكل مستخدم بفوترة سنوية
‏Taskfolk	لا	‏$0، ثم $3 أو $6 لكل منفّذ

فإذا كان الحقل المحسوب داخل الأداة هو الأهم عندك، فإن Jira Product Discovery هو الشراء الأفضل. ما تحصل عليه هنا مقعد أرخص، وAPI حقيقي لكتابة الدرجة، ووكلاء لا يُحتسبون مقاعد أبدًا.

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