پروژهای که با هدف «پلتفرم داخلی» از یک کار آخر هفتهای شروع میشود، معمولا ظرف چند سال تبدیل به تعهدی 60 نفره و هزینهٔ حدود 7.5 میلیون دلار در سال میشود — هزینهای که اغلب میان مراکز هزینه پخش شده و برای مدیران اجرایی شفاف نیست.
اعداد کلیدی برای شروع تحلیل
در مدلهای مرجع پلتفرم مانند نمونههای CNCF معمولاً به هفت تیم محصولی نیاز است: زیرساخت، عملیات، استقرار، زمان اجرا و میانافزار، پایگاهداده، امنیت و توانمندسازی توسعهدهنده. اگر هر تیم «دوپیتزایی» (۷–۹ نفر) و با چند اسکراممستر و مالک محصول در نظر گرفته شود، اندازهٔ کلی تیم حوالی 60 نفر میشود. با فرض میانگین حقوق محافظهکارانهٔ 125,000 دلار در سال برای هر مهندس، تنها حقوق سالانه حدود 7.5M دلار خواهد بود.
| سال 1 | سال 2 | سال 3 | سال 4 | سال 5 | |
|---|---|---|---|---|---|
| سالیانه | $7.5M | $7.5M | $7.5M | $7.5M | $7.5M |
| تجمعی | $7.5M | $15M | $22.5M | $30M | $37.5M |
چرا نسخهٔ «ارزان» همیشه ارزان نیست
- نسخهٔ حداقلی (MVP) آخر هفتهای: کنترلپلن ساده با چند فایل YAML و یک تیم کوچک که نسخهٔ اولیه را منتشر میکند؛ بهسرعت به بار نگهداری تبدیل میشود.
- نسخهٔ عملیاتی: پلتفرمی که قابلیت تداوم و مقیاس داشته باشد نیازمند سازمان مهندسی محصول با حدود 60 نفر است؛ این هزینهٔ ثابت و بلندمدت ادامه مییابد.
- بار نگهداری توزیعشده: هزینهها در مراکز مختلف و زیرعنوان «مهندسی» ثبت میشوند و هنگام تصمیمگیری کلی نادیده گرفته میشوند.
ساختار نیروی انسانی برای سازمانهایی که پلتفرم را میخرند
شرکتهایی که از پلتفرمهای تجاری استفاده میکنند معمولاً تیمهای کوچکتری برای راهبری نگه میدارند؛ چون دیگر نیازی به ساخت مداوم نیست و تمرکز بر عملیات، ارتقاء و یکپارچهسازی است. نسبتهای مشاهدهشده در میدان عبارتاند از:
- بر حسب توسعهدهنده: 6,500 توسعهدهنده / 16 نفر عملیات، 2,500 توسعهدهنده / 5 نفر عملیات، 1,200 توسعهدهنده / 6 نفر عملیات
- بر حسب تیمهای اپلیکیشن: 45 تیم اپلیکیشن / 5 نفر عملیات، 300 تیم اپلیکیشن / 4 نفر عملیات
- بر حسب اپلیکیشنها: 350 اپ / 7 نفر عملیات، 300 اپ / 8 نفر عملیات
این تیمها بهجای توسعهٔ مداوم زیرساخت، روی APIها، یکپارچگیها، چارچوبهای توسعهدهنده، خطوط لولهٔ امنیتی، داشبوردها، ابزارهای ارتقا و قابلیتهای جدید مثل هوش مصنوعی کار میکنند. برای نمونهٔ صنعتی میتوانید اسناد و راهکارهای VMware Tanzu را مطالعه کنید.
هزینههای پنهان که اغلب نادیده گرفته میشوند
- گروههای سایهٔ مهندسی: در هر تیم توسعه معمولاً یک یا چند نفر بهصورت غیررسمی رابط بین اپلیکیشن و پلتفرم هستند؛ این افراد و زمانصرفشده معمولاً در برآورد اولیه محاسبه نمیشود.
- یکپارچهسازی خطوط ساخت و استقرار: همگامسازی اپلیکیشنها با ابزار پلتفرم مستلزم فعالیت چند نفر از تیمهای محصول است؛ هزینه و زمان این کار اغلب پراکنده ثبت میشود.
- پشتیبانی از انطباق و امنیت: حسابرسیها، مقررات و نیازمندیهای تطبیقی متغیرند و بار اضافی سالیانه روی تیم پلتفرم ایجاد میکنند.
علت پنهان ماندن هزینهها
هزینهٔ خرید یک پلتفرم تجاری بهصورت یک ردیف آشکار در سفارش خرید دیده میشود؛ اما هزینهٔ ساخت داخلی بهعنوان دستمزدها و سربار در چند مرکز هزینه پخش میشود و مانند استخدام عادی جلوه میکند. بنابراین معمولاً هیچکس مجموعِ هزینهها را با یک محاسبهٔ ساده نمیبیند و عدد کل پنهان میماند.
انگیزههای شغلی و «توسعهٔ مبتنی بر رزومه»
مهندسانی که برای ارتقا یا حرکت شغلی پاداش میگیرند، انگیزهٔ ساخت قابلیتهای جدید و استفاده از فناوریهای نو دارند تا آنها را در رزومه ذکر کنند. این رفتار، که به «توسعهٔ مبتنی بر رزومه (résumé-driven development)» مشهور است، گاهی منجر به انتخاب فناوریهایی میشود که برای نگهداری و عملیات بلندمدت مناسب نیستند و هزینهٔ اضافی ایجاد میکنند.
چکلیست تصمیمگیری: ساخت یا خرید
- مقیاس: تعداد توسعهدهندگان و اپلیکیشنها را بسنجید؛ آیا نسبتهای مشاهدهشده نشان میدهد خرید اقتصادیتر است؟
- سرعت به بازار: آیا زمان لازم برای توسعهٔ پلتفرم با اهداف کسبوکارتان همراستا است؟
- هزینهٔ پنهان: گروههای سایه، هزینههای یکپارچهسازی و توزیعشدن هزینهها در واحدها را محاسبه کنید.
- منابع انسانی و انگیزهها: آیا ساختِ مداوم در سازمان تشویق میشود و این امر ممکن است شما را از راهبرد عملیاتی منحرف کند؟
- تعهد بلندمدت: آیا آمادهاید سالانه 60 نفر و هزینههای جانبی را تا زمان نامعلوم تأمین کنید؟
گام بعدی پیشنهادی
یک مدلسازی پنجساله شامل همهٔ مراکز هزینه انجام دهید: حقوق مستقیم، هزینههای سربار، هزینهٔ فرصت تیمهای اپلیکیشن و هزینههای نگهداری. اگر مدل نشان دهد ساخت داخلی منجر به هزینهٔ ثابت و بالا میشود، خرید پلتفرم تجاری و نگهداری تیمهای کوچک عملیاتی معمولاً از نظر مالی و عملیاتی مناسبتر است.
تصمیم درست وقتی حاصل میشود که همهٔ هزینهها گردآوری و شفاف شوند، نه اینکه پراکنده در صفحات مختلف حسابداری باقی بمانند. شفافسازی اعداد و درک انگیزههای سازمانی کلید انتخاب میان ساخت یا خرید است.
