ارزش نرم‌افزار رو مدل کن، نه فقط هزینه‌شو
هوش مصنوعیخلاصهٔ کامل‌تر
جیمز شور تو قسمت چهارم مجموعه‌ش درباره سنجیدن اثر AI روی توسعه نرم‌افزار، یه قدم از خود AI فاصله می‌گیره و می‌ره سراغ یه سؤال مهم‌تر: داریم چیز درستی می‌سازیم؟ به گفته نویسنده، تیم‌ها ماه‌ها روی دقیق کردن تخمین هزینه وقت می‌ذارن ولی تقریباً هیچ فکری به ارزش خروجی نمی‌کنن. در حالی که بین هزینه و ارزش هیچ رابطه تضمین‌شده‌ای نیست: میشه بیست میلیون دلار خرج یه نرم‌افزار بی‌ارزش کرد و با دو میلیون دلار یه کسب‌وکار رو عوض کرد.
نکته جالبش درباره دوران AI ـه. اگه نوشتن کد دیگه گلوگاه نیست، پس چی هست؟ به نقل از Lee Eason، گلوگاه داره می‌ره سمت خود مشتری‌ها. یعنی مشتری فقط یه مقدار محدود فیچر جدید رو می‌تونه جذب کنه. قبلاً گرون بودن توسعه خودش اولویت‌بندی رو تحمیل می‌کرد. حالا میشه کلی کار تحویل داد، ولی ممکنه بهترین کارت لای بقیه گم بشه و اصلاً دیده نشه.
مشکل بعدی attribution هست، یعنی فهمیدن اینکه رشد فروش دقیقاً از کجا اومده. اگه بعد از یه ریلیز فروش ۱۰٪ بره بالا ولی همزمان تیم فروش و مارکتینگ هم کمپین داشتن، سهم فیچر شما چقدره؟ عدد درآمد هم ماه‌ها دیر می‌رسه. راه‌حل نویسنده اینه که ارزش رو مدل کنی نه اینکه مستقیم اندازه بگیری، و برای هر بخش مدل یه معیار جایگزین (proxy) بذاری. مثلاً از «Pirate Metrics» یعنی AARRR استفاده کنی: Acquisition، Activation، Retention، Referral و Revenue.
خود مدل یه اسپردشیته که NPV (ارزش فعلی خالص، یعنی سود سال‌های آینده که بر اساس فاصله زمانی تخفیف خورده) رو برای مثلاً پنج سال پیش‌بینی می‌کنه. دسته‌هاش اینان: فروش جدید، upsell، نگه‌داشتن مشتری، صرفه‌جویی هزینه، هزینه‌های جاری (مثل هزینه توکن یه سرویس AI) و هزینه توسعه. برای هزینه توسعه، نویسنده یه سقف خرج تعیین می‌کنه، اونو به چند مایل‌استون می‌شکنه و سر هر مرحله تصمیم می‌گیره ادامه بده یا ضررشو ببنده.
شور تعریف می‌کنه که وقتی VP مهندسی بوده، جا انداختن این روند حدود دو سال طول کشیده. بیشترش هم صرف راضی کردن آدم‌ها شده و حمایت CEO و CFO خیلی کمک کرده. نویسنده معتقده مدل حتماً غلطه، ولی به درد می‌خوره. چون فرض‌های پنهان رو میاره رو میز و میشه تیم‌ها رو تشویق کرد مدل همدیگه رو نقد کنن. بعد از تحویل هم میشه باهاش ارزش واقعی کار رو نشون داد. حتی میشه حساب کرد پروژه بدون AI چقدر خرج برمی‌داشت.
هشدارش اینه که این روش سنگینه و فقط برای پروژه‌های بزرگ مناسبه، نه باگ‌فیکس. ممکنه آدم‌ها خبرهای بد رو تو مدل قایم کنن. پس باید ازش به عنوان ابزار تصمیم‌گیری استفاده کرد، نه ابزار ارزیابی عملکرد افراد. جمع‌بندی نویسنده اینه که اولویت‌بندی نرم‌افزار در واقع همون استراتژی شرکته.
نکات کلیدی:
- بین هزینه و ارزش نرم‌افزار رابطه تضمین‌شده‌ای نیست؛ بهبود ارزش خیلی اثرگذارتر از کم کردن هزینه‌ست.
- تو دوران AI گلوگاه از نوشتن کد رفته سمت ظرفیت مشتری برای جذب فیچرهای جدید.
- به جای اندازه‌گیری مستقیم درآمد، ارزش رو با یه مدل NPV پنج‌ساله و معیارهای جایگزین مثل AARRR مدل کنین.
- هزینه توسعه رو با سقف خرج و مایل‌استون‌های «ادامه یا توقف» کنترل کنین.
- این روش فقط برای پروژه‌های بزرگه و نباید برای ارزیابی عملکرد افراد استفاده بشه.
