تصمیم گیری در مورد توسعه کدام ویژگی(فیچر) و چگونگی اولویت بندی آنها

این مطلب یکی از مطالب مهمی هست که هر مدیر محصول یا صاحب محصول بهتر است با آن آشنا شده و روزانه از آن پیروی کند. این مطلب ترجمه ی مقاله Deciding which features to build and how to prioritize them که توسط آقای David Pichsenmeister نوشته شده و توسط من ترجمه شده است.

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

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

پانوشت مترجم : استفاده از ماتریس 2X2 سود و هزینه و همچنین مطمین بودن از اینکه این موارد به عنوان یک ایده ی واقعا جدید هستند، میتواند در ابتدای امر بسیار مفید باشد(قبل از استفاده از مدل این مقاله)

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

• آیا این ویژگی برای اکثر کاربران مفید هست یا برای تعداد معدودی کاربر؟ (ارتباط کاربر - User Relevance)

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

• چند بار از آن استفاده خواهد شد؟ (استفاده مکرر - Usage frequency)

استفاده چند باره از ویژگی، ارزش آن را برآورد میکند. آیا این ویژگی بصورت ساعتی، روزانه، هفتگی یا ماهانه توسط کاربران استفاده خواهد شد؟ حتی شاید کمتر؟ عمدتا در نظر داریم که بیشتر منابعمان را برای ساختن ویژگی هایی صرف کنیم که بیشتر کاربران در بیشتر اوقات از آنها استفاده خواهند کرد. (استفاده مکرر کاربر از یک ویژگی بیشتر باشد)

• میتواند ارتباط برقرار کند؟ (ارتباط - Communication)

زمانی که ویژگی اضافه میکنیم، عملا میخواهیم تا ارتباطی با کاربران و ویژگی بوجود آید. ویژگی هایی با تاثیر گذاری بالا یا پایین وجود دارند. ویژگی ها با تاثیر گذاری بالا، چیزی هست که میتوانید داستانی در مورد آن بسازید. از خودتان بپرسید که این همان چیزیست که شما میتوانید توییت کنید یا در مورد آن پستی در بلاگ بنویسید؟ یا چیزی هست که نشریات و مجلات هم به آن علاقه مند هستند و دوست دارند در مورد آن بنویسند؟

• آیا موجب تقویت(تثبیت) موقعیت شما در بازار میشود؟ (تثبیت موقعیت - Positioning)

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

• آیا قدرت فوق العاده ای به کاربران میدهد؟ (ارزش - Value)

قدرت فوق العاده آن چیزیست که تاثیر مثبتی زیادی در گردش کار کاربر (Workflow) داشته باشد. این همان چیزیست که کاربران میتوانند با استفاده از ویژگی جدید، به آن چیزی که قبلا وجود نداشت برسند یا راه حل جدیدی دست یابند.

سوالات مشابه آن میتواند باشد مانند : "آیا میتوانیم از ابزارهایی که قدیمی شده اند(یا منسوخ) استفاده کنیم؟" یا "آیا این ویژگی کارایی رو بهبود میبخشد؟"

• باعث کاهش یا افزایش پیچدگی میشود؟ (پیچیدگی کم - Low Complexity)

همه ی ویژگی هایی که اضافه میکنند باعث آسان تر شدن استفاده از محصولتان نمیشود. برخی از آنها باعث پیچیدگی بیشتر و برخی نیز کاهش پیچیدگی را بدنبال دارند. یک راه خوب این خواهد بود که این موارد رو از دیدگاه کاربرانی که میتوانند از آن استفاده کنند، کشف کنید. آیا این چیزیست که برای کاربران قوی تر(قدیمی تر) قابل استفاده هست یا کاربران جدید هم میتوانند سریع از آن استفاده کنند؟

• آیا روشی وجود دارد که با استفاده از ویژگی های فعلی، به کاربران پیشنهاد دهیم؟ (قابل تعویض - Substitutable)

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

• پیاده سازی آن چقدر ساده یا دشوار هست؟ (تلاش کم پیاده سازی - Low Implementation Effort)

ویژگی های جدید میتوانند بعضی اوقات ساده و راحت و در زمان و با منابع کم قابل پیاده سازی باشند، بعضی اوقات هم به منابع زیادی نیاز داشته باشند. ویژگی هایی که منابع زیادی احتیاج دارند بایستی با دقت برنامه ریزی شده و ارزش کشف منابع جایگزین کمتر برای تست استفاده مکرر و ارتباط کاربر را دارند.

• آیا این ویژگی به رشد ما کمک میکند؟ (پتانسیل رشد - Growth potential)

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

• هزینه تاخیر (Cost of Delay)

توجه : این مورد توسط مترجم (علوی نیک) اضافه شده است.

محاسبه ی هزینه تاخیر، یکی از موارد مهمیست که میبایست در نظر گرفته شود. به این سوال پاسخ دهید که "اگر ارایه یک ویژگی را یک ماه به تاخیر بیاندازید، هزینه ی این تاخیر در سود چرخه ی عمر محصول چقدر خواهد بود؟" (برگرفته از کتاب Essential scrum نوشته شده توسط کنی اس. روبین)

هزینه ی تاخیر یکی از مفاهیم بسیار مهمیست که بعضی سازمان ها همانند اسپاتیفای در جهت کاهش آن، کل ساختار خود را متناسب با آن اصلاح کرده اند. (مقاله مرتبط با مطالعه کنید)

ارجاع : مقاله در مورد محاسبه ی هزینه تاخیر

این لیست میتواند به عنوان روندی مداوم بجای مجموعه ای ثابت از سوالات در نظر گرفته شود که طی مراحل تصمیم گیری از طریق آنها کمک میکند تا درک بهتری نسبت به ساخت(توسعه) و چگونگی اولویت بندی آن داشته باشیم.

من یک گوگل شیت ساده(مشاهده فایل) در جهت محاسبه امکان پذیری این موارد بوجود آوردم. هر ویژگی به عنوان یک ردیف از این فایل در نظر گرفته شده و هر پرسش به عنوان یک ستون. برای هر سلول یک مقدار بین صفر تا پنج که قابل انتخاب باشد در نظر گرفتم. مقدار صفر یعنی بدون ارزش و پنج هم بالاترین ارزش. هر ویژگی در نهایت یک مقداری بنام Score که بین ۰ تا ۴۵ است به عنوان مجموع ارزش های هر ویژگی در نظر گرفتم که ویژگی هایی که ارزش بیشتری دارند، زودتر بایستی پیاده سازی شوند.

در صورت تمایل میتوانید من رو دنبال کنید تا آخرین مطالب مرتبط با مدیریت محصول، طراحی محصول و چابک را مشاهده کنید.

جهت مشاهده دیگر مقالات منتشر شده توسط من، کلیک کنید.

برخی مقالات مرتبط: