وقتی backlog بزرگ است، اولویت‌بندی محصول چگونه از حدس جدا می‌شود؟

چرا backlog بزرگ الزاماً نشانهٔ سلامت محصول نیست؟

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

واقعیت: داشتن درخواست‌های زیاد طبیعی است. تحلیل: نگه‌داشتن همهٔ درخواست‌ها با یک اولویت و یک سطح تعهد، تصمیم‌گیری را مبهم می‌کند. پیشنهاد: backlog را از انبار ایده به ورودی تصمیم تبدیل کنید و برای هر مورد، وضعیت مشخص داشته باشید: مسئلهٔ تأییدنشده، نیازمند شواهد، آمادهٔ آزمایش، آمادهٔ ساخت، در حال اجرا یا عمداً متوقف‌شده.

اولویت‌بندی با رأی‌گیری چه تفاوتی دارد؟

رأی‌گیری برای کشف نگرانی‌ها مفید است، اما جای تصمیم محصول را نمی‌گیرد. مشتری ممکن است یک feature خاص را بخواهد چون آن را راه‌حل آشنای مسئله‌اش می‌داند. تیم فروش ممکن است یک قابلیت را فوری بداند چون در یک مذاکرهٔ فعال مطرح شده است. تیم فنی هم ممکن است کاری را جلو بیندازد چون از نظر اجرا جذاب یا کم‌ریسک است. هر سه سیگنال مهم‌اند، اما هیچ‌کدام به‌تنهایی نشان نمی‌دهند چه چیزی بیشترین ارزش را ایجاد می‌کند.

اولویت‌بندی یعنی این سیگنال‌ها را در یک تصمیم قابل توضیح کنار هم بگذاریم. سؤال «چند نفر این را خواسته‌اند؟» باید به سؤال‌های دقیق‌تری تبدیل شود:

• این درخواست به کدام مسئلهٔ تکرارشونده وصل است؟
• چه کسی و در چه مرحله‌ای از مسیر کاربر با آن مسئله روبه‌رو می‌شود؟
• اگر فعلاً آن را نسازیم، چه چیزی از دست می‌رود؟
• چه شاهدی داریم و چه چیزی هنوز فقط فرض است؟
• این کار چه گزینه‌های دیگری را از ظرفیت تیم خارج می‌کند؟

درخواست را چگونه به مسئلهٔ قابل تصمیم تبدیل کنیم؟

برای هر درخواست، قبل از نوشتن راه‌حل، یک کارت مسئلهٔ کوتاه بسازید. این کارت نباید به سند سنگین تبدیل شود. پنج خط کافی است:

این تبدیل جلوی یک اشتباه رایج را می‌گیرد: مقایسهٔ یک feature با یک مسئله. «افزودن داشبورد» و «کاهش ناتوانی کاربر در فهم وضعیت کارش» هم‌سطح نیستند. اولی راه‌حل است؛ دومی مسئله‌ای است که می‌توان با راه‌های مختلف بررسی کرد.

• کاربر و موقعیت: چه کسی، چه زمانی و در چه شرایطی با مشکل روبه‌رو است؟
• مسئله: اکنون چه چیزی سخت، کند، پرخطا یا غیرممکن است؟
• اثر: اگر مسئله حل شود، چه رفتار یا نتیجه‌ای باید تغییر کند؟
• شواهد و اطمینان: این مسئله را از کجا می‌دانیم و کدام بخش هنوز حدس است؟
• راه‌حل‌های ممکن: کوچک‌ترین آزمایش یا چند گزینهٔ واقعی چیست؟

اثر، ریسک و هزینهٔ فرصت را چگونه کنار هم ببینیم؟

یک روش ساده این است که هر گزینه را در چهار بُعد مرور کنیم: اثر احتمالی، اطمینان به مسئله، هزینه و ریسک. می‌توان برای شروع به هر بُعد نمرهٔ یک تا پنج داد، اما این نمره‌ها حقیقت علمی نیستند؛ فقط گفت‌وگو را منظم می‌کنند. اگر تیم دربارهٔ نمرهٔ اثر اختلاف دارد، احتمالاً هنوز مسئله یا شواهد به‌اندازهٔ کافی روشن نیست.

هزینه فقط زمان توسعه نیست؛ پشتیبانی، پیچیدگی معماری، داده، نگه‌داری و مسیر بازگشت را هم شامل می‌شود. هزینهٔ فرصت یعنی کاری که به خاطر انتخاب فعلی انجام نمی‌شود. تصمیم خوب لزوماً بیشترین امتیاز ظاهری را انتخاب نمی‌کند؛ trade-off را آشکار می‌کند.

برای هر گزینه این جمله را کامل کنید: «اگر این را انتخاب کنیم، در عوض از چه چیزی فعلاً صرف‌نظر می‌کنیم و چه زمانی تصمیم را دوباره بررسی می‌کنیم؟» اگر پاسخ وجود ندارد، اولویت هنوز کامل نشده است.

