اگر امروز یک مدیر محصول هستید، احتمالاً متوجه شدهاید که سرعت عرضه ویژگیهای جدید به شدت بالا رفته، اما نرخ استفاده از آنها ثابت مانده یا حتی کاهش یافته است. این تضاد، نتیجهی مستقیم ورود ابزارهای کدنویسی هوشمند به چرخه تولید است.
طبق پژوهشی روی بیش از ۱۰۰ هزار توسعهدهنده در گیتهاب (GitHub)، ابزارهای کدنویسی هوش مصنوعی فعالیت برنامهنویسان را تا ۱۸۰٪ افزایش دادهاند. با این حال، در حالی که تعداد نسخههای منتشر شده حدود ۳۰٪ رشد کرده، میزان استفاده کلی در چهار بازار اصلی اپلیکیشن، ثابت مانده یا افت کرده است. این وضعیت یک عدم تعادل خطرناک ایجاد میکند: نرمافزارها سریعتر از آنکه انسانها بتوانند بهطور معنادار از آنها استفاده کنند، عرضه میشوند.
تصور کنید در یک فروشگاه دیجیتال هستید که هر ساعت قفسههای جدیدی اضافه میشود، اما تعداد خریداران تغییری نمیکند. نتیجه این اتفاق، ایجاد ارزش بیشتر نیست؛ بلکه تجربهای شلوغ و پراکنده است که در آن کاربر برای یافتن نیاز واقعیاش دچار سردرگمی میشود. در چنین دنیایی، نقش مدیر محصول از یک «رویاپرداز برای ویژگیهای جدید» به یک «کارآگاه برای تحلیل رفتار» تغییر میکند.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، سرعت در دنیای هوش مصنوعی همیشه با کیفیت یا پذیرش همراستا نیست. اکنون چرخههای توسعه از هفته به روز کاهش یافتهاند. دستیارهای کدنویسی و ابزارهای تست خودکار به تیمها اجازه میدهند یک ایده را تقریباً در لحظه به نمونه اولیه تبدیل کنند. این شتاب، فرصتهای تست و عرضه را زیاد میکند، اما به همان اندازه سرعت یادگیری و تصمیمگیری را نیز میطلبد. این تغییر در پارادایم تولید، ما را به سمتی میبرد که در آن حاکمیت دادهها به جای سرعت صرف در کدنویسی، اولویت اصلی تیمهای هوش مصنوعی قرار گیرد.
به نقل از گزارشهای تحلیل داده، اگر سرعت یادگیری با سرعت توسعه همگام نشود، کاربران در میان انبوهی از ویژگیهای جدید و «بهبودهایی» غرق میشوند که شاید هرگز آنها را نخواستهاند یا حتی تجربه کاربریشان را بدتر میکند. خطر اصلی این است که تیمهای محصول ماهها وقت صرف شکل دادن به یک ویژگی کنند، اما مشتریان عملکرد اصلی را نادیده بگیرند و از مسیری فرعی استفاده کنند که تیم توسعه حتی متوجه آن نشده است.
علاوه بر این، این سرعت باعث ایجاد اصطکاک میشود. وقتی یک تیم دستیار هوش مصنوعی اضافه میکند و تیم دیگر همزمان روی سیستم پیشنهاددهنده یا رابط کاربری جدید آزمایش میکند، تجربه کاربر تکهتکه میشود. مشتریان مجبورند میان چندین ایده متضاد دستوپا بزنند و محصول در نهایت بیش از حد شلوغ به نظر میرسد.
برای بقا در این شتاب، تیمها به ابزارهای تحلیل محصول مانند میکسپانل (Mixpanel) روی آوردهاند تا شکاف بین «عرضه» و «یادگیری» را پر کنند. هدف این است که «نویز» از «روتین» تفکیک شود؛ یعنی بدانیم کدامیک از ویژگیهای عرضه شده واقعاً جایگاهی در عادت روزانه مشتری پیدا کرده است.
برای مثال، یک دستیار خرید هوشمند در یک فروشگاه آنلاین را در نظر بگیرید. این ابزار ممکن است دقیقاً طبق برنامه به سوالات پاسخ دهد، اما یادگیری واقعی زمانی شروع میشود که تحلیل کنیم مشتریان واقعاً چه میکنند. تعداد بالای تعاملات لزوماً نشانه موفقیت نیست؛ دادهها ممکن است نشان دهند که:
- مشتریان یک سوال را تکرار میکنند چون پاسخ هوش مصنوعی مبهم است.
- کاربران تنها زمانی دستیار را باز میکنند که جستوجوی استاندارد شکست خورده باشد.
- گفتگوها به دلیل اصطکاک فنی یا تجربه کاربری ضعیف، ناگهان قطع میشوند.
- تفاوتهای عمیقی در نحوه استفاده مشتریان قدیمی در برابر بازدیدکنندگان جدید وجود دارد.
در مقابل، نرخ پذیرش پایین ممکن است پذیرفتنی باشد، اگر آن تعداد کم از کاربران، نرخ تبدیل بالاتری داشته باشند. تحلیلهای محصول نشان میدهند که آیا ویژگی جدید به کاربر کمک کرده تا پیش برود یا او را به مسیری غیرمنتظره فرستاده است. این دادهها، شواهد عینی برای تصمیمگیری مدیران فراهم میکند.
تیمهای محصول اکنون باید بر اساس زمانبندی انتشار، سوالات متفاوتی بپرسند. اولویتها باید با بلوغ ویژگی تغییر کند:
- چند روز اول: تمرکز بر شناسایی شکستهای فنی، گردشهای کاری خراب و تعاملات گیجکننده.
- چند هفته بعد: تغییر تمرکز به این موضوع که آیا استفاده از ویژگی تکرار میشود و آیا به یک نتیجه تجاری منجر شده است یا خیر.
پرسیدن سوالات روز اول در هفته ششم، هیچ ارزشی ندارد. سوال حیاتی این نیست که «آیا کاربر از ابزار استفاده کرد؟»، بلکه این است که «کاربر قصد انجام چه کاری داشت، آیا ابزار به او کمک کرد و آیا پس از فروکش کردن کنجکاوی اولیه، دوباره بازگشت؟»
خودِ هوش مصنوعی نیز در مدیریت این حجم از داده کمک میکند. مدلها میتوانند تغییرات غیرعادی در رفتار کاربران را در مجموعههای عظیم داده شناسایی کنند و زمان یافتن سیگنالهای مهم را کاهش دهند. با این حال، دادهها نمیتوانند خودشان را تفسیر کنند. کاهش استفاده از یک ویژگی میتواند به معنای خرابی یک مسیر باشد، یا برعکس، به این معنا باشد که تیم با موفقیت یک مرحله غیرضروری را حذف کرده است. در نهایت، افرادی که محصول و کاربرانش را میشناسند باید معنای این تغییرات را تفسیر کنند.
با گسترش شکاف بین عرضه و بررسی، جلسات فصلی در حال منسوخ شدن هستند. اگر نرمافزار هر هفته تغییر میکند، بررسیهای سه ماهه باعث میشود بخش بزرگی از رفتار مشتریان نادیده بماند. مدیران محصول نیاز دارند تغییرات مهم را پیش از آنکه بستر زمانی انتشار محو شود، دریافت کنند.
این امر مستلزم فرهنگی است که در آن افراد مالک نتایج خاص باشند و بتوانند به راحتی رفتارهای مرتبط را بررسی کنند. با استفاده از فناوریهای هوش مصنوعی برای هدایت توجه به سمت تغییراتی که ارزش بررسی دارند، مدیران میتوانند زمان خود را روی مواردی متمرکز کنند که واقعاً شایسته بررسی دقیق هستند.
به همین دلیل، بهترین تیمهای محصول کسانی هستند که حاضرند نظرشان را تغییر دهند. آنها از شواهد برای پرسیدن سوالات سخت استفاده میکنند: آیا این ویژگی باید سرمایهگذاری بیشتری دریافت کند؟ آیا یک تغییر کوچک میتواند اصطکاک را در یک نقطه بحرانی حذف کند؟ آیا این آزمایش پیچیدگیهایی اضافه کرده که مشتریان هرگز نخواستهاند؟
هرچه نرمافزار سریعتر عرضه شود، تیم باید سریعتر فرضیات خود را به چالش بکشد. برای هر کسی که محصولات مبتنی بر هوش مصنوعی عرضه میکند، مهمترین تصمیم این است که آیا حاضر است بر اساس دادههای پس از عرضه عمل کند و نظرش را تغییر دهد، پیش از آنکه تجربه کاربری بیش از حد تکهتکه و غیرقابل ترمیم شود.
گام بعدی شما
- اگر مدیر محصول هستید، به جای تمرکز بر تعداد ویژگیهای عرضه شده (Shipping Velocity)، نرخ تکرار استفاده (Retention) را در هفته دوم پس از عرضه بسنجید.
- ابزارهای تحلیل رفتار (مانند Mixpanel یا Amplitude) را با لایههای هوش مصنوعی ترکیب کنید تا نویزهای آماری را از سیگنالهای رفتاری تفکیک کنید.
- جلسات بررسی محصول را از حالت فصلی به حالت هفتگی یا دوهفتهای تغییر دهید تا با سرعت تولید کد همراستا شوید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو