منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مرداد ۱۴۰۵ · زمان مطالعه: حدود ۱۲ دقیقه

اولویت‌بندی ویژگی‌ها (Feature Prioritization) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

پنج چارچوبی که منبع معرفی می‌کند — RICE، اثر‌در‌برابر‌تلاش، کانو، MoSCoW و نقشهٔ داستان — همه یک کار می‌کنند: یک فهرست از ویژگی‌های نامزد را مرتب می‌کنند.

و هیچ‌کدام به گلوگاه واقعی کاری ندارد: خودِ آن فهرست از کجا آمد.

تعریف

اولویت‌بندی ویژگی‌ها تعیین می‌کند تیم‌ها ویژگی‌های محصول را با چه ترتیبی بسازند و منتشر کنند. کاری است که میان ارزش برای مشتری، اهداف کسب‌وکار و امکان‌پذیری فنی توازن برقرار می‌کند تا تیم بر اثرگذارترین ویژگی‌ها تمرکز کند.

و منبع نکتهٔ درستی دربارهٔ پیش‌شرطش می‌گوید: اولویت‌بندی موفق به چشم‌انداز مشترک و اهداف روشن شرکت نیاز دارد — چون همین چشم‌انداز مشترک است که به اعضای تیم اجازه می‌دهد شایستگی هر ویژگی را عینی‌تر بحث کنند و اثر سوگیری‌های شخصی کم شود.

فایده‌هایش

منبع چهارده فایده می‌شمارد. مهم‌ترین‌هایشان: بهبود تصمیم‌گیری و کاهش حدس‌زدن و اختلاف داخلی · رویکرد هدف‌اول و روشی تکرارپذیر برای همهٔ تیم · معیارهای قابل‌سنجش و ارتباط شفاف دربارهٔ چرایی هر اولویت · بهینه‌کردن منابع با تمرکز بر پروژه‌های کمتر و اثرگذارتر · تمرکز راهبردی · کاهش استرس مدیر محصول · رضایت کاربر و مشتری و راضی‌نگه‌داشتن تیم‌های فروش و پشتیبانی · رهبری مشارکتی · انطباق‌پذیری با بازنگری منظم اولویت‌ها · تکرار و انتشار سریع‌تر · و مدیریت دامنه و پرهیز از خزش ویژگی.

پنج چارچوب

• - RICE — امتیاز بر پایهٔ گستره (چند کاربر)، اثر، اطمینان از رسیدن به نتیجهٔ مطلوب، و تلاش لازم.
• - اثر در برابر تلاش — سنجش فایده در برابر تلاش پیاده‌سازی، برای یافتن بیشترین ارزش با کمترین هزینه.
• - مدل کانو — دسته‌بندی ویژگی‌ها به باید‌داشت، تقویت‌کنندهٔ عملکرد، و لذت‌بخش.
• - MoSCoW — چهار دستهٔ باید داشت، بهتر است داشت، می‌شود داشت، نخواهیم داشت.
• - نقشهٔ داستان — چیدن ویژگی‌ها در نقشهٔ داستان کاربر تا جای هرکدام در راهبرد کل محصول دیده شود.

و در بهترین‌روش‌ها سه چیز درست می‌گوید: چشم‌انداز واحد بسازید · رهبری مشارکتی با ذی‌نفعان دپارتمان‌های مختلف · و از دام‌های رایج بپرهیزید — تصمیم بر پایهٔ واکنش شهودی، بازگشت‌سرمایهٔ منفردِ یک ویژگی، یا بلندترین صدای اتاق. و اضافه می‌کند که درخواست‌های فروش و پشتیبانی را در نظر بگیرید ولی نگذارید تصمیم را قبضه کنند.

چارچوب‌ها فهرست را مرتب می‌کنند، فهرست را نمی‌سازند

این بخش افزودهٔ مترجم است. هر پنج چارچوب، مجموعهٔ نامزدها را مفروض می‌گیرند. اما تصمیم پرنفوذتر از قبل گرفته شده: وقتی کسی تعیین کرد چه چیزی وارد فهرست شود.

و مشکل این است که چارچوب این محدودیت را نامرئی می‌کند، چون خروجی‌اش یک عدد با ظاهر مطمئن است. امتیاز RICE نمی‌گوید «بهترین گزینهٔ ممکن»؛ می‌گوید «بهترینِ آنچه پیشنهاد شد».

پس پرسشی که بیشتر از یک دور امتیاز‌دهی ارزش دارد این است: چه چیزی در این فهرست نیست؟ و غیبت‌ها تصادفی نیستند؛ سه‌تایشان نظام‌مندند:

