کشف مسئله؛ از درخواست فیچر تا فهم مسئله واقعی
در اولین مرحله از مدل دو الماس (Double Diamond)، تمرکز بر کشف مسئله (Discover) است. در این مرحله، بهجای اینکه خیلی سریع روی اولین مسئله یا راهحل تمرکز کنیم، تلاش میکنیم مسئله را از زوایای مختلف بررسی کنیم و شناخت دقیقتری از شرایط موجود به دست آوریم.
در مرحله Discover، با استفاده از مشاهده، مصاحبه با کاربران، بررسی دادهها و لاگها و شکلدادن به فرضیات مختلف، شواهد لازم برای شناخت مسئله جمعآوری میشود. سپس در مرحله Define، این یافتهها بررسی، جمعبندی و اولویتبندی میشوند تا مشخص شود کدام مسئله واقعاً ارزش حل کردن دارد.
نکته مهم این است که الماس اول نمیپرسد چه چیزی بسازیم؛ میپرسد چه مسئلهای واقعاً ارزش حل کردن دارد.
درخواست فیچر، لزوماً مسئله واقعی نیست
در بسیاری از تیمهای نرمافزاری، مسئله به شکل یک نیازمندی یا درخواست فیچر وارد تیم میشود. اما یک درخواست مشخص، لزوماً بیانکننده مسئله اصلی مشتری نیست.
برای مثال، ممکن است درخواست شود:
«تاریخچه انتقال وجه را به اپلیکیشن اضافه کنید.»
اگر مستقیماً وارد طراحی این قابلیت شویم، ممکن است تصور کنیم مسئله، نبودن تاریخچه انتقال وجه است. اما رویکرد محصولمحور ابتدا میپرسد:
«چرا کاربر به تاریخچه انتقال وجه نیاز دارد؟»
بررسی رفتار کاربران ممکن است نشان دهد که کاربران برای انتقال مجدد پول به گیرندگان قبلی، مجبورند هر بار شماره کارت مقصد را از پیامرسانها یا منابع دیگر پیدا و کپی کنند. این فرایند زمانبر است و احتمال خطا را افزایش میدهد.
در این شرایط، مسئله واقعی میتواند این باشد:
«انتقال مجدد پول به گیرندگان قبلی، برای کاربر فرایندی زمانبر و پرزحمت است.»
بنابراین، «تاریخچه انتقال وجه» تنها یکی از راهکارهای احتمالی است و نمیتوان از ابتدا فرض کرد که بهترین راهحل همین است.
منابع کشف مسئله
برای شناخت مسئله بهتر است به یک منبع واحد اکتفا نکنیم. سه منبع اصلی میتوانند در این فرایند مورد استفاده قرار گیرند:
کاربران و رفتار آنها: مصاحبه با کاربران، مشاهده رفتار، تیکتهای پشتیبانی و بازخوردهای دریافتشده.
دادهها و لاگها: بررسی Customer Journey، تحلیل قیف (Funnel Analysis) و بررسی مرحلهبهمرحله تعامل کاربر با محصول.
کسبوکار و بازار: بررسی رقبا، قابلیتهای محصولات مشابه و راهکارهای موجود در بازار.
ترکیب این منابع کمک میکند مسئله را از چند زاویه بررسی کنیم و از تصمیمگیری بر اساس یک درخواست یا یک نشانه منفرد جلوگیری شود.
از KPI فنی تا تجربه کاربر
یکی از وظایف مهم مدیر محصول، ایجاد ارتباط میان شاخصهای فنی و رفتار و تجربه کاربر است.
در بسیاری از پروژهها و قراردادهای نرمافزاری، شاخصهایی مانند Latency، Error Rate، Availability، Uptime، TPS و زمان پاسخ API اهمیت زیادی دارند. اما اهمیت واقعی این شاخصها زمانی مشخص میشود که تأثیر آنها بر تجربه کاربر را نیز در نظر بگیریم.
برای مثال، اگر زمان پاسخ یک API افزایش پیدا کند، موضوع فقط یک مشکل فنی نیست. وقتی پاسخ با تأخیر نمایش داده شود، ممکن است کاربر تصور کند برنامه متوقف شده یا درخواست او انجام نشده است. در نتیجه، احتمال دارد همان درخواست را دوباره ارسال کند.
تکرار این درخواستها میتواند بار سیستم را افزایش دهد و در صورت مدیریت نشدن صحیح، حتی به ایجاد تراکنشهای تکراری و کاهش اعتماد کاربر منجر شود.
بنابراین، یک KPI فنی میتواند مستقیماً بر رفتار کاربر و کیفیت تجربه او تأثیر بگذارد.
مدیر محصول باید بتواند ارتباط میان این چهار حوزه را درک کند:
KPI فنی، تجربه کاربر، رفتار کاربر و نتیجه کسبوکار
در کنار شاخصهای فنی مانند زمان پاسخ، نرخ خطا و پایداری، شاخصهایی مانند سرعت ادراکشده، نرخ موفقیت کاربر، رضایت، اعتماد و میزان اقدامات تکراری نیز برای ارزیابی کیفیت واقعی محصول اهمیت دارند.
در نهایت، مدیر محصول باید میان تیم فنی، تیم تجربه کاربر و تیم کسبوکار ارتباط مؤثری ایجاد کند.
ارزش واقعی زمانی ایجاد میشود که بتوانیم KPIهای فنی را به KPIهای تجربه کاربری متصل کنیم، تأثیر آنها را بر رفتار کاربر درک کنیم و ارتباط آنها با نتایج کسبوکار را ببینیم.