شاید از اولین سوالاتی که به ذهن هر مالک محصول برسد این است که چگونه بک لاگ محصول را اولویت بندی کنم؟

مطمئنا هر محصول با محصول دیگر، مشتری و ذی نفعان هر پروژه و محصول با مشتریان و ذی نفعان دیگر محصول متفاوت و در روند تصمیم گیری بسیار تاثیرگذار خواهد بود. اول بذارید یه تعریفی از محصول داشته باشیم.

محصول چیست؟

بذارید در قدم اول به سراغ دیکشنری کمبریج بریم، که میگه “محصول چیزیست که آماده شده برای فروش”. خب از این تعریف احتمالا به یه بخش کوچکی از منظور ما در تعریف محصول می‌رسیم. مایک کوهن در این مورد میگه محصول چیزیست که از دل یک پیشرفت تدریجی ومداوم بیاید و ارزشی را برای بازار (خواهان آن محصول) ایجاد نماید. یک محصول باید از نظر عملکردی بتواند آنچه را که قرار بوده است انجام دهد، با کیفیت خوب انجام دهد.

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

بک لاگ محصول (product backlog) چیه؟

بذارید بریم سراغ مرجع اصلی یعنی scrum.org، جایی که بک لاگ محصول رو اینجور تعریف می‌کنه، “Product Backlog یک لیست مرتب و آشکار از مواردی است که برای بهبود و یا تولید یک محصول مورد نیاز است. این تنها منبع ارجاع کار به تیم اسکرام است.” و یا از دید مایک کوهن لیست اولویت‌بندی شده از تمامی فیچرهای یک محصول با توضیح مختصری از نوع عملکرد آن‌ها. مسئول مستقیم تدوین و به روزرسانی این لیست مالک محصول است، اما در اکثر تیم‌ها، تیم توسعه نیز برای بدست آوردن آیتم‌های بک‌لاگ محصول به کمک مالک محصول خواهند آمد.
معمولا بک لاگ محصول شامل موارد زیر خواهد بود:

  • – امکانات و قابلیت‌ها
  • – اشکالات (باگ‌ها)
  • – کار فنی
  • – کسب دانش

اصولا، یک تیم اسکرام و مالک محصول، کار خود را با نوشتن هر آنچه فکر می‌کنند برای اولویت‌بندی نیاز است، شروع می‌کنند. این عقب ماندگی محصول چابک تقریباً همیشه برای دو سرعت اول کافی است. پس از آن اطلاعات بیشتری در مورد محصول و مشتریان آن ارائه می شود ، می توان به عقب مانده محصول Scrum رشد و تغییر داد.

اشتباهاتی که در بک لاگ محصول اتفاق میافته چیه؟

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

  • – آیتم‌های بک‌لاگ محصول برای توصیف تغییرات در نظر گرفته شده در محصول ضروری هستن اما کافی نه. شناخت کامل از محصول از طریق مکالمه‌ی که درباره تک تک آیتم‌های موجود در بک لاگ محصول وجود و اطلاعات تکمیلی پیرامون آن‌ها از درون تیم حاصل می شه.
  • – برخلاف سند نیازمندی‌ها، وجود آیتم‌‌ها در بک‌لاگ محصول نشانگر اجباری بودن آن‌ها در تحویل آن به مشتری نیست.
  • – باز هم بر خلاف سند نیازمندی‌ها که از یک نقطه‌ای به بعد مبنا قرار میگیره و انتظار هیچ تغییری در اون نیست، بک لاگ محصول با شناخت بیشتر محصول تکامل پیدا می‌کنه.

چه مسائلی در تهیه بک لاگ محصول تاثیرگذاره؟

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

  • – اهداف تجاری‌سازی
    آیا این قابلیت‌ها به تجاری‌سازی منجر میشه؟ آیا مشتریان جدیدی به ما اضافه میشن؟ آیا مشتری با این آیتم وفادار خواهد موند؟
  • – کاهش ریسک پروژه
    آیا این قابلیت ریسک رو کاهش میده؟ از جایگاهمون در بازار دفاع می‌کنه؟ آیا به عنوان روند جاری بازار به حساب میاد؟
  • – ملاحظات مالی
    آیا این فیچرها کمک مالی بهمون میکنه؟ آیا باعث ذخیره زمان یا هزینه انجام میشه؟ آیا بهره‌وری را بالا می‌بره؟
  • – توجه به منابع در دسترس
    آیا این فیچرها به منابعی که در حال حاضر داریمشون و شاید در آینده نداشته باشیمشون نیاز داره؟
  • – رضایت ذی‌نفعان
    آیا این قابلیت‌ها ذی‌نفعان پروژه رو راضی خواهد کرد؟

