طراحی محصول، رقابتی از منظر فیچر! (قسمت دوم-بررسی یک تجربه)

این مقاله، بخش دوم مقاله‌ی زیر می‌باشد و پیشنهاد می‌شود ابتدا مقاله‌ی زیر را مطالعه کنید:

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

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

سیستم مجموعه ای از اجزا مرتبط است که برای رسیدن به یک هدف مشترک با همدیگر تعامل دارند.

از نظر من این تعریف برای محصول هم منطبق است،‌به این صورت که :

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

(درواقع طبق این تعریف، محصول را باید در تفکر سیستمی دید)

چه در سیستم و چه در محصول،‌ اجزای تشکیل دهنده،‌ به خودی خود دارای وظیفه و هدف هستند. بعنوان مثال در خودرو، چرخ ها ساختار مشخص دارند، حول یک محور می‌چرخند و هدف حرکت دادن خودرو را بهعده دارند…

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

بنابراین مجموعه ای از فیچرهاست که محصول را به رودمپ و اهداف اصلی خود میرساند.

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

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

همانطور که در تصویر می‌بینید، چرخه طراحی محصول ۵ مرحله‌ی کلی دارد:

۱- استراتژی: تعیین چشم انداز، اهداف و استراتژی محصول با توجه به بررسی نظرات سهامداران

۲- کشف: تعیین و بررسی نیازمندی های کاربران و محصول، جمعاوری اطلاعات از نظرسنجی و مصاحبه با کاربران، تحلیل نظرات آن‌ها

۳- تحلیل: ایجاد use case و یوزر استوری، پرسونا، استوری بورد و... براساس اطلاعات مراحل پیشین

۴-دیزاین: طراحی اسکچ، پروتوتایپ تجربه و رابط کاربری و یوزر تستینگ

۵-تولید: بتا لانچ، یوزر تستینگ، بالاروی محصول

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

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

پس محصول را ساده ببینید!

اولین و مهمترین اقدام در طراحی محصول اولیه ساده سازی است!

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

کمی توضیح در مورد پروژه...

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

زمان زیادی برای ارائه اولین نمونه به سرمایه گذار نمانده بود و میزان پیشرفت پروژه چیزی در حد صفر درصد بود…

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

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

فیچر لیستینگ تهیه کنید!

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

• اولین اقدام در این وضعیت پیدا کردن نقاط مشترک بود.

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

• قدم بعدی که به آن رسیدم، آپتیمایز کردن فیچرهای مشترک بود.

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

• آخرین قدم، دسته بندی فیچرها

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

نگاهی دقیق‌تر...

اگر بخواهیم دقیقتر به راهکاری که من استفاده کردم نگاه کنیم باید به این صورت شرح دهم :

همانطور که در تصویر می‌بینید، فیچر رزرو وقت (Appointment)، یک فیچر مادر است که در دل خود ۸ عدد فیچر زیرمجموعه‌ دارد. (فیچر هایی که آن‌ها را در تصویر قبلی دیدیم)

هر فیچری که روی کاغذ مینویسیم، ابتدا در نقطه‌ی صفر توسعه قرار دارد (هیچ فکری بابت اجرای آن نشده است) و اگر تمام و کمال اجرا شود و توسعه یابد به نقطه ی ۱۰۰ می رسد.

هنگامی که شما فیچری را خرد میکنید، اجزای پیچیده ی آن را جدا میکنید، از اولویت اجرا در این ورژن خارج میکنید، و باقی مانده فیچر را اجرا میکنید، شما حدودا بین ۵۰ تا ۷۰ درصد آن فیچر را به مرحله اجرا برده‌اید.

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

خب، همانطور که در تصویر می‌بینید، اگر A را فیچر مادر در نظر بگیرید و A1 تا‌ A8 را فیچر های زیر مجموعه‌ی آن در نظر بگیرید، باید فیچرهای زیر مجموعه را از نظر سختی و آسانی توسعه و اجرا، دسته‌بندی کنید و ‌برای ورژن اول، فیچرهایی که پیچیدگی اجرایی ندارند و توسعه آن‌ها کار آسانی است (Easy to develop) را در مرحله اجرا قرار دهید، فیچر هایی را که از نظر فنی پیچیدگی اجرا دارند و توسعه آن‌ها کار سخت و زمان‌بری است (Hard to develop) را از ورژن اول خارج کنید و برای ورژن بعدی به سراغ اجرای آن‌ها بروید.

این کار را در چند ورژن از محصول انجام ‌دهید تا فیچر مادر شما به نقطه‌ی ۱۰۰٪ توسعه برسد، به این معنی که تمام فیچرهای زیر مجموعه‌اش را اجرا کرده‌اید و توسعه داده‌اید.

خب،آیا این فیچر به نقطه‌ی کمال خود رسیده است؟

آیا بعنوان مدیرمحصول یا طراح محصول، کار طراحی فیچر رو به پایان رسانده‌اید ؟

اگه خاطرتون باشه در انتهای بخش قبلی مقاله گفتم که :

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

آغاز فرآیند توسعه فیچرها و در نهایت توسعه محصول…

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

این مقاله آمیخته‌ای از تجریبات شخصی به همراه استخراج مطالب از uservoice.com و craft.io و uxdesign می‌باشد.