اگر شما مدیر محصول کسب و کاری هستید که از متدولوژیها Agile یا چابک برای توسعه محصول استفاده میکنید، احتمالا گاهی در مورد اینکه کدوم User Story ها یا نیازمندیهای مشتریان باید وارد Release Backlog بشن و در Sprint پیش رو قرار بگیرن دچار مشکل شدید، این انتخاب به شدت حائز اهمیت هست چرا که تصمیم شما به راحتی میتونه آوردهی بیشتر و یا کمتری رو برای کسب و کارتون حاصل کنه. به همین دلیل آشنایی با متدولوژیهای اولویت بندی بک لاگ محصول یک امر ضروری برای مدیران محصول تمامی شرکتهاست.
برای طبقه بندی و اولویت بندی بک لاگ محصول متدولوژیهای مختلفی وجود داره که تو این نوشته قصد دارم یکی از روشهای پرطرفدار و مهمش بنام روش MOSCOW رو معرفی کنم.
روش اولویت بندی MOSCOW
یک روش اولویت بندی نیازهای مشتریان که در زمینههای مختلفی برای اجماع نظر بین ذینفعان یک کسب و کار و یا در مورد اولویت بندی بک لاگ تیم توسعه محصول سازمان مورد استفاده قرار میگیره. طبق این روش ما 4 دسته نیازمندی یا اولویت بنام Could،Should،Must و Would خواهیم داشت که اسم این روش مخففی از این 4 دسته هست و ترتیب اولویت اونها و تعریفشون به صورت زیر هست:
اولویتهای از نوع Must: اولویتها یا در واقع در مورد این نوشته User story هایی که برای مشتری ضروری هستند و بدون اونها محصول فاقد استفاده هست و اهداف کسب وکار تأمین نخواهد شد، و اگر حتی یکی از این دسته اولویتها در انتشار محصول در نظر گرفته نشن، انتشار یا لانچ محصول با شکست همراه خواهد بود. به طور مثال در اپلیکیشنهای تاکسی یاب آنلاین مثل اسنپ، امکان مشاهده مشخصات راننده یک فیچر ضروری هست که بدون اون امنیت سفر و کسب وکار زیر سؤال میره و فعالیت این قبیل کسب وکارها موفقت آمیز نخواهد بود.
اولویتهای از نوع Should: نیازمندیهایی که مهم هستند اما ضروری نیستند و موفقیت انتشار محصول وابسته به اونها نیست اما بهتره که هرچه زودتر در محصول لحاظ بشن. برای تشخیص راحتتر این دسته اولویتها از اولویتهای Must میتونید اندازه بگیرید که این اولویت تا چه اندازه ارزش و هدف اولیه کسب و کار رو فراهم میکنه و یا چه تعداد از مشتریان از این فیچر تأثیر خواهند پذیرفت. به طور مثال امکان مشاهده موقعیت در لحظه راننده روی نقشه در اپلیکیشن اسنپ و یا مشخص کردن مدت زمان رسیدن راننده در این اپلیکیشن از User Story های نوع Should هست.
اولویتهای از نوع Could: اولویتها یا نیازهایی از مشتری که مطلوب و پسندیده هستند و یا بهتره محصول داشته باشه اما الزام آور و اجباری نیستند. مثلا با در نظر گرفتن اپلیکیشن اسنپ میتونیم ببینیم که امکان اضافه کردن مکانهای منتخب از نوع اولویتهایی هست که بهتره در این اپلیکیشن باشه اما الزامی نیست و در طبقه بندی اولویتهای از نوع Could قرار میگیره.
اولویتهای از نوع Would: نیازها یا User Story هایی از مشتری که در پایینترین درجه اهمیت قرار دارند و اهداف محصول و کسب و کار رو تأمین نمیکنن، این دسته میتونه به راحتی نادیده گرفته بشه و یا در Release های آینده لحاظ بشن. مثلا امکان مشاهده گردش حساب در اپلیکیشن اسنپ از این قبیل اولویتهاست.
این متدولوژی یک روش سریع و ساده رو برای اولویت بندی نیازهای مشتریان در اختیار شما قرار میده که بین تیمهای توسعه محصول چابک در دنیا محبوب هست، اما روشهای دیگهای هم برای اولویت بندی نیازهای مشتریان وجود داره که یک مدیر محصول بایستی به تمامی اونها اشراف داشته باشه و با در نظر گرفتن همه این روشها بک لاگ محصول رو طبقهبندی کنه. در نوشتههای بعد روشهای دیگر رو خواهم گفت.