نکاتی برای اولویت‌بندی بک‌لاگ، یا به قولی چطور بک‌لاگمون رو اولویت‌بندی کنیم؟

تا اینجای کار کمی از تعاریف و اشتباهات گفتیم، حالا یه سر بزنیم به SBOK 3rd Edition که ۵ روش گفته برای اولویت‌بندی. البته که میدونیم که اسامی مختلفی استفاده میشه برای این روش‌ها و حتی روش‌های بسیار خوب و باحال دیگه هم وجود داره که اگر دوست داشتید در کامنت‌های این پست بگید برامون.

۱- طرح ساده (Simple Scheme)
در این روش ساده اولویت‌بندی با لیبل زدن به آیتم‌ها انجام میشه. بصورتی که به هر آیتم یه عدد مثلا بین ۱ تا ۳ میدید یا از لیبل‌های “high”، “medium” و “law” استفاده می‌کنیم. با اینکه این روش بسیار سادست ولی اصولا با مشکل مواجه میشه، به دلیل اینکه اصولا این تمایل وجود داره که تمام آیتم‌ها اولویت “۱” و یا “high” دارند.

۲- اولویت‌بندی MoSCoW
خب این روش چیه؟! آیا ربطی به مسکو داره؟ از روسیه اومده؟
نه نه اشتباه نکنید. این روش اسمش رو از ابتدای عبارت‌های “,Must have,” “Should have” “Could have” و “Won’t have” گرفته شده است. این روش نسبت به روش ساده کاربردی‌تره و اولویت‌بندی بهتر در بک‌لاگمون خواهیم داشت.
آیتم‌ها بین Must have به معنی آیتم‌هایی که کاملا ضروری هستند و Won’t have به معنی اینکه آیتم‌هایی که بودنشون خوبه ولی هیچ ضرورتی ندارند اولویت‌بندی میشن.

۳- پول مونوپولی (Monopoly Money)
خب در این روش افراد تیم به اندازه بودجه‌ی پروژه پول دستشون هست و ازشون خواسته میشه با دقت این پول رو تقسیم کنن بین یوزراستوری‌ها (User Story) موجود. در این روش افراد به بر اساس چیزی که می‌خوان بابت پول بیشتری پرداخت کنن، اولویت‌بندی رو انجام میدن.

۴- متد صد امتیازی (100-Point Method)
خب این روش رو Dean Leffingwell و Don Widrig سال ۲۰۰۳ ایجاد کردن. در این روش افراد ۱۰۰ امتیاز در دست دارن و به هر آیتم یه امتیازی براساس اهمیتشون نسبت میدن.

۵- تحلیل کانو (Kano Analysis)
خب یکی از معروف‌ترین و قدیمی‌ترین روش‌های اولویت‌بندی روش کانو هست که توسط Noriaki Kano در سال ۱۹۸۴ ایجاد شد و آیتم‌ها در چهار دسته مختلف کلاس‌بندی میشن:
الف: برانگیزاننده/خوشحال‌کننده: آیتمی که کاملا جدیدست و ارزش بالایی برای مشتری ایجاد میکنه و مشتری بسیار از داشتنش خوشحال و هیجان‌زده میشه.
ب: راضی‌کننده‌ها: آیتمی که ارزشی خوبی برای محصول ایجاد می‌کنه و مشتری رو راضی نگه میداره.
ج: ناراضی‌کننده‌ها: آیتم‌هایی که در صورت نبودنشون مشتری ناراضی خواهد بود. یعنی در واقع مشتری انتظار داشته این آیتم‌های حداقلی در محصولمون وجود داشته باشه.
د: بی تفاوت: آیتمی که به هیچ وجه تاثیری روی کاربر یا مشتری محصول نداره و میشه حذفش کرد.

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