خبر تأییدشده
GitHub در ۲۸ اکتبر مدل تازه‌ای برای مشتریان Enterprise Cloud دارای تیم حساب GitHub یا Microsoft اعلام کرد: کاربران دارای مجوز Enterprise می‌توانند دسترسی Copilot را در همان طرح دریافت کنند. این دسترسی اعتبار ماهانه AI به‌ازای صندلی ندارد و مصرف از نخستین درخواست از بودجه سازمان محاسبه می‌شود. پیشنهاد تکمیل کد و ویرایش بعدی بدون بودجه نیز فعال می‌ماند، اما Chat، code review و اجرای ابری به بودجه نیاز دارند. دسترسی self-service هنوز عمومی نشده و اشتراک‌های فعلی آن تغییر نمی‌کنند. طرح‌های Copilot Business و Enterprise نیز همچنان قابل خریدند. بنابراین «دسترسی گنجانده‌شده» نباید با «مصرف نامحدود رایگان» اشتباه شود.
تحلیل مستقل IROSG
برای مدیر فناوری، مسئله اصلی این تغییر انتقال تمرکز از تعداد صندلی به الگوی مصرف است. در مدل مبتنی بر صندلی، هزینه پایه معمولاً با تعداد افراد قابل پیش‌بینی‌تر است؛ در مدل مصرفی، نوع کار و شدت استفاده نقش بیشتری پیدا می‌کند. تحلیل ما این است که تصمیم درباره مهاجرت باید براساس صورت‌حساب و رفتار واقعی تیم انجام شود، نه صرفاً سادگی عنوان تجاری طرح.
یک روش ارزیابی، جداکردن کاربران کم‌مصرف، کاربران روزمره و گردش‌کارهای خودکار است. میانگین مصرف کل ممکن است هزینه یک فعالیت پرتکرار را پنهان کند. برای نمونه، بررسی خودکار تعداد زیادی تغییر می‌تواند الگوی هزینه متفاوتی از گفت‌وگوی تعاملی چند برنامه‌نویس داشته باشد. برآورد سازمان باید شامل سناریوی عادی، دوره انتشار پرکار و رشد احتمالی تعداد پروژه‌ها باشد.
توصیه تحریریه این است که پیش از تغییر قرارداد، مسئول بودجه و مسئول بهره‌برداری درباره رفتار هنگام اتمام بودجه توافق کنند. توقف یک قابلیت در میانه روز کاری می‌تواند اثر عملی بیشتری از مبلغ صورت‌حساب داشته باشد. وجود هشدار زودهنگام، مسیر پاسخ‌گویی و اطلاع‌رسانی روشن به تیم کمک می‌کند محدودیت مصرف به یک اختلال غافلگیرکننده تبدیل نشود. این‌ها الزامات پیشنهادی برنامه‌ریزی‌اند، نه توصیف قراردادی اضافه بر اطلاعیه.
نکته دیگر، تفکیک دسترسی فنی از اختیار مصرف است. داشتن حساب فعال لزوماً به معنی مجازبودن هر نوع پردازش داده سازمان نیست. قواعد طبقه‌بندی اطلاعات، انتخاب مدل و استفاده از ابزارهای متصل همچنان باید برای کارکنان قابل فهم باشند. تغییر روش پرداخت فرصت خوبی برای بازبینی این قواعد است، ولی نباید موجب شود تیم همه سیاست‌های موجود را بدون نیاز بازنویسی کند.
برای مقایسه منصفانه گزینه‌ها، هزینه باید به یک خروجی معنادار وصل شود: مثلاً تغییر پذیرفته‌شده یا زمان صرفه‌جویی‌شده قابل اندازه‌گیری. این سنجه نیز باید با کیفیت همراه باشد؛ ارزان‌ترشدن تولید پیش‌نویس اگر زمان بازبینی را افزایش دهد ممکن است سود مورد انتظار را از بین ببرد. تصمیم مناسب برای هر سازمان به ترکیب کاربران، حساسیت پروژه‌ها و بودجه قابل تحمل بستگی دارد. شرایط نهایی خرید و زمان دسترسی باید از تیم حساب و اسناد جاری GitHub تأیید شود.
برای دوره آزمایشی می‌توان بودجه هر پروژه را با مالک مشخص ثبت کرد و پیش از گسترش استفاده، هزینه واقعی چند هفته را با فرض اولیه مقایسه کرد؛ اختلاف این دو، ورودی تصمیم بعدی خواهد بود.