در یک مثال فرضی، کدام درخواست باید جلو بیفتد؟

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

در چارچوب مسئله، ابتدا می‌پرسیم هر مورد چه مشکلی را حل می‌کند. اگر شواهد نشان دهد کاربران پیش از رسیدن به ارزش اصلی در onboarding متوقف می‌شوند، ساده‌کردن همان مسیر ممکن است از یک قابلیت جدید مهم‌تر باشد؛ اما هنوز باید با یک آزمایش کوچک بررسی شود. اگر خروجی داده فقط برای یک درخواست خاص لازم باشد، شاید راه‌حل موقت یا دستی هزینهٔ کمتری داشته باشد. اگر دستیار هوشمند مسئلهٔ روشنی ندارد، جذابیت آن دلیل کافی برای ساخت نیست.

این مثال فرضی است و نتیجهٔ واقعی ادعا نمی‌کند. نکته، ترتیب سؤال‌هاست: اول مسئله و شواهد؛ بعد اثر و ریسک؛ سپس کوچک‌ترین اقدام قابل‌آزمایش.

چک‌لیست ۱۴روزهٔ جداکردن اولویت از حدس چیست؟

برای یک backlog مهم، این ریتم دو هفته‌ای می‌تواند نقطهٔ شروع باشد:

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

• روزهای ۱ و ۲: درخواست‌ها را جمع کنید، موارد تکراری را یکی کنید و راه‌حل را از متن مسئله جدا کنید.
• روزهای ۳ و ۴: کاربر، موقعیت، اثر و شواهد هر مسئله را بنویسید؛ موارد بدون مالک یا بدون مسئله را علامت بزنید.
• روزهای ۵ و ۶: گزینه‌های کوچک‌تر را کنار راه‌حل اصلی بگذارید و هزینه، ریسک، وابستگی و هزینهٔ فرصت را مرور کنید.
• روز ۷: با تیم محصول، فنی و افراد نزدیک به کاربر یک تصمیم موقت بگیرید: آزمایش، ساخت، تعویق یا حذف.
• روزهای ۸ تا ۱۲: کوچک‌ترین prototype، مصاحبه، نمونهٔ دستی یا تست فنی را اجرا کنید و نتیجه، ابهام باقی‌مانده و اثر بر roadmap را ثبت کنید.
• روزهای ۱۳ و ۱۴: یک مورد را وارد تعهد اجرایی کنید، چند مورد را با دلیل نگه دارید و موارد کم‌ارزش را از مسیر اصلی خارج کنید.

چه چیزهایی را عمداً در backlog نگه نداریم؟

ایده‌هایی که مسئلهٔ مشخص، صاحب تصمیم یا زمان بازبینی ندارند، نباید برای همیشه در صف اصلی بمانند. آن‌ها را در یک پارکینگ ایده با تاریخ بازبینی نگه دارید تا «شاید روزی» با «تعهد این چرخه» قاطی نشود. اگر یک feature به مسئلهٔ بزرگ‌تری وصل است، همان مسئله را مرجع قرار دهید تا هر راه‌حل دوباره صف نگیرد. برای دیدن رابطهٔ بین مسئله، دامنهٔ MVP و آزمایش، مقالهٔ از مسئله تا MVP؛ مسیر ساخت اپلیکیشن را قبل از کدنویسی ببندیم نقطهٔ شروع مناسب‌تری است. برای فهم نقش تصمیم‌گیری و همکاری بین‌تیمی نیز از Scrum Master تا Product Lead؛ چه چیزی در نوع تصمیم‌گیری عوض می‌شود؟ ادامهٔ این بحث است.

جمع‌بندی عملی برای فردا

فردا یک مورد مهم backlog را بردارید و فقط این پنج خط را برایش بنویسید: مسئله، کاربر، شواهد، گزینهٔ کوچک‌تر و هزینهٔ فرصت. اگر تیم هنوز نمی‌تواند دربارهٔ این پنج مورد توافق کند، زمان ساخت نرسیده است؛ زمان discovery یا یک آزمایش محدود رسیده است.

اولویت‌بندی خوب قول نمی‌دهد که همهٔ تصمیم‌ها درست از آب درمی‌آیند. قول می‌دهد تصمیم‌ها قابل توضیح، قابل بازبینی و متناسب با شواهد باشند. برای بنیان‌گذار، این یعنی سرمایه و تمرکز تیم روی مسئلهٔ روشن‌تری خرج می‌شود. برای Product Manager، یعنی roadmap از فهرست فشارها به مجموعه‌ای از انتخاب‌های آگاهانه تبدیل می‌شود. MVP هم از یک نسخهٔ کوچک اما تصادفی، به کوچک‌ترین تجربهٔ کامل برای یادگیری تبدیل می‌شود.