در پروژه‌های توسعه محصول به شیوه چابک، هدف به واحدهای جداگانه‌ای تقسیم می‌شود که داستان کاربری نامیده می‌شوند و ویژگی‌های ارزشمندی را به کاربر ارائه می‌نمایند. اما بهترین راه برای برنامه‌ریزی فرآیندهای توسعه محصول و تدوین انتشارهای محصول مبتنی بر ساختارهای شکست داستان‌های کاربری چیست؟. تکنیک “برش کیک چندلایه‌ای” رویکردی است که به مدیران محصول کمک می‌کند تا بتوانند ویژگی‌های کلیدی محصول خود را در انتشارهای مختلف تقسیم‌بندی کرده و فرآیند مدیریت و توسعه محصول خود را تسریع و بهینه نمایند. در این مقاله قصد دارم، شرحی مختصر از آنچه در مورد این تکنیک مطالعه کردم را به اشتراک بگذارم. با آکادمی محصول همراه باشید.
ساختار شکست کارها به داستان‌های کاربر به شیوه‌ای صحیح، از کارهای سختی است که اغلب مدیران محصول با آن درگیر خواهند بود و فقط با تمرین زیاد و تجربه بر آن مسلط خواهند شد. خبر خوب این است که تعدادی تکنیک وجود دارد که می‌توانید از آنها استفاده کنید تا شانس ایجاد داستان‌های کاربردی و ارزشمند را افزایش دهید. یکی از این تکنیک‌ها، در نظر گرفتن محصول به عنوان یک کیک چندلایه‌ای است.
محصول به عنوان کیک چند لایه
یکی از محبوب‌ترین رویکردهای ایجاد داستان‌های کاربر در مراحل مختلف مدیریت محصول در نظر گرفتن دامنه انجام کار و ارزش کار قابل ارائه به کاربر می‌باشد. از اینرو داستان کاربر در فرمت “به عنوان یک {نقش کاربر} می‌خواهم {هدف داستان کاربری} به طوری که بتوانم {نتیجه داستان کاربری} ” شروع خوبی است، اما ایده زیادی در مورد نحوه‌ی تقسیم کارها به به قطعات کوچک، ارزشمند و کاربردی که قابل تست باشند و به روند بلوغ محصول کمک کنند و همچنین از انعطاف‌پذیری کافی در صورت بروز تغییرات برخوردار باشند، را در اختیار ما قرار نمی‌دهد. اینجا دقیقا همان جایی است که باید از تکنیک‌های برش محصول استفاده کرد. موضوع این مقاله نیز بر روی یکی از این تکنیک‌ها یعنی، تکنیک “کیک چند لایه‌ای” تمرکز کرده است.
این ایده اولین بار توسط بیل ویک (Bill Wake) در سال ۲۰۰۳ ارائه شد. طبق این ایده:
“یک محصول را باید به عنوان یک کیک چند لایه‌ای در نظر گرفت. به عنوان مثال یک لایه شبکه، یک لایه منطقی و یک لایه ارائه (presentation) و … در نظر بگیرید. هنگامی که یک داستان کاربری را تقسیم می‌کنیم، ما فقط بخشی از آن کیک را سرو می‌کنیم. ما می‌خواهیم که تمام کیک را به مشتری بدهیم ولی بهترین راه این است که کیک را به صورت عمود بر لایه‌ها برش بزنیم. توسعه‌دهندگان اغلب تمایل دارند تا در یک زمان تنها بر روی یک لایه کار کنند (و آن را توسعه دهند.)، اما به عنوان مثال، یک لایه کامل از بانک اطلاعاتی که در زیرساخت توسعه داده شده باشد، برای مشتری، بدون حضور یک لایه قابل مشاهده و بصری از قابلیت محصول، ارزشی نخواهد داشت.”
طراحی داستان کاربری اثربخش
پیش از بررسی این تکنیک، باید از اثربخش بودن داستان‌های کاربری مطمئن شد چون یک داستان کاربری اثربخش که به درستی طراحی شده باشد، یکی از پیش نیازهای اصلی اثربخشی تکنیک “کیک چندلایه‌ای” می‌باشد.
پیچیدگی محصول با وجود داستان‌های کاربری طولانی
در مثال زیر، نمونه‌ای از یک داستان کاربری را نشان می‌دهم که به شرح یک قابلیت جدید در یک وب سایت فروش بلیط سفر می‌پردازد.
“به عنوان یک کاربر از سایت سفر XYX، می خواهم لیست پروازهای بین دو شهر انتخاب شده را با توجه به قیمت کل، مالیات بر ارزش افزوده مشاهده کنم، به طوری که بتوانم گزینه ای را انتخاب کنم که برایم بهترین باشد.”
به نظر کار می رسد تحقق این یوزر استوری کار ساده باشد. یک لیست با اطلاعاتی که باید در UI یک وب سایت برای کاربر به نمایش گذاشته شود. این نمونه یوزر استوری هست که به ارزشمندی تاکید بیش از اندازه ای داشته و قابل برش زدن نیست. در صورتیکه می بایست به گونه ای قابل تقسیم، قابل تخمین زمانی و تست‌پذیر نوشته و طراحی شود که بتواند در روال توسعه ای تیم محصول قرار گیرد.
یوزر استوری فوق ساختار درستی ندارد زیرا ما صرفا با تولید یکسری اطلاعات و نمایش آن در سایت مواجه نیستیم، بلکه با لایه‌های مختلفی از یک سیستم و گاهی تعامل بین سیستم های چندگانه (تعامل بین وب سرویس‌های مختلف) مواجه خواهیم بود.
کار بسیار بزرگتر از آن چیزی است که به نظر میرسد و زمانی که توسط یک مدیر محصول بی تجربه نیز در روند توسعه قرار گیرد، می تواند پیچیدگی کار و تلاش توسعه‌ای مورد نیاز را در طول اسپرینت افزایش دهد. در نهایت داستان کاربری شما به صورت ناامیدکننده ای، داستان‌های کاربری دیگر را یا متوقف کرده یا Pend نگه می‌دارد و علاوه بر افزایش ریسک های توسعه کسبوکار و محصول، عدم رضایتمندی کاربران را نیز افزایش میدهد.
بنابراین باید بدانیم که وقتی داستان‌های کاربری بزرگ و غیرمنطقی باشند، تمایل تیم به تمرکز بر روی جنبه‌های فنی بیشتر از تاکید بر روی دیگر لایه‌های مختلف معماری محصول خواهد بود که صحیح نیست.
اهمیت طراحی داستان کاربری اثربخش
برای ایجاد داستان‌های کاربری اثربخش، می‌بایست مفاهیم تئوریک را با تجربه و اقدامات اجرایی ترکیب نمایید تا نتیجه مناسب بگیرید. به طور مثال، عناصر داستان کاربری اثربخش، عبارتند از: مستقل بودن، قابلیت تقسیم، ارزشمند بودن، قابل تخمین و پیش‌بینی‌پذیر، کوچک و تست‌پذیر باشد. اما باید بدانیم داستان‌های کاربری در باور مدیریت محصول بسیار ایده‌آل است اما در عمل واقعا ممکن است، این اتفاق رخ ندهد.
به طور مثال، نمونه‌های زیادی وجود دارند که در آنها به ارزشمند بودن داستان کاربری بیش از سایر عناصر توجه بیش از اندازه شده است و خب البته این منطقی هست که هر داستان کاربری باید ارزش اثربخشی را برای ارائه به محصول در برداشته باشد. اما این دیدگاه اگر غیر منعطف و افراطی باشد همه چیز خراب خواهد شد. باید بین عناصر داستان کاربری، توازن مناسبی برقرار باشد.
به طور مثال، در سیستم‌های چندگانه (به ویژه در معماری‌های مبتنی بر میکروسرویس) باید بدانیم داستان‌های کاربری که تمرکز بیش از اندازه‌ای بر روی ارزشمندی دارند و سایر عناصر مربوطه در آن کمرنگ هستند، به داستان‌های کاربری بسیار طولانی و پیچیده تبدیل خواهند شد. در صورتیکه داستان کاربری باید به گونه‌ای طراحی شود که به ویژه در معماری‌های لایه‌ای محصول، قابل برش زدن باشد به طوریکه بتوان به صورت منطقی نسخه‌های مختلف انتشار مختلف محصول را شناسایی نمود.
در واقع، داستان کاربری باید قابل تقسیم، مبتنی بر زمان و قابل تست باشد تا بتواند در جریان کاری تیم توسعه قرار گیرد در غیر این‌صورت به یک کابوس برای تیم فنی و کل کسبوکار تبدیل می‌شود و علاوه‌براین موجب به تعویق افتادن انتشار محصول و ایجاد بحران‌های روانی و انگیزشی تیم و افزایش ریسک‌های سرمایه‌گذاری می‌گردد.
بنابراین، یکی از اهداف مهم تکنیک “کیک چندلایه‌ای”، ممانعت از تأکید بیش از حد بر ارزش داستان کاربری و نادیده گرفتن سایر عناصر کلیدی یک داستان اثربخش است. استفاده از این تکنیک روند دریافت سریع بازخورد کاربران و عرضه محصول به بازار در زمان مناسب را تسهیل خواهد بخشید. در واقع، کارها باید به واحدهایی مشخص مبتنی بر اندازه سطح پیچیدگی‌شان تقسیم و تنظیم شوند تا بتوان از ساده‌ترین کار شروع کرد و به تدریج با پیچیدگی‌های محصول رو به رو شد و بر اساس بازخوردهای منظم، روند توسعه و بهبود محصول را پیشبرد.
انواع روش های برش محصول: برش عمودی در مقابل برش افقی
بر اساس این تکنیک، برش کیک می‌تواند به صورت عمودی و افقی باشد که هر یک را در ادامه بررسی می‌کنیم.
برش افقی داستان های کاربری در فرآیند توسعه محصول
در اولین تلاش برای توسعه محصول، بسیاری از تیم‌های فنی سعی می‌کنند بر روی یک لایه از معماری محصول تمرکز کنند و به عبارت دیگر، داستان‌های کاربری را به صورت افقی یا در طول خطوط معماری سیستم برش بزنند.
به طور مثال، داستان کاربری “ورود به برنامه” در صورت برش افقی به صورت زیر خواهد بود:
- ایجاد یک رابط کاربری ورود به سیستم که خطاهای اعتبار سنجی مرتبط با نام کاربری و کلمه عبور را نیز نشان دهد یا در صورت ورود اشتباه کلمه عبور بیش از حداکثر تعداد مجاز حساب کاربری را مسدود نماید
- پیاده‌سازی منطق جانبی سرور برای اعتبار سنجی خط مشی کلمه عبور
- به روز رسانی رکورد کاربر در دیتابیس مانند ثبت (لاگ) آخرین ورود به سیستم کاربر و تعداد تلاش‌های نادرست
در تصویر زیر هر یک از موارد اشاره شده فوق، فقط بخشی از داستان کاربری ورود به برنامه هستند. برچسب نارنجی نشان دهنده ایجاد رابط کاربری و برچسب زردرنگ نشان دهنده پیاده سازی تغییرات مورد نیاز در پایگاه داده است.
برش داستان‌های کاربری به صورت افقی برای تیم، جهت شروع فرآیند می‌تواند نقطه شروع اولیه مناسبی باشد زیرا به فکر توسعه‌دهندگان نزدیک‌تر است. با این حال این نوع برش محصول برخاسته از تفکر مدیریت و توسعه محصول به شیوه‌ی رویکردهای سنتی است.
به طور مثال، فرض کنید یک تیم توسعه از مهارت‌های سرور ساید قوی‌تری در مقایسه با مهارت‌های توسعه رابط کاربری برخوردار باشند. از اینرو محصول در انتهای اسپرینت از ضعف رابط کاربری برای نمایش ویژگی‌های قابل عرضه به کاربر برخوردار خواهد بود هر چند که آیتم‌های توسعه داده شده از زیرساخت قوی برخوردار باشند. برای کاربر، رابط کاربری حکم محصول را در نگاه اول دارد و وقتی شما محصول را در سطح لایه فنی و معماری به صورت افقی برش داده‌اید و صرفا بر روی یک لایه تمرکز می‌کنید در نهایت ویژگی قابل عرضه یا از ضعف رابط کاربری یا ضعف زیرساخت رنج خواهد برد و محصول نیز در جایگاه ضعیفی به کاربر عرضه می‌شود.
در ادامه برخی از جنبه‌های منفی برش افقی محصول بیان شده است:
- قبل از حاضرشدن کیک، نمی‌توانید آن را امتحان کنید
برش کیک به صورت افقی به این معنی است که به صورت لایه لایه محصول خود را ارائه دهید. ناکامی این رویکرد این است که کاربران نمی‌توانند محصول را تا زمانی که به طور کامل توسعه داده نشده و لایه‌ها با هم یکپارچه نشده‌اند، تجربه کنند که سبب کاهش سرعت روند دریافت فیدبک از کاربران خواهد شد.
رویکرد چابک از ارائه محصول با حداقلی مجموعه‌ای از ویژگی‌های مورد نیاز برای ایجاد بازده سرمایه‌گذاری بهره می‌برد که مربوط به حداکثرسازی ارزش قابل ارائه از سوی محصول و توسعه‌های آتی مبتنی بر داده‌های تحلیلی و تصمیم‌گیری‌های قابل دفاع، منطقی و صحیح است.
- ممکن است کیک را امتحان کنید و دوست نداشته باشید
در صورت استفاده از برش افقی، ممکن است شما محصولی را توسعه دهید که بعد از ارائه و گذشت مدت زمان زیاد، تازه متوجه شوید که این محصول شما دقیقاً همان چیزی نبوده که مشتری درخواست داده و به عبارت دیگر آنقدر حلقه دریافت بازخورد از مشتری و بازار، طولانی شده که سبب افزایش ریسک، افزایش هزینه و مصرف منابع در روند توسعه و مدیریت محصول می‌شود.
علاوه بر این، افزایش زمان حلقه دریافت بازخورد از کاربر، با آنچه از متدولوژی‌های چابک انتظار داریم بدست بیاوریم، در تناقض است. کل ایده این است که بتوانیم به صورت چابک یاد بگیریم، از آموخته ها و شکست‌هایمان استفاد کنیم و با توجه به داده‌های معتبر تحلیلی از بازار هدف، تغییرات نیازمندی‌ها و بازار، حرکت‌های استراتژیک رقبا و غیره، دست به تغییرات و بهبودهای آتی بزنیم. از اینرو بازخورد مشتریان / کاربران نهایی به عنوان مهمترین منبع دانش و یادگیری تلقی می‌شود.
- تقریباً غیرممکن است که تمامی داستان‌های کاربر را به صورت افقی در لایه‌های مختلف به صورت هم تراز و با اولویت‌های کاری که مدام در حال تغییر هستند، سازگار کنید.
برش افقی نیازمندی‌های محصول، انعطاف‌پذیری شما را کاهش داده و موجب دشواری شناسایی نقشه راه محصول توسط مدیران محصول می‌شود و از دگرسو، مدیران پروژه برای مقابله با وابستگی و مدیریت هوشمندانه ظرفیت تیم به مشکل بر خواهند خورد که در پروژه‌های توسعه محصول بسیار شایع است. برش افقی در لایه‌ها به طور مستقل می‌تواند به یک کابوس تبدیل شود و هزینه، زمان و کیفیت کلی نتیجه نهایی محصول را به صورت منفی تحت تأثیر قرار دهد.
برش عمودی داستان های کاربری در فرآیند توسعه محصول
رویکرد دوم برش محصول، برش داستان‌های کاربری به صورت عمودی است به این صورت که هر داستان کاربری برای آنکه محقق شود باید از تمام لایه‌های معماری محصول عبور کند و تست های عملکردی خود را گذرانده باشد.
مثال داستان کاربری “ورود به برنامه” را به خاطر دارید که در روش برش افقی، برش در لایه زیرساخت و سمت سرور و به صورت افقی گذر کرده و لایه رابط کاربری را که لایه بازنمایی و نمایش ویژگی توسعه داده شده به کاربر می باشد، را در نظر نگرفته بود. این در حالیست که در برش عمودی، تحقق این داستان کاربری به صورتی است که باید برش لایه سرور و لایه رابط کاربری باید در نظر گرفته شوند تا عملکرد ورود به برنامه توسط کاربر تست شده و بازخورد آن دریافت شود.
در مثال “ورود به برنامه” طبق برش عمودی مراحل زیر را خواهیم داشت:
- توانایی وارد کردن کلمه عبور صحیح در فرم لاگین برای کاربر (رابط کاربری)
- پیاده سازی منطق سمت سرور سناریو ورود نام کاربری و کلمه عبور (happy path Login) دریافت شده از لایه UI و به روز رسانی آخرین ورود کاربر در پایگاه داده
- ممانعت از ورود کاربر با توجه به وارد کردن رمز عبور نادرست با پیاده‌سازی سناریو مربوطه (negative path Login) در سمت سرور
- به روز رسانی رابط کاربری برای کاربر از طریق ارائه پیام مناسب مانند “رمز عبور نادرست”
- پیاده‌سازی سناریو مسدودسازی حساب کاربری پس از ۳ تلاش نادرست در سمت سرور
- به روز رسانی رابط کاربری با ارائه پیغام مناسب مرتبط با مسدود شدن حساب کاربری
- به روز رسانی رکورد کاربر در دیتابیس با تعداد تلاش های نادرست منجر به مسدود شدن حساب کاربری و …
مزیت برش عمودی داستان‌های کاربری این است که نتایج هر مرحله ارزش خاص و موجهی را برای کاربر فراهم می‌نماید و روند تست ویژگی‌ها، برقراری ارتباط با مشتری و دریافت بازخورد از آنها را مبتنی بر حلقه‌های سریع یادگیری تسهیل می‌نماید. یک مشتری می‌تواند تجربه خود از یک فرم “ورود به برنامه” را با توجه به مسیر طراحی شده برای وی در محصول بیان نماید اما نمی‌تواند بازخوردی را تنها با تکیه بر مجموعه‌ای از جداول پایگاه داده ارائه کند.
انواع رویکردهای برش محصول
استراتژی‌های مختلفی برای برش داستان‌های کاربری در محصول مبتنی بر معیارهای مختلف وجود دارد که برخی از مهمترین آنها در ادامه شرح داده شده است:
- برش مبتنی بر مراحل گردش کار
- برش مبتنی بر قوانین و سیاست‌های کسبوکار
- برش مبتنی بر نقشه مسیر راضی / ناراضی برای کاربر
- برش مبتنی بر انواع داده‌ها و پارامترها
- برش مبتنی بر نوع پلتفرم و سیستم‌عامل
برش مبتنی بر فرآیندها و گردش‌های کاری
آیا داستان کاربری یک فرآیند یا یک گردش کاری (workflow) را توصیف می‌کند؟ آیا می‌توانید مراحل ابتدا و انتهای فرآیند را در یک داستان کاربری اصلی قرار دهید و مراحل میانی را در داستان‌های کاربری آتی برای توسعه‌ها و بهبودهای بعدی قرار دهید؟ آیا می‌توانید روی Happy Path یک فرآیند در ابتدا تمرکز کنید و خطاها و ولیدیشن‌ها و سایر آلارم‌های مربوط به negative path را در داستان‌های کاربری بعدی قرار دهید؟.
این سوالات بیانگر برش محصول مبتنی بر فرآیندها و گردش‌های کاربری موجود در محصول می‌باشد. از اینرو، هنگام شکستن گردش کار و یا نقشه مسیر کاربر به مراحل کوچکتر، مراقب سطح جزئیات مورد استفاده خود باشید. یک داستان می‌تواند یک مرحله از گردش کار شما را پوشش دهد به شرط آنکه برای کاربر مفید باشد. اگر فکر می‌کنید یک گام ارزش مورد نظر را نمی‌تواند به تنهای به مخاطبین هدف ارائه دهد پس احتمالاً شما باید بیش از یک مرحله را برای ایجاد یک ارزش قابل ارائه به کاربر گروه بندی نمایید.
هنگام مواجهه با گردش کارهای پیچیده، استراتژی خوبی است که از یک داستان کاربری ساده، کاربردی و اصلی برای کاربر (نگرش ساده‌سازی) شروع کنید و سپس به مرور، لایه‌های جدیدی از پیچیدگی را به محصول اضافه کنید. اما توجه داشته باشید که داستان‌های کاربری بعدی در راستای توسعه یا بهبود محصول می‌بایست مبتنی بر بازخورد کاربران و تصمیم‌گیری بر اساس داده‌های تحلیلی، انجام شوند.
در شکل زیر گردش کار خرید کاربر در یک وبسایت تجارت الکترونیکی نشان داده شده است.
برش مبتنی بر قوانین و سیاست‌های کسبوکار
اگر روش برش محصول شما مبتنی بر قوانین و سیاست‌های کسب وکار باشد، باید قوانین و سیاست‌هایی را انتخاب کنید که اکثریت موارد ارزشمند برای کاربر را پوشش دهد و واقعاً برای کاربر، سودمند و کاربردی باشد. در واقع باید در رویکردهای حل مسئله، سیاست‌ها و قوانینی که حاشیه‌ای هستند و اثربخشی و ارزشمندی آنها از اولویت دوم به بعد برخوردار است را تشخیص داده و کنار بگذارید.
حتی گاهی داستان‌های کاربری حاشیه‌ای را می‌توان با راه حل‌های ارزان‌تر و مقرون به صرفه جایگزین نمود. به طور مثال به جای توسعه یک ابزار اتوماسیون مارکتینگ توسط تیم توسعه، می توان از ابزارها و داشبوردهای آماده مانند Web engage استفاده کرد و پلن متناسب با ظرفیت کسبوکار را اجاره نمود که ارزان تر و به صرفه تر نیز هست تا اینکه به صورت درون‌سازمانی راه‌کار مشابه پیاده‌سازی شود.
همچنین از سیاست‌ها و قوانینی شروع کنید که سناریوها و کاربردهای اصلی کسبوکار شما را پاسخ می‌دهند و موارد بسیار خاص یا تکمیلی را برای بهبودها و توسعه‌های بعدی بسپارید.
در شکل زیر مثالی از قوانینی است که وب سایت تجاربت الکترونیکی با توجه به هزینه یا پیچیدگی عملیاتی، تصمیم خواهد گرفت سفارشی را رد کرده یا قبول نماید. فرض کنید هزینه‌های تحویل اولیه و فروش محصول برابر با ۵ دلار باشد و حجم سفارشات خارجی کم باشد. بنابراین اگر حجم زیادی سفارش از خارج از کشور وجود نداشته باشیم، حتی توسعه‌ی سناریوهای مرتبط با رد سفارشات خارجی مشمول هزینه توسعه، اتلاف وقت و تلاش تیم عملیات خواهد شد. از اینرو باید بر اساس داده‌های دریافتی و بررسی شده از دنیای واقعی بتوانیم سیاست‌ها و قوانین کلیدی کسبوکار را شناسایی کنیم و با توجه به پارامترهای تصمیم‌گیری مرتبط، روند توسعه و مدیریت محصول را در پیش بگیریم.
برش مبتنی بر نقشه مسیر راضی / ناراضی برای کاربر
چارچوب “مسیر رضایت / ناراضی” (Happy/Negative Path) می‌تواند به تقسیم داستان‌های کاربری محصول کمک کند، به خصوص هنگامی که روش‌های دیگر اثربخش نباشند.
به طور مثال امکان لاگین به اپلیکیشن را می‌توانید با رویکرد یک ثبت‌نام ساده اما بدون امکان ویرایش توسعه دهید، اما قابلیت ویرایش را برای توسعه‌های بعدی بگذارید. اما در نظر داشته باشید تا زمانیکه امکان ویرایش نام کاربری یا … را برای کاربران در لاگین در نظر نمی‌گیرید باید یک راه کار جایگزین مانند ایمیل یا تماس با پشتیبانی (راه کار با امنیت پایین‌تر اما موقتی) را در نظر داشته باشید که تیم عملیات بتوانند پاسخگو باشند.
برش مبتنی بر انواع داده ها و پارامترها
تعریف مدل‌های داده‌ای یک راه‌کار دیگر برای شکستن داستان‌های کاربری توسعه ویژگی‌های داده محور محصول مانند قابلیت جست‌و‌جو یا فرم‌های ثبت‌نام می‌باشد. کاربرپژوهی به شما این امکان را میدهد تا بتوانید به طور مثال با توجه به داده‌های تعریف شده، معیارهای کاربردی و مناسب فیلترهای جست‌و‌جو را شناسایی نمایید. همچنین در فرم ثبت‌نام شما می‌توانید موقتاً از اطلاعات مورد نیاز و الزامی شروع کنید.
علاوه بر این، برخی از ویژگی‌ها در محصول، انواع مختلفی از داده‌ها را مدیریت می کنند. برخی از داستان‌های کاربری از داده‌های ساده و برخی دیگر از داده‌های پیچیده‌تر ممکن است تشکیل شده باشند. برای مراحل اولیه می‌توان برش محصول را بر اساس داستان‌های کاربری با نوع داده‌های با درجه پیچیدگی کمتر انجام داد و به تدریج به سمت داستان‌های کاربری با مدل‌های داده‌ای پیچیده‌تر گام برداشت.
به طور مثال فرض کنید محصول شما نیازمند ثبت اطلاعات کسب‌و‌کارهای حقیقی و حقوقی است. شما تصمیم می‌گیرید در فاز اول سراغ کسب وکارهای حقیقی بروید. در فرم ثبت نام این کسب‌و‌کارها باید اطلاعاتی مانند نام کسبوکار، صنف، شماره مجوز، کدپستی و آدرس را دریافت کنید. در این بین صنف کسبوکار، کدپستی و آدرس کسبوکار فیلدهای اختیاری هستند. بنابراین شما حتی می توانید فعلا این فیلدهای اختیاری را نیز در فاز اول در نظر نگرفته و با رویکرد ساده‌سازی، فقط بر روی ویژگی‌های با داده‌ها و پارامترهای اصلی و با اولویت بالاتر تمرکز کنید.
برش مبتنی بر نوع پلتفرم و سیستم عامل
با توجه به وجود درگاه‌های مختلف ارتباط با کاربران مانند وبسایت و اپلیکیشن، طبیعی است که باید محصول را به گونه‌ای توسعه دهیم که در یک زمان بتوان محصول را بر روی بیش از یک پلتفرم عرضه کرد. اما تمرکز بر روی یک پلتفرم در فازهای اولیه، می‌تواند زمان عرضه محصول به بازار هدف و دریافت سریع‌تر بازخورد کاربران را تسریع بخشیده و همه چیز را ساده‌تر کند. به طور مثال شما می‌توانید از پلتفرم با بیشترین میزان استفاده و مخاطب در مراحل اولیه توسعه محصول شروع کنید و داستان‌های کاربری اصلی و کلیدی را برای آن پلتفرم در نظر بگیرید. به طور مثال، شما می‌توانید ابتدا نسخه‌ی آندرویدی محصول را و با تاکید بر ویژگی‌های اصلی آن عرضه نمایید و در توسعه‌ها و بهبودهای بعدی، به فرض نسخه آی.او.اس محصول خود را نیز در دستور کار توسعه قرار دهید.
برش محصول مبتنی بر رابط کاربری
آیا داستان کاربری برای محقق شدن مستلزم پیاده‌سازی یک رابط کاربری پیچیده برای کاربر است؟ آیا می‌توانیم در برش اولیه محصول ابتدا یک نمونه ساده‌تر از رابط کاربری با حداقل پیچیدگی، ولی ارزشمند برای کاربر را پیاده‌سازی کنیم؟ آیا داستان کاربری به گونه‌ای است که باید از چندین رابط کاربری دیگر داده‌های مختلف را دریافت و مدیریت نماید؟ و اگر اینطور باشد، آیا می‌توان در ابتدا روی ارزشمندترین اطلاعات و نمایش آنها در رابط کاربری ساده‌تر تمرکز نمود و به مرور در برش‌های بعدی محصول، اطلاعات و مدل‌های داده‌ای دیگر را به رابط کاربری افزود؟ این سوالات بیانگر برش محصول مبتنی بر رابط کاربری است.
برش محصول مبتنی بر معیارهای پذیرش داستان کاربری
فرض کنید یک داستان کاربری در صورتی مورد تایید محصول قرار خواهد گرفت که سه معیار اصلی پذیرش جهت تضمین ویژگی‌های کلیدی مرتبط با آن داستان را پوشش میدهد و همچنین دو معیار تکمیلی جهت بهینه‌سازی داستان برای کاربر را نیز در بر می‌گیرد.
آیا می توانید به صورت موقت، داستان کاربری را بر اساس معیارهای اصلی پذیرش در نظر بگیرید و سایر معیارهای جانبی (یا دو مورد از سه معیار اصلی)، تکمیلی یا با اولویت پایین‌تر را در داستان کاربری دیگر برای بهبودها و توسعه های بعدی در نظر داشته باشید؟. تصمیم گیری در مورد اینکه چه تعداد و کدامیک از معیارهای پذیرش داستان کاربری را می تواند در فاز جاری و کدامیک را در روندهای آتی در نظر داشت بسته به وضعیت پیشرفت کارها در طول مدیریت محصول و شرایط کسبوکار خواهد بود.
برش محصول مبتنی بر انواع کاربران
ممکن است هر نوع کاربر با توجه به پرسونای خود، داستان کاربری خودش را داشته باشد. در واقع ویژگی‌هایی در محصول ممکن است وجود داشته باشد که بسته به انواع مختلف کاربران به صورت متفاوتی در محصول نمود یابد. از اینرو ممکن است شما در برش‌های مختلف داستان‌های کاربری بر روی برخی از پرسوناهای مخاطبین و برای هر پرسونا بر روی ارزشمندترین داستان‌های کاربری مختص به آن در فازهای مختلف پیشبرد کارها تمرکز کنید.
رویکردهای مختلف برش محصول را بررسی کردیم که بسته به نوع محصول، شرایط کسبوکار و … می‌تواند برای هر محصول متفاوت باشد. از دگر سو، مدیر محصول می‌تواند از یک یا چند روش برش داستان‌های کاربری (رویکرد ترکیبی) برای تصمیم‌گیری، تهیه نسخه‌های مختلف انتشار محصول و … استفاده نماید. اتخاذ تصمیمات درست همیشه ساده نیست و مدیر محصول در طول فرآیندهای مدیریت محصول و با کسب تجربه و مهارت، می‌تواند تصمیمات خود را در زمینه برش داستان‌های کاربری، طراحی نسخه‌های محصول همسو با کسبوکار و بازار هدف و .. هوشمندانه‌تر نماید.
در ادامه بخوانید
