كيف ترتّب أولويات الميزات حين يبدو كل شيء عاجلاً

بقلم فريق FabricLoop  ·  مايو 2026  ·  6 دقائق قراءة

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

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

ما ينجح فعلاً أبسط من ذلك: بُعدان يُقيَّمان بصدق، والانضباط في العمل بنتيجة التقييم.

البُعدان الوحيدان المهمان

ينحصر ترتيب الأولويات في سؤالين. الأول: إلى أي مدى يحسّن هذا النتيجة التي تهمنا؟ (الأثر.) والثاني: كم سيكلفنا تنفيذه؟ (الجهد.) وكل ما عدا ذلك إما تحسين لهذين البُعدين أو تشتيت عنهما.

يُضاف أحياناً بُعد ثالث هو درجة الثقة ("ما مدى تأكدنا من الأثر؟")، وهو جدير بالاعتبار. لكن معظم الفرق في الواقع تعرف متى تخمّن. والانضباط المطلوب هو أن تصنّف التخمين بصدق، لا أن تمنحه درجة على مقياس من 1 إلى 5 وتدخله في معادلة.

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

تقييم الأثر دون دقة زائفة

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

اطرح ثلاثة أسئلة عن كل ميزة قيد النظر:

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

تقييم الجهد دون التقليل من شأنه

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

تفيد ممارستان. أولاً، اسأل فريق الهندسة دائماً قبل تقدير الجهد لا بعده. فمديرو المنتجات الذين يقدّرون الجهد بمفردهم يقللون من تقديره تقريباً في كل مرة. ثانياً، استخدم مفهوم "المجهولات غير المعروفة" (unknown unknowns) كمضاعف صريح للجهد. فأي ميزة تمس جزءاً جديداً من الشيفرة البرمجية، أو واجهة برمجية خارجية، أو مسار مستخدم لم يُختبر مؤخراً، تستحق درجة جهد أعلى بمقدار 1.5 مرة مما يوحي به العمل الظاهر.

وهم الاستعجال

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

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

عندما تتعادل الخيارات في الشبكة

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