اصول پایه و دستورالعمل هایی برای مدیران محصول جهت نوشتن بهینه تر اپیک و یوزر استوری
نوشتن اپیک و یوزر استوری خوب، اولین، پایه ای ترین و مهترین وظیفه شماست وقتی وظیفه مدیریت محصول رو به عهده دارید. برای همین موضوع تصمیم گرفتم خلاصه ای از چند مقاله از "product coalition " رو برای دوستانی که به تازگی میخوان وارد حوزه محصول بشن ترجمه کنم و با اضافه کردن یک سری تجربیات شخصی منتشر کنم.
نکته مهم اینه که این دستورات در همه وضعیت ها قابل اجرا نیست و تفکیک و انتخاب موارد قابل اجرا و غیر قابل اجرا جزوی از مسئولیت های مدیریت محصول هستش. اما اینجا یک راهنمای اساسی جهت نوشتن اپیک و یوزر استوری مطرح میشه.
اپیکِ خوب نوشته شده، کلیدی ترین مشخصه اش اینه که به طور کامل قابل فهم باشه و بدون هیچ شبهه ای مسیر توسعه رو طی کنه. رعایت این معیار، میزان زیادی از سوءتفاهمات و درگیری های درون تیم رو حل میکنه.
از اونجایی که اپیک همون چیزیه که شما زمان نوشتن یوزراستوری ها بهش مراجعه میکنید و اعضای تیم هم برای توسعه محصول به سراغ یوزراستوری ها میرن، آوردن جزئیات در زمان نوشتن اپیک برای همکاری بهتر یکی از مهمترین بخش های نوشتن اپیک خواهد بود.
به عنوان یک مدیر محصول یا یک مالک محصول اجایل (Product manager or agile product owner) در زمان خلق اپیک از موارد زیر باید پیروی کنید :
به عنوان مدیر محصول شما مسئول نوشتن اپیک و نگهداری از سند اپیک(Epic Spec Sheet) خواهید بود اما بر اساس تجربه، میشه برای تکمیل سند اپیک، از مدیر فنی برای نوشتن نیازمندی های فنی و دیزاینر های تجربه کاربرتون(UX Designers) برای نیازمندی های طراحی کمک بگیرین. این همکاری در بلند مدت تاثیر قابل توجهی در سرعت توسعه خواهد داشت.
در قسمت توضیحات شما باید درمورد "چرایی" و "چه چیزیِ" اپیک صحبت کنید. در زمان نوشتن اپیک انتخاب شده برای توسعه، مواردی رو بیان کنید که چرا فیچر مورد نظر توسعه داده میشه، این فیچر چگونه قراره مشکل کاربر رو حل کنه و دستاورد شما بعد از توسعه این فیچر چه خواهد بود.
به علاوه اگر داکیومنت، عکس، وایرفریم های ابتدایی و ... دارید که به تیم در جهت بالا بردن اطلاعات کمک میکنه، در این قسمت ضمیمه کنید. کلید ارائه موفق، درک مشترک و استنباط هدف از توسعه اپیک میباشد.
خیلی کوتاه، قسمت توضیحات شما میتونه شامل :
خلاصه ای از فیچر های قابل توسعه اپیک و چرایی ساخت آونا
متریک های انتخابی جهت بهبود
لینک به سایر اسناد
برنامه مارکتینگی، حقوقی (در صورت نیاز)
وایرفریم های ابتدایی
مثال : به عنوان مثال تیم شما درحال کار روی یک فروشگاه آنلاین خرده فروشی به صورت مارکت پلیس هستش و شما تصمیم گرفتین که یک لیست خرید ثانویه به جز سبد خرید اصلی برای کاربرانتون تعبیه کنید.
توضیحات : این فیچر به کاربران کمک میکنه تا کالا هایی که در سفارش آتی قصد خرید آنها را نداردند را در یک لیست خرید ثانویه نگهداری کند.
تحقیقات ما نشون میده، 70% از کاربران از این قابلیت استفاده خواهند کرد و در تست کاربر، دیزاین های ما برای کاربر کاملا بصری بود.
ما انتظار داریم این قابلیت، 12% باعث نهایی شدن سبد های خرید بیشتر شود و میزان استفاده از سرویس به طور میانگین 3% افزایش پیدا کند.
به صورت ایده آل ما میخوایم کاربر بتونه کالا های همه فروشندگان را به لیست خرید ثانویه اضافه کنه اما در محصول MVP تنها محصولاتی این قابلیت رو دارن که در انبار فیزیکی خرده فروشی موجود و مالک آن خرده فروشی باشد.
از موارد ضروری نوشتن اپیک، پرداختن به نیازمندی های محصول هستش که اعضای تیم درک کنند چه چیزی را باید دیزاین کنند، بسازند، تست و منتشر کنند. برای مثال اگه شما میخواهید یک محصول توسعه بدید که در زبان های مختلف در دسترس باشد یا برای دیوایس های متفاوت مثل موبایل، تبلت، دسکتاپ و ... ارائه شود، تمامی این موارد باید در قسمت نیازمندی های محصول، در سند اپیک شرح داده شود.
در ادامه مثال بالا، نیاز های محصول شما میتونه به شرح زیر باشه :
نیازمندی های محصول : به صورت پیشفرض بعد از اضافه کردن کالا به سبد خرید، کالا به سبد اصلی منتقل خواهد شد اما کاربر این قابلیت را دارد در زمان بررسی سبد خرید، کالا را به سبد ثانویه منتقل کند. کاربر میتواند تعداد کالای افزوده شده به سبد خرید را بسته به تعداد موجود در انبار و محدودیت سفارش تغییر دهد و یا حذف کند.
کالای در سبد خرید ثانویه، رزرو نمیشوند. (در زمان انتقال به سبد ثانویه، این مورد به کاربر اطلاع رسانی خواهد شد)
در زمان نوشتن نیازمندی های طراحی باید بیشترین همکاری ممکن با طراحان تجربه کاری(UX Designers) انجام شود. ممکنه مسائل و نکاتی از نظر طراحان در رابطه با تجربه کاربری قرار داشته باشه که به ذهن شما خطور نکرده باشه. برای مثال ممکنه دیزاینر شما تصور کنه بهتره ترتیب نمایش سبد خرید فعلی و سبد خرید ثانویه به شکل خاصی باشه تا تجربه کاربری بهتری رو برای کاربر رقم بزنه. این دسته از نیازمندی ها در این بخش آورده میشود.
در ادامه مثال های بالا، نیازمندی های طراحی میتواند به شکل زیر باشد :
نیازمندی های طراحی : نمایش سبد خرید فعلی و سبد ثانویه در دو تب مجزا
در صورت تغییری در موجودی و یا قیمت سفارش به کاربر اطلاع رسانی شده و مغایرت گیری شود.
امکان افزودن هر ردیف کالا به سبد خرید فعلی
امکان افزون تمام ردیف های کالا در این لیست به سبد خرید با یک دکمه
مانند طرح ریزی نیازمندی های طراحی، داشتن ارتباطات با سطح بالا و با کیفیت و مداوم با رهبر تیم فنی و سایر اعضاء تیم فنی از اهمیت قابل توجهی برخوردار هست. ورودی های آنها در مراحل ابتدایی برای تخمین زمانی پروژه و ساخت صحیح محصول اهمیت بالایی دارد. برای مثال، ممکنه تیم فنی بخواد چند API در جهت ادغام سبد خرید فعلی و لیست خرید بعدی تعبیه کند. این مشخصات و نیازمندی های فنی میبایست در قسمت نیاز های مهندسی آورده شوند.
میتونیم برای ادامه مثال بالا این موارد رو اضافه کنیم :
نیازمندی های مهندسی : نیاز به دیتابیس لیست خرید بعدی به اندازه X
انتقال کد مشتری به لیست خرید بعدی
حذف خودکار لیست خرید بعدی بعد از گذشت n ماه
داشتن یک سند اپیک مناسب باعث تاثیر مثبت در همکاری و تعامل اعضای تیم شما خواهد بود. برای شما به عنوان مدیریت محصول هم باعث میشه یوزر استوری های دقیق تری برای شکستن وظایف تعریف کنید و اولویت بندی آیتم های بک لاگ خیلی راحت و روان انجام بشه.
یوزر استوری ساده ترین نوع شکستن اپیک به اجزای کوچک تر و کاربر محورتر برای تیم فنی جهت تفهیم کامل نیازمندی های محصول خواهد بود. در متدولوژی اجایل تمام چیز هایی که توسعه داده میشود میبایست حول کاربر تعریف شود، به همین منظور تعریف یوزر استوری باید در راستای مکالمات روزانه و عامیانه باشد.
در اینجا یک نمونه ساده از نحوه نوشتن یوزر استوری رو باهم بررسی میکنیم :
به عنوان (یک نوع یوزر)، میخواهم (یک نوع هدف)، برای اینکه (نتیجه).
As a (type of user), I want (some goal), so that (reason).
نکته مثبت یوزر استوری وضعیت شفاف و ساده ی اون از دیدگاه کاربری هستش که قراره از فیچر استفاده کنه.
یک یوزر استوری خوب میبایست در وضعیت مناسبی از میزان توضیحات قرار داشته باشد. تعریف یک نیازمندی که شامل توضیحات، به اضافه شرایط پذیرش فیچر خواهد بود. شرایط پذیرش، یک تصویر واضح برای تیم فنی میباشد جهت درک اینکه درحال ساخت "چه محصولی" هستند و برای تیم QA (تضمین کیفیت) یک وضعیت شفاف در راستای تست های پذیرش رقم خواهد زد. مواردی که باید رعایت شوند :
§ یوزر استوری
§ شرایط پذیرش (Acceptance criteria)
§ طراحی های پیوست شده به شرایط پذیرش
تا به اینجا یک اپیک برای فروشگاه خرده فروشی طراحی کرده ایم که آن قابلیت لیست خرید ثانویه برای کاربر بوده است. در این قسمت به نوشتن یوزر استوری و معیار های پذیرش این یوزر استوری میپردازیم.
یوزر استوری : به عنوان کاربر میخواهم، کالایی که در لیست خرید ثانویه قرار دارد را به سبد خرید اضافه کنم، برای اینکه خرید کالا نهایی شود.
معیار پذیرش : با توجه به اینکه من کاربر هستم، با کلیک بر روی گزینه افزودن به لیست خرید بعدی، یک پاپ آپ با هدف تایید و یا عدم تایید نمایش داده خواهد شد.
در صورتی که موجودی یک کالا در لیست خرید بعدی تمام شده باشد، با کلیک بر روی افزودن به سبد خرید یک پاپ آپ با عنوان اتمام موجودی نمایش داده خواهد شد.
نوشتن یک یوزر استوری شفاف همراه با معیار های پذیرش کاربردی به برنامه نویسان کمک میکند تا در رابطه با فرآیند کار فیچر در زمان توسعه تفکر کنند. تمامی طراحی ها رو برای مهندسان نرم افزار و مهندسان QA ضمیمه کنید تا در زمان کار بر روی یوزر استوری آنها را دنبال کنند. این عمل باعث کمک به اسکرام مستر برای برآورد صحیح ظرفیت تیم میشود.
یوزر استوری خوب نوشته شده = برد، برد، برد ...
