چرا بودجهبندی نرمافزار بهصورت پروژهٔ یهبارمصرف شکست میخوره
خلاصهٔ کاملتر
نویسنده، Rich Mironov، که این مطلب رو بازگویی یه «غرغر قدیمی» خودش میدونه، استدلال میکنه سازمانهایی که ساخت نرمافزارو مثل یه پروژهٔ یهبارمصرف بودجه میدن، بهطور اجتنابناپذیر سرخورده میشن، به نتیجه نمیرسن، زیادی خرج میکنن و آخرش کارو دور میندازن. میگه این رو صدها بار دیده.
به گفتهٔ نویسنده، خیلی کالاهای فیزیکی وقتی ساخته و فروخته میشن «تمام» هستن؛ یه چکش وقتی از کارخونه بیرون میاد کارش تمومه و انتظار آپدیت و پشتیبانی ازش نداری. ولی بهکاربردن همین دیدگاه روی نرمافزار یه برداشت اشتباه بنیادی از طرز کار و پشتیبانی فناوریه. به همین خاطر اون شش دلیل میآره که چرا باید تیم سازنده (توسعه، محصول، طراحی، تست) رو بعد از v1.0 دستنخورده نگه داشت.
اول، همیشه برای فرستادن نسخهٔ اول نیازمندیها رو قیچی میکنیم: بعضی کاربردهای کمتکرار عقب میافتن، مقیاسپذیری ناقص میمونه و همیشه یه لیست خرید برای v1.1 و v2.0 هست. دوم، تا کاربر واقعی پولی با محصول کار نکنه نمیفهمیم چی کمه: ورودیهای غیرمنتظره، مشکل با زبونها و ارزها و منطقههای زمانی، و رفتارهایی که پیشبینی نکرده بودیم. نویسنده به نقل از Jeff Gothelf میگه با هوش مصنوعی این سختتر هم میشه، چون مشتریها قابلیتهای AI رو جوری استفاده میکنن که نمیشه پیشبینی کرد.
سوم، هر سیستمی باگ داره و نیاز به اصلاح: حتی وقتی «درست کار میکنه»، باز هم گلوگاههای کارایی، اکسپلویتهای روز صفر و قیمتگذاری خاص برای مشتری بزرگ پیش میاد؛ نویسنده میگه سیستمی بدون مهندسی نگهدارنده، ظرف چند فصل میمیره. چهارم، زیرساخت همیشه در حال تغییره: مثلاً AWS یا Salesforce یا GCP خودشون جریان دائمی آپدیت API و حذف سرویس دارن، بهعلاوهٔ مرورگرهای جدید، passkeyها، پشتیبانی MCP برای ایجنتهای AI و مقررات نوظهور EU. اسمشو بذار بدهی فنی یا آنتروپی نرمافزار، نمیشه نادیدهش گرفت.
پنجم، همیشه رؤیاها و فرصتهای جدید هست: هر کاربر و فروشنده و تحلیلگر پیشنهادی برای بهترکردن محصول داره و این فشار مقاومتناپذیره. ششم، بهترین آدمها برای تغییرهای بعدی، همونهاییان که محصولو ساختن: کسایی که از کوچکترین جزئیات و وابستگیها خبر دارن. به گفتهٔ نویسنده این تصور که «هر وقت لازم شد پیمانکار میآریم یا از تیم دیگه قرض میگیریم» اشتباهه، چون منحنی یادگیری آدمهای جدید خیلی تندتره و تیم اصلی هم اگه بره رو کار دیگه، شیش ماه بعد باید کار خودشو از نو یاد بگیره.
نویسنده میگه نیاز به سرمایهگذاری مداوم یه ویژگیه، نه باگ یا اشتباه؛ نرمافزار یه دارایی فکری مستهلکشوندهست، نه چکش. به خاطر اینکه باید هر خط کدو تا آخرین مشتری برای همیشه پشتیبانی کنیم، مدل مالی باید درآمد مداوم رو مقابل هزینهٔ مداوم (آدمها و توکنها) بذاره. مدل پیشفرض سرمایهگذاری خود نویسنده حدود ۵۰٪ انرژی R&D رو میذاره روی قابلیتهای جدید درآمدزا و ۳۵ تا ۴۰٪ روی «نگهداری و مراقبت»؛ و میگه شرکتی که کمتر از ۳۰٪ روی نگهداری بذاره رو باید نگران بود. اون اشاره میکنه برونسپاری هم چاره نیست، چون پیمانکار بیرونی که سیستم و معماری رو نمیشناسه دو برابر خرج برمیداره و همهٔ اون شش دلیل بازم سر جاشونن.
نکات کلیدی:
- نرمافزار مثل چکش با ساختهشدن «تمام» نمیشه؛ یه دارایی مستهلکشوندهست
- بودجهبندی پروژهٔ یهبارمصرف بهطور اجتنابناپذیر به بحران مالی و فنی میرسه
- تیم سازنده باید بعد از v1.0 دستنخورده بمونه، چون بهترین آدم برای تغییرها همونه
- شش دلیل: قیچیکردن نیازمندیها، نیاز واقعی کاربر، باگها، تغییر زیرساخت، رؤیاهای جدید، دانش تیم
- نویسنده پیشنهاد میده حدود ۳۵ تا ۴۰٪ R&D صرف نگهداری و مراقبت بشه
