آیا PMها باید با ایجنتها کد بزنن؟
هوش مصنوعیخلاصهٔ کاملتر
نویسنده با این جمله شروع میکنه که همه ذوقزده شدن چون یهو میتونن کد بزنن، ولی نکته اصلی رو کامل از دست دادن. ایجنتهای کدنویسی اومدن، ساختن نرمافزار یهشبه ارزون شد و یه موج راه افتاد: حالا PMها هم میتونن محصول بفرستن، کسبوکار میتونه پروتوتایپ بزنه، انگار همه شدن مهندس. ولی به گفته نویسنده تقریباً هیچکس نپرسید تنها سؤالی که واقعاً مهمه: اگه میشه هر چیزی رو ساخت، چی رو باید بسازیم؟
استدلال اصلی اینه که تصمیمگیری درباره اینکه چی ساخته بشه، همیشه یه گلوگاه بزرگ بوده — به اندازه خودِ نوشتن کد پرهزینه. فقط چون تولید نرمافزار کند و گرون بود، این هزینه پنهون میموند و تو تایملاین حل میشد. حالا که تحویل سریع شده، اون مه داره کنار میره و چیزی که زیرش بوده زشته. نویسنده میگه هر چقدر هم AI بریزی تو تیم توسعه، اگه گلوگاه contextـیه که تو یه تیکت Jira گیر افتاده، فایدهای نداره؛ خودِ سازمان گلوگاهه.
نویسنده از «تیکت دوخطی» بهعنوان نشونه یه مدل عملیاتی خراب یاد میکنه: یه تسک مبهم با یکی دو جمله که از طرف «کسبوکار» میاد، بدون توضیح مسئله و بدون اینکه معلوم باشه کی این مشکل رو داره و چرا مهمه. تو این مدل، «کسبوکار» فکر میکنه، PM ترجمه میکنه و توسعهدهندهها تحویل میدن — یه خط مونتاژ که تو هر دستبهدست شدن، context بخار میشه و توسعهدهنده اصلاً به آدم واقعیِ صاحبِ مسئله نزدیک نمیشه.
به نظر نویسنده، توسعهدهندهای که کاربر رو بفهمه میتونه فرصتهایی رو ببینه که هیچکس دیگه نمیبینه، چون اون فرصتها تو چیزای از نظر فنی ممکن زندگی میکنن. وقتی همه رو از کاربر جدا کنی، فقط کارو کند نمیکنی، بلکه توانایی کل تیم برای کشف ایدههای خوب رو از بین میبری. این اتلاف همیشه بوده؛ ایجنتها فقط کاری کردن که دیگه نشه نادیدهاش گرفت.
درباره خودِ سؤال اصلی، نویسنده یه «بله» مشروط میده: ایجنت کدنویسی یه ابزار فوقالعاده برای کشفه. PMای که یه پروتوتایپ باکیفیت میسازه تا یه چیز واقعی جلوی کاربر بذاره و بفهمه مردم واقعاً چی میخوان و بابتش پول میدن، داره دقیقاً درست ازش استفاده میکنه. ولی لحظهای که PM بیفته دنبال تحویلِ فیچرِ production و بشه یه دکّون تکنفره تحویل، قضیه رو برعکس گرفته — نه چون کد بدی مینویسه، بلکه چون کمیابترین منبع شرکت رو سر کار اشتباه خرج میکنه. شعار نویسنده اینه: کشف، نه تحویل (Discovery, not delivery).
نویسنده میگه این مشکل قابلحله و آدمای باتجربه (مثل Marty Cagan) راهحلش رو نوشتن، ولی بیشتر مدیرای ارشد اصلاً خبر ندارن همچین گفتوگویی وجود داره؛ فکر میکنن توسعه نرمافزار یعنی فقط تحویل: تیکت تو، فیچر بیرون. در آخر هم یه توصیه شخصی داره: اگه هر روز داری چیزایی میسازی که کسی نمیخواد، شرکتهایی رو پیدا کن که این کارو درست انجام میدن و دنبال تأثیر برو، نه سقف حقوق.
نکات کلیدی:
- با ارزون شدن ساختِ نرمافزار، گلوگاه واقعی از «تحویل» به «تصمیمِ اینکه چی بسازیم» منتقل شده
- تیکتهای دوخطیِ مبهم نشونه یه مدل عملیاتیِ خرابن که context رو تو هر دستبهدست شدن نابود میکنن
- استفاده درستِ PM از ایجنت، پروتوتایپزدن برای کشفِ نیاز کاربره، نه تحویلِ فیچر production
- جدا کردن تیم از کاربر، توانایی کشف ایدههای خوب رو از بین میبره
- شعار جمعبندی: کشف، نه تحویل (Discovery, not delivery)
