OKR وقتی کاربر محصولت یه ایجنت هوش مصنوعیه
هوش مصنوعیخلاصهٔ کاملتر
تو وبیناری که جف گوتلف و جاش سایدن دهم سپتامبر دربارهٔ آیندهٔ مدیریت محصول برگزار کردن، پرتکرارترین سوال از یه مدیر محصول بود: تو کتاب Who Does What By How Much? گفته شده key result حتما باید تغییر رفتار انسان رو بسنجه، حالا اگه چیزی که محصول رو مصرف میکنه به جای آدم یه ایجنت خودمختار باشه چی؟ این پست جواب بلند همون سواله.
گوتلف میگه دلیل اینکه متریکهای ایجنت شبیه نتیجه به نظر میرسن اینه که ایجنت واقعا رفتار داره: endpoint صدا میزنه، دوباره تلاش میکنه، جا میزنه، به آدم ارجاع میده. این دقت اندازهگیری وسوسهکنندهست، ولی ایجنت نیاز و بودجه نداره و روزش بهتر یا بدتر نمیشه، پس ذینفع نیست. آدمهای واقعی دو طرفشن: کسی که ایجنت رو راه انداخته و کسی که خروجیش رو باید بپذیره یا درستش کنه.
نمونهای که میزنه اینه: هدف «تبدیل شدن به لایهٔ پیشفرض رزرو برای ایجنتهای سفر»، با key resultهایی مثل رشد کالهای API از ۱.۲ به ۵ میلیون در ماه، کاهش میانهٔ زمان پاسخ از ۹۰۰ به ۲۰۰ میلیثانیه و بالا بردن نرخ درخواست موفق از ۹۲ به ۹۹ درصد. همهشون قابل اندازهگیریان و با تلاش تیم هم تکون میخورن، ولی هیچکدوم نمیگن سفر کسی بهتر شد یا نه.
بازنویسیش اینه که هر key result رو یه سطح ببری بالاتر، سمت آدمی که اینور یا اونور ایجنت وایستاده: سهم سفرهایی که مسافر بدون ویرایش قبولشون میکنه از ۴۸ به ۷۰ درصد، سهم رزروهایی که تیم پشتیبانی باید درستشون کنه از ۲۲ به ۸ درصد، و سهم مسافرهایی که بعد از اولین اشتباه ایجنت بازم رزرو خودکار رو روشن نگه میدارن از ۳۰ به ۵۵ درصد.
نویسنده میگه دستهٔ دوم سختتر ابزارگذاری میشه و همین نکتهشه. سومی رو هم از همه مهمتر میدونه، چون تکیه کردن به محصول بعد از یه شکست، آزمون واقعی اینه که آدمها باورش دارن یا نه. تست عملیش سادهست: OKR تیم رو خط به خط بخون و بپرس این معیار رفتار چه کسی رو پیشبینی میکنه. اگه تنها جواب «ایجنت» بود، اون یه معیار سلامته؛ چیز خوبیه، ولی تعریف موفقیت فصل نیست.
نکات کلیدی:
- در تعریف گوتلف و سایدن، key result باید تغییر رفتار انسان رو بسنجه، نه رفتار ماشین.
- ایجنت رفتار داره ولی نیاز و بودجه و نفع نداره، پس ذینفع حساب نمیشه.
- تعداد کال API، زمان پاسخ و نرخ موفقیت معیار سلامت سیستمن و جاشون داشبورده.
- نمونهٔ بازنویسی: پذیرش بدون ویرایش ۴۸ به ۷۰ درصد، تعمیر توسط پشتیبانی ۲۲ به ۸ درصد، ادامهٔ استفاده بعد از خطا ۳۰ به ۵۵ درصد.
- معیاری که سختتر اندازهگیری میشه معمولا همونیه که واقعا نتیجه رو نشون میده.