• - درست‌کردن، چون ویژگی نیست. رفع بدهی فنی و بهبود پایداری قهرمان ندارد، پس پیشنهاد‌دهنده هم ندارد.
• - حذف‌کردن. هیچ‌کس فرم «درخواست حذف ویژگی» پر نمی‌کند، در حالی که حذف اغلب ارزان‌ترین بهبود تجربه است.
• - و هر چیزی که پشتیبانی و عملیات می‌خواهند. این‌ها درخواست ویژگی نمی‌نویسند — تیکت می‌نویسند. و تیکت هرگز به فهرست نامزدها راه پیدا نمی‌کند.

و درمانش رویه‌ای است، نه نیت: پیش از هر دور امتیاز‌دهی، یک بار فهرست را از سه منبعِ بی‌قهرمان پر کنید — پرتکرارترین موضوع تیکت‌های ماه، فهرست بدهی فنی، و چیزهایی که می‌شود حذف کرد. اگر این سه هرگز در فهرست نامزدها نیستند، امتیاز‌دهی شما فقط بین خواسته‌های صاحبان قدرت داوری می‌کند.

«اطمینان» همان جایی است که امتیاز ساخته می‌شود

این بخش هم افزودهٔ مترجم است. در RICE، سه ورودی از چهار ورودی کم‌و‌بیش قابل بحث با دادهٔ بیرونی‌اند. ورودی چهارم — اطمینان — درصدی است که پیشنهاد‌دهنده به ایدهٔ خودش می‌دهد. و ضرب می‌شود.

یعنی کسی که این ویژگی را می‌خواهد، مقیاس امتیاز را در دست دارد.

و یک نامتقارنی بدتر هم هست: تلاش را کسانی برآورد می‌کنند که باید کار را انجام دهند — و آن‌ها معمولاً صادق و بدبین‌اند. اثر و اطمینان را کسانی برآورد می‌کنند که ویژگی را می‌خواهند — و آن‌ها خوش‌بین‌اند. نتیجه:

RICE نظام‌مند به‌نفع ویژگی‌هایی کار می‌کند که قهرمانشان مطمئن‌تر است — و این با «ارزشمندتر» یکی نیست.

دو اصلاح ساده جلوی این را می‌گیرد:

• - اطمینان را کسِ دیگری تعیین کند، نه پیشنهاد‌دهنده.
• - یا بهتر: اطمینان را با یک پرسش دو‌گزینه‌ای عوض کنید — «آیا این فرض را آزمون کرده‌ایم؟ بله/نه». و اگر «نه» بود، آن ویژگی به صف آزمون می‌رود، نه به بک‌لاگ. این کار یک اسم مشترک هم به فرض‌های نیازموده می‌دهد، که بحث دربارهٔ آن‌ها را ممکن می‌کند.

و یک آزمون کلی‌تر که به‌نظرم دربارهٔ هر چارچوبی صادق است: منبع «کاهش استرس» را جزو فایده‌ها می‌آورد، و همین نکته هشدار است — چارچوب‌ها محبوب‌اند چون حس تصمیم می‌دهند و سندی تولید می‌کنند که بحث را تمام می‌کند. پس بپرسید: آیا چارچوب ما هیچ‌وقت جوابی داده که ارشدترین فرد اتاق خوشش نیامده؟ اگر نه، آن چارچوب رویهٔ تصمیم نیست — رویهٔ تصویب است.

«باید‌داشت» و تاریخ انقضای کانو

این بخش هم افزودهٔ مترجم است و دو قید مشخص به دو چارچوب می‌زند.

MoSCoW: «باید داشت» فقط وقتی معنا دارد که تعریفش این باشد — بدون این منتشر نمی‌کنیم. و در عمل همه‌چیز «باید» می‌شود، چون «باید» یک نشان مقام است. دو اصلاح:

• - تعداد یا بودجهٔ «باید»ها را پیش از رأی‌گیری سقف بگذارید. کمیابی همان چیزی است که این دسته را آگاهی‌بخش می‌کند؛ بی سقف، دسته‌بندی اطلاعاتی حمل نمی‌کند.
• - و آزمونش یک جمله است: «اگر این باید است، بگو چه چیزی را برای جا‌دادنش حذف می‌کنیم.»

کانو: منبع دسته‌ها را طوری می‌آورد که گویی پایدارند. اما پویایی مرکزی خودِ این مدل این است که لذت‌بخش به تقویت‌کنندهٔ عملکرد و بعد به باید‌داشت تبدیل می‌شود. پس:

• - یک مطالعهٔ کانو تاریخ انقضا دارد. اجرایش کنید، تاریخش را رویش بنویسید، و پیش از هر تصمیم بزرگ نقشهٔ راه دوباره اجرایش کنید.
• - و یک‌بار‌اجرا‌کردن و به‌دیوار‌زدنش از نداشتنش بدتر است، چون یک عکس منقضی‌شده را به سند دائمی تبدیل می‌کند.

در بافت فارسی: ریسکی که چارچوب‌ها خانه‌ای برایش ندارند

این بخش هم افزودهٔ مترجم است و سه نکته دارد.

یک: ویژگی‌ای که به یک سرویس بیرونی وابسته است، عدد تلاش دارد به‌علاوهٔ یک احتمال ناممکن‌شدن — درگاه پرداخت، سرویس پیامک، نقشه، فروشگاه اپ، سرویس ابری. و RICE هیچ جمله‌ای برای «ممکن است از ما گرفته شود» ندارد.

دو راه عملی: یک جملهٔ پنجم به‌نام ریسک وابستگی اضافه کنید (تقسیم امتیاز بر احتمال دوام آن وابستگی)؛ یا ساده‌تر و مؤثرتر: دو ویژگیِ وابسته‌به‌بیرون را در یک فصل زمان‌بندی نکنید. این کار ریسک را از «برآورد» به «برنامه» منتقل می‌کند، که دقیق‌تر است.

دو: «گستره» اینجا اشتباه سنجیده می‌شود. ویژگی‌ای که ۸۰٪ حساب‌ها را پوشش می‌دهد ممکن است فقط ۴۰٪ نشست‌هایی را پوشش بدهد که واقعاً می‌توانند اجرایش کنند — گوشی قدیمی، مرورگر قدیمی، اینترنت کند. پس گستره را روی جمعیتی بسنجید که توان استفاده دارد، نه جمعیتی که حساب دارد.

سه: «بلندترین صدای اتاق» که منبع هشدارش را می‌دهد، اینجا معمولاً یک نام مشخص دارد: مشتری سازمانی بزرگ — چون تمرکز درآمد بالاتر است و رفتن یک مشتری واقعاً خطرناک است. پس «نگذارید فروش تصمیم را قبضه کند» مسئلهٔ انضباط نیست؛ مسئلهٔ ساختار است.

و پاسخ صادقانه‌اش این است: به آن مشتری یک بودجهٔ نام‌دار بدهید — مثلاً ۲۰٪ ظرفیت هر فصل — به‌جای اینکه تظاهر کنید درخواست‌هایش در RICE با بقیه رقابت می‌کنند. نام‌گذاری بودجه، یک بحث بی‌پایان را به یک مسئلهٔ حساب‌داری تبدیل می‌کند.

و همین راه‌حل برای آن غیبت اول هم کار می‌کند: یک سهم ثابت و نام‌دار از ظرفیت برای پایداری و بدهی فنی، که یک‌بار تصمیم گرفته می‌شود و هر اسپرینت از نو بحث نمی‌شود. چون چیزی که قهرمان ندارد، در هیچ رأی‌گیری‌ای برنده نمی‌شود.

جمع‌بندی

• - اولویت‌بندی ویژگی‌ها ترتیب ساخت و انتشار را تعیین می‌کند و میان ارزش مشتری و اهداف کسب‌وکار و امکان‌پذیری فنی توازن می‌سازد؛ چارچوب‌هایش RICE، اثر‌در‌برابر‌تلاش، کانو، MoSCoW و نقشهٔ داستان‌اند.
• - اما هر پنج چارچوب فهرست نامزدها را مفروض می‌گیرند؛ پرسش باارزش‌تر این است که چه چیزی در فهرست نیست — و سه غیبت نظام‌مند است: درست‌کردن، حذف‌کردن، و هر چیزی که پشتیبانی می‌خواهد (چون تیکت می‌نویسد نه درخواست ویژگی).
• - در RICE، «اطمینان» درصدی است که پیشنهاد‌دهنده به ایدهٔ خودش می‌دهد و ضرب می‌شود؛ و تلاش را بدبین‌ها برآورد می‌کنند و اثر را خوش‌بین‌ها. پس به‌نفع مطمئن‌ترین قهرمان کار می‌کند، نه ارزشمندترین ویژگی.
• - اصلاحش: اطمینان را کس دیگری بدهد، یا با «آیا این فرض را آزمون کرده‌ایم؟» عوضش کنید — و «نه» به صف آزمون می‌رود نه بک‌لاگ.
• - و آزمون هر چارچوبی: آیا هیچ‌وقت جوابی داده که ارشدترین فرد اتاق خوشش نیامده؟ اگر نه، رویهٔ تصویب است نه تصمیم.
• - «باید‌داشت» بی‌سقف اطلاعاتی حمل نمی‌کند؛ سقف بگذارید و بپرسید «چه چیزی را برای جا‌دادنش حذف می‌کنیم». و مطالعهٔ کانو تاریخ انقضا دارد، چون لذت‌بخش به باید‌داشت تبدیل می‌شود.
• - و در بافت ما: برای وابستگی بیرونی یک جملهٔ ریسک وابستگی اضافه کنید یا دو ویژگیِ وابسته را هم‌فصل نکنید · گستره را روی نشست‌های توانمند بسنجید نه حساب‌ها · و به مشتری بزرگ و به پایداری، هر دو، بودجهٔ نام‌دار بدهید.