تعریف مسئله؛ از پراکندگی تا انتخاب مسئله درست
در مرحله Discover، مسئله را از زوایای مختلف بررسی کردیم، شواهد جمعآوری کردیم و با چندین مسئله احتمالی مواجه شدیم. اما نمیتوانیم همه این مسائل را همزمان حل کنیم. بنابراین در مرحله دوم، یعنی Define، باید از پراکندگی فاصله بگیریم و روی یک مسئله مشخص و ارزشمند تمرکز کنیم.
در این مرحله، یافتههای بهدستآمده را ترکیب و اولویتبندی میکنیم تا بتوانیم مسئلهای را انتخاب کنیم که واقعاً ارزش تمرکز و حل کردن داشته باشد.
یک Problem Definition خوب چه ویژگیهایی دارد؟
برای مثال، مسئله زیر را در نظر بگیرید:
«کاربرانی که به گیرندگان قبلی انتقال وجه تکراری دارند، برای یافتن و ورود مجدد اطلاعات مقصد زمان و تلاش زیادی صرف میکنند. این اصطکاک احتمال خطا و رها کردن فرایند را افزایش میدهد.»
این تعریف، چند مؤلفه مهم را در خود دارد:
کاربر (User): مشخص میکند چه گروهی با مسئله مواجه است؛ در این مثال، کاربرانی که به گیرندگان قبلی انتقال وجه تکراری دارند.
زمینه (Context): مشخص میکند مسئله در چه شرایطی اتفاق میافتد؛ یعنی هنگام انتقال وجه تکراری.
نقطه درد (Pain Point): مشخص میکند کاربر دقیقاً با چه مشکلی مواجه است؛ مانند جستوجو و ورود مجدد اطلاعات مقصد.
تأثیر (Impact): نشان میدهد این مشکل چه پیامدی دارد؛ مانند افزایش احتمال خطا و رها کردن فرایند.
یک Problem Definition خوب باید مسئله را توصیف کند، نه راهحل را.
شرح مسئله باید مستقل از راهکار باشد.
اگر از همان ابتدا روی یک راهحل مشخص تمرکز کنیم، ممکن است بهجای دفاع از مسئله واقعی، در ادامه صرفاً از راهکاری که انتخاب کردهایم دفاع کنیم.
از «چه چیزی بسازیم؟» تا «چه مسئلهای را حل کنیم؟»
در رویکرد سنتی و فیچرمحور، معمولاً تیم کسبوکار یک قابلیت مشخص را درخواست میکند و تیم فنی بر نحوه پیادهسازی آن تمرکز میکند:
کسبوکار: این فیچر را میخواهم.
تیم فنی: چگونه آن را بسازیم؟
اما در تفکر محصولی، سؤالها متفاوت هستند:
کسبوکار: این فیچر را میخواهیم.
تیم محصول: با این فیچر قرار است چه مسئلهای را حل کنیم؟
تیم محصول: چه شواهدی داریم که این مسئله واقعاً وجود دارد؟
تیم محصول: این مشکل برای چه کاربرانی و در چه موقعیتی اتفاق میافتد؟
برای پاسخ به این پرسشها میتوان از منابع مختلفی مانند تیکتهای پشتیبانی، لاگها، دادههای محصول، مصاحبه با کاربران و مشاهده رفتار آنها استفاده کرد.
وقتی مسئله را بهدرستی میفهمیم، احتمال اینکه راهحل مناسبتری پیدا کنیم افزایش پیدا میکند.
فرصت هوش مصنوعی برای تیمهای مهندسی
در گذشته، فرض بر این بود که نیازمندی بهطور کامل تحلیل شده و آماده پیادهسازی است. امروز با کمک هوش مصنوعی، اگر یک نیازمندی واقعاً دقیق و کامل باشد، بخش قابلتوجهی از فرآیند پیادهسازی آن میتواند بسیار سریعتر انجام شود.
بنابراین، هوش مصنوعی در کنار تهدیدهای خود، یک فرصت مهم نیز برای تیمهای مهندسی ایجاد کرده است:
بهجای اینکه فقط سریعتر فیچر بسازیم، دامنه فعالیت خود را گستردهتر کنیم و در کشف و فهم مسئله نیز نقش فعالتری داشته باشیم.
هدف نهایی نباید صرفاً افزایش سرعت توسعه باشد؛ بلکه باید استفاده از این ظرفیت برای ساخت محصولات بهتر و حل مسائل واقعی کاربران باشد.