وقتی مشتری درخواست اضافه‌شدن یک قابلیت جدید به نرم‌افزار را مطرح می‌کند، از کجا بفهمیم واقعاً به آن نیاز دارد؟ آیا باید درخواستش را به فهرست توسعه اضافه کنیم یا شاید بتوان مشکلش را بدون ساخت هیچ قابلیت تازه‌ای حل کرد؟
اولویت‌بندی قابلیت‌های نرم‌افزار از همین تشخیص شروع می‌شود. باید بفهمیم کاربر چه مشکلی دارد، برای حل آن چه کاری انجام می‌دهد و چرا امکانات فعلی محصول پاسخ‌گوی نیازش نیستند. بعد می‌توانیم درباره توسعه تصمیم بگیریم.
این تفاوت در ظاهر ساده است، اما نادیده‌گرفتنش می‌تواند ماه‌ها از وقت تیم توسعه را صرف امکاناتی کند که کاربران حتی سراغشان نمی‌روند. ماجرای یکی از بزرگ‌ترین تغییرات تاریخ مایکروسافت آفیس، مثال جالبی از همین اشتباه است.
وقتی کاربران قابلیتی را درخواست می‌کنند که از قبل وجود دارد
در جریان توسعه Microsoft Office 2007، تیم مایکروسافت با مسئله عجیبی روبه‌رو شد. کاربران قابلیت‌های متعددی درخواست می‌کردند، اما بخش بزرگی از این امکانات از قبل در نسخه Office 2003 وجود داشتند!
طبق گزارش مجله Wired درباره رابط کاربری جدید Microsoft Office، پل کولمن، مدیر ارشد بازاریابی مایکروسافت، گفته بود که از هر ده درخواست قابلیت جدید برای Office 2007، نُه مورد در نسخه قبلی نرم‌افزار وجود داشت.
مشکل اصلی کمبود امکانات نبود؛ کاربران نمی‌توانستند آن‌ها را پیدا کنند.
مایکروسافت در Office 2007 رابط کاربری Ribbon را معرفی کرد؛ ساختاری که بسیاری از ابزارهای پراکنده در منوهای قدیمی را به شکلی قابل‌دسترس‌تر نمایش می‌داد. هدف این تغییر، ساده‌ترکردن مسیر رسیدن به قابلیت‌ها بود.
این ماجرا یک نکته مهم درباره توسعه نرم‌افزار دارد: درخواست قابلیت جدید، همیشه نشانه کمبود قابلیت نیست. گاهی نشانه ضعف تجربه کاربری است.
فرض کنید کاربری می‌گوید نرم‌افزار حسابداری شما به گزارش فروش ماهانه نیاز دارد. تیم توسعه می‌تواند این درخواست را ثبت کند و برای ساخت یک داشبورد تازه برنامه بریزد. اما شاید گزارش موردنظر در بخش دیگری از نرم‌افزار وجود داشته باشد و کاربر فقط نتوانسته آن را پیدا کند.
در چنین شرایطی، تغییر نام یک گزینه، اصلاح ساختار منو یا اضافه‌کردن یک مسیر دسترسی ساده ممکن است مؤثرتر از توسعه یک قابلیت کاملاً جدید باشد.
مسئله این نیست که مشتری اشتباه می‌کند. اتفاقاً درخواست او سرنخ مهمی درباره تجربه استفاده از محصول است؛ فقط نباید آن را مستقیماً به راه‌حل تبدیل کنیم.
نقش رویکرد Jobs to Be Done در شناخت نیاز واقعی کاربران
در طراحی و مدیریت محصول، رویکردی به نام Jobs to Be Done یا JTBD وجود دارد که به ما کمک می‌کند مسئله را از زاویه متفاوتی ببینیم.
این رویکرد که کلیتون کریستنسن و همکارانش از چهره‌های اصلی توسعه آن بودند، به‌جای تمرکز صرف بر ویژگی‌های محصول، تلاش می‌کند بفهمد کاربران در شرایط مشخص، برای رسیدن به چه نتیجه‌ای از محصول استفاده می‌کنند.
در معرفی نظریه Jobs to Be Done در مؤسسه کریستنسن، همین پیشرفت مطلوب کاربر، محور شناخت تقاضا و طراحی راه‌حل قرار می‌گیرد.
برای مثال، کاربری که درخواست خروجی اکسل از یک داشبورد مدیریتی را دارد، لزوماً به یک دکمه دانلود نیاز ندارد. شاید می‌خواهد گزارش هفتگی را برای مدیرش ارسال کند، داده‌ها را با گزارش ماه گذشته مقایسه کند یا اطلاعات را به نرم‌افزار دیگری انتقال دهد.
هر کدام از این نیازها می‌توانند راه‌حل متفاوتی داشته باشند.
وقتی درخواست مشتری با مسئله واقعی او تفاوت دارد
شرکت Intercom، ارائه‌دهنده نرم‌افزارهای ارتباط با مشتری، در یکی از مطالب رسمی خود درباره مدیریت درخواست‌های کاربران، مثال جالبی مطرح کرده است.
بعضی از مشتریان درخواست می‌کردند امکان خاموش‌کردن پنجره چت خارج از ساعت کاری فراهم شود. در نگاه اول، درخواست کاملاً مشخص بود: اضافه‌شدن قابلیتی برای غیرفعال‌کردن چت.
اما آیا مسئله اصلی واقعاً نمایش پنجره چت بود؟
در راهنمای Intercom برای پاسخ‌گویی به درخواست قابلیت‌های جدید، این شرکت توضیح می‌دهد که می‌توانست با تنظیم ساعت کاری و نمایش زمان تقریبی پاسخ‌گویی، به نتیجه موردنظر بسیاری از مشتریان برسد؛ بدون اینکه قابلیت درخواستی آن‌ها ساخته شود.
در واقع، مسئله بعضی از مشتریان این بود که کاربرانشان انتظار پاسخ فوری نداشته باشند.
اینجا تفاوت بین «خواسته مشتری» و «نیاز واقعی مشتری» روشن می‌شود. مشتری راه‌حلی پیشنهاد کرده بود، اما با بررسی دقیق‌تر مشخص شد که راه دیگری هم برای رسیدن به همان نتیجه وجود دارد.
این دقیقاً همان جایی است که شناخت نیاز کاربر، پیش از شروع توسعه محصول اهمیت پیدا می‌کند.
نیازسنجی کاربران پیش از توسعه؛ از گفت‌وگو تا شواهد واقعی
شناخت نیاز مشتری فقط با پرسیدن «چه قابلیتی می‌خواهید؟» اتفاق نمی‌افتد. حتی سؤال «چرا این قابلیت را می‌خواهید؟» هم همیشه کافی نیست؛ چون ممکن است کاربر به‌جای توضیح مشکل، شروع به دفاع از راه‌حل پیشنهادی خودش کند.
برای رسیدن به اطلاعات دقیق‌تر، بهتر است به‌جای پرسیدن درباره آینده، تجربه‌های واقعی گذشته را بررسی کنیم.
۱. مصاحبه با کاربر درباره آخرین تجربه واقعی
دفعه بعد که مشتری درخواست یک قابلیت جدید مطرح کرد، گفت‌وگو را با سه سؤال شروع کنید:
- آخرین باری که به این قابلیت نیاز پیدا کردی، دقیقاً چه اتفاقی افتاد؟
- الان بدون این قابلیت، چطور کارت را انجام می‌دهی؟
- کدام قسمت از این فرایند بیشترین مشکل را برایت ایجاد می‌کند؟
این سؤال‌ها کمک می‌کنند به‌جای دریافت یک پیشنهاد کلی، موقعیت واقعی استفاده از محصول را بشناسیم.
فرض کنیم کاربری در یک پلتفرم آموزشی درخواست قابلیت یادداشت‌برداری داخل ویدیو را مطرح کرده است. شاید در گفت‌وگو متوجه شویم که مشکل اصلی او یادداشت‌برداری نیست؛ می‌خواهد بخش‌های مهم درس را پیدا کند و هنگام مرور مطالب دوباره سراغشان برود.
در این حالت، نشانه‌گذاری لحظه‌های مهم ویدیو، نمایش خلاصه درس یا امکان مراجعه مستقیم به یک بخش مشخص هم می‌توانند گزینه‌های مناسبی باشند.
قرار نیست بدون بررسی، یکی از این راه‌حل‌ها را انتخاب کنیم. نکته این است که مسئله واقعی، فرصت بررسی گزینه‌های بیشتری را در اختیارمان می‌گذارد.
۲. بررسی رفتار کاربران با داده‌های محصول
گفته‌های کاربران تنها بخشی از اطلاعات موردنیاز ما هستند. بخش دیگر را می‌توانیم از رفتار واقعی آن‌ها به دست بیاوریم.
برای این کار، باید مشخص کنیم کاربر از کدام نقطه وارد فرایند می‌شود، چه اقداماتی انجام می‌دهد و در کدام مرحله متوقف می‌شود.
برای مثال، در یک نرم‌افزار رزرو آنلاین می‌توانیم رویدادهای زیر را ثبت و بررسی کنیم:
- بازکردن صفحه رزرو
- انتخاب خدمت موردنظر
- انتخاب تاریخ و ساعت
- ورود اطلاعات تماس
- آغاز پرداخت
- تکمیل موفق رزرو
اگر تعداد زیادی از کاربران پس از انتخاب ساعت، فرایند را رها کنند، می‌توانیم همان بخش را دقیق‌تر بررسی کنیم. شاید مشکل از زمان‌بندی، نمایش هزینه، خطای فنی یا مراحل اضافی باشد.
البته نرخ ریزش به‌تنهایی علت مشکل را نشان نمی‌دهد. این داده فقط به ما می‌گوید کجا باید دنبال مسئله بگردیم.
در کنار ابزارهای تحلیل رفتار، درخواست‌های پشتیبانی هم منبع ارزشمندی هستند. دسته‌بندی تیکت‌ها بر اساس نوع مشکل کمک می‌کند بفهمیم کدام موانع بیشتر تکرار می‌شوند و کدام قابلیت‌های موجود برای کاربران مبهم‌اند.
۳. آزمون کاربردپذیری پیش از ساخت قابلیت
گاهی ساده‌ترین راه برای پیدا کردن مشکل این است که از کاربر بخواهیم یک کار مشخص را در نرم‌افزار انجام دهد و فقط مشاهده کنیم.
به این روش Usability Testing یا آزمون کاربردپذیری می‌گویند.
بر اساس راهنمای Nielsen Norman Group درباره آزمون کاربردپذیری، مشاهده رفتار کاربران هنگام انجام فعالیت‌های واقعی می‌تواند مشکلات طراحی و فرصت‌های بهبود را آشکار کند.
برای مثال، به‌جای اینکه به کاربر بگوییم «از بخش گزارش‌ها خروجی بگیر»، بهتر است بگوییم:
«فرض کن مدیرت گزارش فروش ماه گذشته را خواسته. با استفاده از این نرم‌افزار، گزارش را آماده کن.»
در حالت دوم، به کاربر نمی‌گوییم از کدام قابلیت استفاده کند. بنابراین می‌توانیم بفهمیم آیا خودش مسیر درست را پیدا می‌کند یا نه.
در یک آزمون کیفی کوچک، حتی مشاهده چند کاربر از گروه مخاطبان هدف می‌تواند مشکلات اولیه را روشن کند. برای سنجش آماری و تعمیم نتایج، البته به نمونه بزرگ‌تر و طراحی دقیق‌تری نیاز داریم.
دو معیار کاربردی برای ارزیابی چنین آزمونی عبارت‌اند از:
نرخ موفقیت در انجام کار (Task Success Rate): چند درصد کاربران توانستند فعالیت مشخص‌شده را با موفقیت به پایان برسانند؟
زمان انجام کار (Time on Task): انجام آن فعالیت چقدر طول کشید؟
اگر یک قابلیت وجود دارد اما کاربران نمی‌توانند بدون راهنمایی از آن استفاده کنند، احتمالاً به بهبود تجربه کاربری نیاز داریم، نه ساخت قابلیت دیگری با همان کارکرد.
از درخواست قابلیت جدید تا تصمیم توسعه؛ چه راه‌هایی داریم؟
پس از شناخت مسئله و بررسی شواهد، نوبت تصمیم‌گیری است. در این مرحله، هر درخواست را می‌توان در یکی از چهار مسیر زیر بررسی کرد.
| وضعیت شناسایی‌شده | اقدام مناسب |
|---|---|
| قابلیت وجود دارد، اما پیدا نمی‌شود | بهبود مسیر دسترسی و طراحی رابط کاربری |
| قابلیت وجود دارد، اما استفاده از آن دشوار است | اصلاح فرایند و تجربه کاربری |
| کاربر به نتیجه موردنظر نمی‌رسد، اما راه‌حل دیگری در محصول وجود دارد | اصلاح جریان کار، آموزش یا استفاده از امکانات فعلی |
| نیاز مهم و تکرارشونده است و راه‌حل موجود پاسخ‌گو نیست | بررسی ساخت قابلیت جدید و اعتبارسنجی راه‌حل |
این دسته‌بندی کمک می‌کند درخواست‌ها مستقیماً وارد صف توسعه نشوند. هر درخواست ابتدا باید به یک مسئله مشخص و سپس به یک تصمیم قابل‌دفاع تبدیل شود.
در تکنوراه هم رویکرد ما در طراحی و توسعه نرم‌افزارهای اختصاصی از همین نقطه شروع می‌شود. پیش از ورود به مرحله طراحی و کدنویسی، تلاش می‌کنیم نیازهای واقعی کسب‌وکار را از راه‌حل‌های پیشنهادی جدا کنیم و محدوده پروژه را بر اساس مسئله‌ای که قرار است حل شود، مشخص کنیم. چون حتی یک نرم‌افزار باکیفیت هم اگر برای حل مسئله اشتباهی ساخته شده باشد، الزاماً ارزشی برای کسب‌وکار ایجاد نمی‌کند.
یک مثال کاربردی از اپلیکیشن‌های مدیتیشن
برای اینکه این موضوع ملموس‌تر شود، فرایند توسعه یک اپلیکیشن مدیتیشن را در نظر بگیریم. محصولی که کاربران در آن به محتوای صوتی و تمرین‌های ذهن‌آگاهی دسترسی دارند و می‌توانند برای تمرین روزانه یادآور تنظیم کنند.
این دسته از محصولات برای ما در تکنوراه هم آشناست؛ تجربه طراحی اپلیکیشن مدیتیشن در نسخه‌های موبایل و وب، یکی از نمونه‌کارهای مجموعه در همین حوزه است.
حالا تصور کنید کاربری در چنین محصولی می‌خواهد قابلیت تازه‌ای برای برنامه‌ریزی تمرین‌های روزانه داشته باشد.
اگر صرفاً درخواست را مبنای تصمیم قرار دهیم، احتمالاً به ساخت یک تقویم اختصاصی فکر می‌کنیم؛ تقویمی که کاربر بتواند تمرین‌های هفته را در آن تنظیم کند.
اما از زاویه JTBD، مسئله می‌تواند متفاوت باشد: کاربر می‌خواهد تمرین مدیتیشن را به بخشی از برنامه روزانه‌اش تبدیل کند.
با این تعریف، گزینه‌های بیشتری برای بررسی داریم. شاید یادآورهای موجود کافی باشند و فقط تنظیمشان دشوار باشد. شاید کاربر به یک برنامه پیشنهادی ساده نیاز داشته باشد. شاید هم واقعاً بخواهد تمرین‌هایش را با تقویم شخصی هماهنگ کند.
برای تصمیم‌گیری، می‌توانیم ابتدا بررسی کنیم کاربران چقدر از یادآورهای فعلی استفاده می‌کنند، آیا پس از دریافت یادآوری تمرین را شروع می‌کنند و کدام مرحله باعث رهاشدن فرایند می‌شود.
اگر شواهد نشان بدهند که امکانات فعلی مسئله را حل نمی‌کنند، آن‌وقت ساخت یک قابلیت جدید توجیه پیدا می‌کند.
در چنین شرایطی، بهتر است پیش از توسعه کامل، راه‌حل انتخابی را در قالب یک نمونه اولیه یا Prototype با کاربران آزمایش کنیم. هدف این است که بفهمیم آیا راه‌حل واقعاً انجام کار را آسان‌تر می‌کند یا فقط قابلیت دیگری به محیط نرم‌افزار اضافه خواهد شد.
اولویت‌بندی قابلیت‌های محصول؛ کدام درخواست زودتر بررسی شود؟
حتی پس از شناسایی درخواست‌های معتبر، مشکل دیگری وجود دارد: منابع تیم توسعه محدود است و نمی‌توان همه امکانات را هم‌زمان ساخت.
برای همین، اولویت‌بندی قابلیت‌های محصول فقط به تعداد درخواست‌ها وابسته نیست. باید ارزش احتمالی هر قابلیت، تعداد کاربران تحت‌تأثیر، میزان اطمینان به شواهد و هزینه توسعه را هم در نظر بگیریم.
یکی از چارچوب‌های شناخته‌شده برای این کار، مدل RICE است.
مدل RICE برای اولویت‌بندی قابلیت‌ها
این مدل چهار عامل را بررسی می‌کند:
- Reach (گستره تأثیر): قابلیت موردنظر در یک بازه مشخص بر چند کاربر اثر می‌گذارد؟
- Impact (میزان تأثیر): چقدر به بهبود تجربه کاربر یا تحقق اهداف محصول کمک می‌کند؟
- Confidence (اطمینان): شواهد ما برای تخمین این اثرگذاری چقدر قابل‌اعتمادند؟
- Effort (تلاش موردنیاز): طراحی، توسعه، آزمایش و پیاده‌سازی چقدر زمان و منابع نیاز دارد؟
امتیاز نهایی از ضرب سه عامل نخست و تقسیم آن بر میزان تلاش به دست می‌آید.
این روش که در مقاله رسمی Intercom درباره مدل RICE معرفی شده، امکان مقایسه منظم‌تر گزینه‌های توسعه را فراهم می‌کند.
اما یک نکته مهم وجود دارد: مدل RICE نمی‌تواند جای نیازسنجی را بگیرد.
اگر هنوز نمی‌دانیم مسئله واقعی چیست، واردکردن چند عدد تخمینی به یک فرمول، فقط ظاهر دقیقی به حدس‌هایمان می‌دهد.
بهتر است ابتدا اعتبار نیاز را بررسی کنیم و سپس از این مدل برای مقایسه راه‌حل‌های قابل‌اجرا استفاده کنیم.
چه زمانی یک درخواست را کنار بگذاریم؟
گاهی بررسی‌ها نشان می‌دهند ساخت یک قابلیت جدید، با وجود جذابیت اولیه، تصمیم مناسبی نیست.
مثلاً ممکن است:
- فقط گروه کوچکی از کاربران به آن نیاز داشته باشند.
- هزینه نگهداری قابلیت در بلندمدت بیشتر از ارزش احتمالی آن باشد.
- قابلیت تازه، استفاده از بخش‌های اصلی محصول را پیچیده‌تر کند.
- نیاز کاربر با یک تغییر ساده در فرایند فعلی برطرف شود.
- درخواست با مسیر توسعه و اهداف اصلی محصول هماهنگ نباشد.
کنارگذاشتن چنین درخواست‌هایی لزوماً به معنی نادیده‌گرفتن مشتری نیست. گاهی نشانه آن است که تیم محصول توانسته میان نیازهای کاربران، اهداف کسب‌وکار و محدودیت‌های توسعه تعادل برقرار کند.
بعد از توسعه، چطور بفهمیم تصمیم درستی گرفته‌ایم؟
انتشار یک قابلیت جدید پایان فرایند نیست. در واقع، تازه در این مرحله می‌توانیم بخشی از فرضیه‌های اولیه را با رفتار واقعی کاربران مقایسه کنیم.
پیش از انتشار، باید مشخص کنیم انتظار داریم چه تغییری اتفاق بیفتد.
برای مثال، اگر هدف ساده‌ترکردن فرایند رزرو است، می‌توانیم نرخ تکمیل رزرو، مدت‌زمان انجام آن و تعداد خطاهای کاربران را پیش و پس از تغییر بررسی کنیم.
اگر هدف افزایش استفاده از یک قابلیت موجود است، می‌توانیم میزان استفاده از آن و تعداد درخواست‌های پشتیبانی مرتبط را دنبال کنیم.
البته افزایش یا کاهش یک شاخص همیشه نتیجه مستقیم تغییر ما نیست. تغییر ترکیب کاربران، فصل فروش، کمپین‌های بازاریابی و عوامل فنی هم می‌توانند روی نتایج اثر بگذارند. برای تصمیم‌های مهم، آزمایش کنترل‌شده یا A/B Testing می‌تواند ارزیابی مطمئن‌تری فراهم کند.
آنچه اهمیت دارد، تعیین معیار موفقیت پیش از شروع توسعه است. در غیر این صورت، احتمال دارد پس از انتشار فقط به تعداد استفاده‌ها یا بازخوردهای مثبت تکیه کنیم، بدون اینکه بدانیم مشکل اولیه واقعاً برطرف شده یا نه.
ساخت قابلیت بیشتر، همیشه به معنی ساخت محصول بهتر نیست
هر درخواست مشتری می‌تواند فرصتی برای شناخت بهتر محصول باشد، اما قرار نیست هر کدام به یک پروژه توسعه تبدیل شود.
ماجرای Microsoft Office نشان می‌دهد که گاهی قابلیت موردنظر از قبل وجود دارد و مسئله به دسترسی و تجربه کاربری مربوط است. تجربه Intercom هم یادآوری می‌کند که بعضی درخواست‌ها را می‌توان با راه‌حل‌هایی متفاوت از پیشنهاد اولیه مشتری برطرف کرد.
از همین رو، پیش از اضافه‌کردن قابلیت جدید به نرم‌افزار، باید سه چیز را روشن کنیم: کاربر دقیقاً چه کاری می‌خواهد انجام دهد، چه چیزی مانع او شده و کدام راه‌حل با کمترین پیچیدگی می‌تواند مشکلش را برطرف کند.
محصول خوب قرار نیست فهرستی بلند از امکانات داشته باشد. ارزش محصول در این است که کاربران بتوانند کارهای مهمشان را با اطمینان، سرعت و کمترین اصطکاک انجام دهند.
و بعضی وقت‌ها، بهترین تصمیم تیم توسعه درباره یک قابلیت جدید، این است که اصلاً آن را نسازد.
برای توسعه محصولتان از کجا شروع کنید؟
اگر برای ساخت یک MVP، توسعه اپلیکیشن یا نرم‌افزار اختصاصی برنامه دارید، یا می‌خواهید امکانات محصول فعلی‌تان را بازنگری کنید، شناخت نیاز واقعی کاربران می‌تواند نقطه شروع مناسبی باشد.
در تکنوراه، در کنار طراحی و توسعه محصولات دیجیتال، خدمات مشاوره فنی و CTO as a Service را هم با تمرکز بر نیازهای کسب‌وکار ارائه می‌دهیم؛ از تعریف محدوده و اولویت‌های پروژه تا انتخاب مسیر مناسب توسعه.
در جلسه مشاوره فنی رایگان ۱۵ دقیقه‌ای تکنوراه می‌توانید نیازها و چالش‌های پروژه‌تان را با تیم ما مطرح کنید و درباره مسیر مناسب شروع یا ادامه توسعه گفت‌وگو کنیم.