خبر در یک نگاه
در ۶ نوامبر ۲۰۲۶، گیت‌هاب دامنه سنجش داشبورد Copilot impact را گسترده‌تر کرد. نمودار «پذیرش عامل» اکنون در کنار تجربه‌های قبلی، استفاده از Copilot Chat و پنجره VS Code Agents را نیز نشان می‌دهد؛ بنابراین این نما در مجموع به نه تجربه Copilot می‌رسد. هم‌زمان نام گروه «کاربران منفعل» به «کاربران چت‌محور» تغییر کرده است. این تغییر فقط ویرایش واژه‌ها نیست: کاربری که واقعاً با Copilot کار می‌کند اما بیشتر پرسش و پاسخ یا کار عامل‌محور انجام می‌دهد، دیگر با برچسبی گمراه‌کننده توصیف نمی‌شود. همین دو قابلیت در گزارش‌های مصرف ۲۸روزه سازمان و سازمان بزرگ نیز در فیلد copilot_feature_engagement.totals_by_feature با کلیدهای chat و vscode_agent می‌آیند.
با این حال، گیت‌هاب صریحاً می‌گوید که مرحله‌های پذیرش عوض نشده‌اند. چت و پنجره عامل VS Code برای تعامل با قابلیت اندازه‌گیری می‌شوند، اما در تعیین مرحله پذیرش نقشی ندارند. اندازه گروه‌ها نیز تغییر نمی‌کند و مقدار API برای کاربران چت‌محور همچنان No Cohort است. این تفکیک، هسته خبر است: دید سازمان درباره شیوه استفاده کامل‌تر شده، نه اینکه تعریف قدیمی بلوغ پذیرش یا نتیجه‌گیری بهره‌وری بازنویسی شده باشد.
نه تجربه را چگونه از هم تفکیک کنیم؟
عدد نه را نباید به معنای نه مرحله پذیرش یا نه شاخص بهره‌وری خواند. دو ردیف تازه، یکی chat برای استفاده‌ای است که در داده‌های متریک به Copilot Chat نسبت داده می‌شود و دیگری vscode_agent برای پنجره VS Code Agents. هفت ردیف دیگر، همان هفت قابلیت قبلی‌اند که پیش از این در گزارش‌های ۲۸روزه وجود داشتند. دو منبع رسمی مورد بررسی نام تک‌تک آن هفت قابلیت را فهرست نمی‌کنند؛ ازاین‌رو نامی برای آن‌ها جعل نمی‌کنیم. در تحلیل داده، هرکدام را یک ردیف مستقل «قابلیت قبلی ۱ تا ۷» نگه دارید، نه اینکه آن‌ها را با چت یا عامل VS Code جمع یا در یک عنوان مبهم ادغام کنید.
تفکیک عملی چنین است: ردیف چت می‌تواند کاربرانی را شامل کند که در Copilot Chat تعامل داشته‌اند، و این پوشش در متریک‌ها حالت عامل را هم دربر می‌گیرد؛ بنابراین کاربری که ویرایش عامل‌محور انجام داده، ممکن است در چت نیز شمرده شود. ردیف vscode_agent به پنجره Agents در VS Code مربوط است. هفت ردیف قدیمی برای مقایسه تاریخی باید بدون تغییر تفسیر شوند. پس اگر جمع درصد ردیف‌ها از صد درصد بیشتر شد، الزاماً خطا رخ نداده است: یک کاربر می‌تواند زیر بیش از یک قابلیت شمرده شود.
این نکته برای مدیرانی که انتظار «دسته‌های ناسازگار» دارند حیاتی است. totals_by_feature فهرستی از تعامل‌های واجد شرایط است، نه تقسیم‌بندی انحصاری افراد. در گزارش یا نمودار داخلی، عنوان ستون را «کاربران درگیر با این قابلیت» بگذارید، نه «سهم کاربران بدون هم‌پوشانی». اگر ماتریس کاربران در دسترس سازمان است، هم‌پوشانی چت و عامل VS Code را جداگانه نشان دهید؛ اگر نیست، فقط همان تعداد هر ردیف را گزارش کنید و از استنتاج درباره تعداد افراد یکتا خودداری کنید.
قاعده ۲۸ روز و آستانه دو روز
واژه «درگیر» در این تغییر معنای دقیقی دارد: کاربر باید آن قابلیت را در دست‌کم دو روز از دوره ۲۸روزه استفاده کرده باشد. یک استفاده منفرد، به تنهایی برای قرار گرفتن در شمارش تعامل آن قابلیت کافی نیست. این آستانه به تیم کمک می‌کند تفاوت میان آزمایش یک‌باره و الگوی استفاده تکرارشونده را ببیند، اما نباید آن را معیار کیفیت پاسخ، رضایت توسعه‌دهنده یا موفقیت کسب‌وکار جا زد.
برای نمونه، فرض کنید دوره گزارش از روز اول تا روز بیست‌وهشتم ماه باشد. توسعه‌دهنده «الف» در روزهای سوم و بیست‌ودوم از Chat استفاده می‌کند؛ از نظر این قاعده، در ردیف chat کاربر درگیر است. توسعه‌دهنده «ب» یک بار در روز سوم پنجره Agents را باز می‌کند؛ از این منبع نمی‌توان او را کاربر درگیر آن قابلیت دانست. توسعه‌دهنده «ج» در دو روز از چت و در سه روز از پنجره عامل استفاده می‌کند؛ می‌تواند در هر دو ردیف بیاید. این مثال‌ها درباره رفتار شمارشی‌اند، نه درباره ارزش یا امنیت کدی که تولید شده است.
دوره ۲۸روزه را با یک روز تقویمی یا با عمر مجوز اشتباه نگیرید. گزارش می‌پرسد در پنجره مشخص‌شده چه اتفاقی افتاده است. اگر مدیر در هر هفته از داده عکس بگیرد، تغییر ترکیب پنجره می‌تواند روند را جابه‌جا کند؛ بنابراین برای مقایسه، تاریخ استخراج، دامنه سازمان یا سازمان بزرگ، منطقه زمانی و نسخه خروجی را در دفترچه اندازه‌گیری ثبت کنید. داده یک روز نیز طبق مستندات، پس از بسته‌شدن آن روز و گذشت دو روز کامل UTC در دسترس قرار می‌گیرد؛ پس داده همان روز را قطعی تلقی نکنید.
«کاربر چت‌محور» یعنی چه؟
در نسخه قبلی، گروهی از کاربران فعال که هیچ قابلیت واجد شرایطی را دست‌کم دو روز در پنجره ۲۸روزه استفاده نکرده بودند، «Passive users» نام داشتند. اکنون «Chat-first users» توصیف مناسب‌تری برای این گروه است. تعریف عملی تغییر نکرده است: آنان در Copilot فعال‌اند، اما برای یک مرحله پذیرش واجد شرایط نیستند. نام تازه نباید به این معنا باشد که همه اعضای گروه الزاماً فقط چت کرده‌اند؛ متن رسمی می‌گوید این افراد در یک قابلیت واجد شرایط به آستانه لازم نرسیده‌اند.
در API نیز این گروه همچنان مقدار No Cohort دارد. بنابراین تیم داده نباید با تغییر برچسب نمای داشبورد، نگاشت API را تغییر دهد یا اندازه cohort را دوباره محاسبه کند. اگر سامانه گزارش‌ساز شما نام «Passive users» را به‌عنوان مقدار ثابت ذخیره کرده است، برچسب نمایشی را برای خوانایی اصلاح کنید، اما مقدار خام و تاریخ گزارش را حفظ کنید. در گزارش تحلیلی بنویسید «نام گروه تغییر کرده، تعریف و اندازه cohort تغییر نکرده است». این کار جلوی برداشت نادرست از رشد یا افت مصنوعی را می‌گیرد.
راه‌اندازی و روش ارزیابی دفاعی
اول، مالک Enterprise یا Organization باید مطمئن شود سیاست متریک‌های مصرف Copilot فعال است. دسترسی به این داده برای مالکان سازمان بزرگ و مدیران صورتحساب، مالکان سازمان، و نقش سفارشی‌ای که مجوز View Copilot Metrics دارد، فراهم است. دوم، دامنه بررسی را مشخص کنید: گزارش سازمان بزرگ برای تصویر کلان و گزارش سازمان برای تصمیم تیمی مناسب است. سوم، یک دوره ۲۸روزه کامل را انتخاب و صبر کنید تا تأخیر دسترسی روزانه سپری شود؛ سپس داشبورد و گزارش را با همان بازه مقایسه کنید.
چهارم، در copilot_feature_engagement.totals_by_feature وجود دو کلید chat و vscode_agent را کنترل کنید. نبودن آن‌ها الزاماً نشانه خاموش بودن قابلیت در امروز نیست؛ اگر دوره مربوط به پیش از این تغییر باشد، گزارش فقط هفت قابلیت اصلی را دارد. پنجم، برای هر یک از نه ردیف، تعداد تعامل را جدا ثبت کنید و کنار آن تعداد کاربران فعال، دوره، دامنه و زمان دریافت داده را بنویسید. ششم، یک آزمون سازگاری انجام دهید: جمع ردیف‌ها را به‌عنوان تعداد کاربر یکتا منتشر نکنید، چون هم‌پوشانی مجاز است.
ارزیابی را با سؤال شروع کنید، نه با نمودار. سؤال «آیا Chat در تیم ما وجود دارد؟» با یک شمارش پاسخ نمی‌گیرد؛ بهتر است بپرسید «آیا استفاده از Chat در دو روز یا بیشتر تکرار شده و آیا پس از آموزش روند آن تغییر کرده است؟» برای یک مداخله آموزشی، یک دوره پایه و دوره پس از آموزش را با پنجره‌های هم‌اندازه مقایسه کنید. در کنار متریک، بازخورد توسعه‌دهنده، کیفیت بازبینی، خطاهای مشاهده‌شده و زمان صرف‌شده برای کار را گردآوری کنید. مستندات رسمی نیز توصیه می‌کند الگوهای چند سیگنال را ببینیم، نه یک عدد منفرد را معیار بهره‌وری بدانیم.
تفسیر درست: تعامل، پذیرش و اثر
داشبوردهای Copilot پرسش‌های متفاوتی را پاسخ می‌دهند. پذیرش می‌پرسد چند توسعه‌دهنده دارای مجوز واقعاً از Copilot استفاده کرده‌اند؛ تعامل بسامد استفاده و قابلیت‌های مورد استفاده را می‌بیند؛ نرخ پذیرش، پذیرش پیشنهادها را دنبال می‌کند؛ خطوط کد درباره کد پیشنهادشده، افزوده‌شده یا حذف‌شده در ویرایشگر گزارش می‌دهد؛ و چرخه pull request شامل ایجاد و ادغام، زمان تا ادغام و فعالیت بازبینی است. این‌ها هم‌معنا نیستند. افزایش chat نمی‌گوید نرخ پذیرش بالا رفته، و افزایش تعامل vscode_agent به‌تنهایی ثابت نمی‌کند زمان ادغام کم شده است.
کوهورت‌ها نیز «عمق یا پهنای استفاده از قابلیت‌های واجد شرایط» را نمایش می‌دهند، نه حجم خام فعالیت. کاربری با پیشنهادهای تکمیل کد فراوان ممکن است در مرحله code-first بماند، درحالی‌که کاربری با چند سطح تجربه عامل‌محور به مرحله بعدی برسد. پس اضافه‌شدن دو ردیف تازه را با انتقال کاربران به مرحله‌های بالاتر یکی ندانید. گیت‌هاب صریحاً می‌گوید چت و پنجره عامل VS Code فقط تعامل هستند و مرحله پذیرش را تغییر نمی‌دهند.
Impact dashboard می‌تواند خروجی pull request و زمان تا ادغام را میان cohortها مقایسه کند و مقایسه‌های صنعتی یا برآورد بالقوه بازگشت سرمایه را زمینه بدهد. اما این مقایسه‌ها رابطه یا همبستگی را نشان می‌دهند، نه اثبات علیت. ترکیب تیم، پیچیدگی پروژه و تجربه افراد نیز بر نتیجه اثر دارد. ازاین‌رو جمله «چت باعث شد بهره‌وری افزایش یابد» نتیجه‌ای فراتر از داده است. جمله دفاع‌پذیرتر این است: «در دوره مورد بررسی، تعامل با چت و شاخص چرخه pull request هم‌زمان چنین الگویی داشتند؛ برای نسبت‌دادن علت، داده و طراحی ارزیابی بیشتری لازم است.»
سناریوی سازمانی پیشنهادی
یک سازمان بزرگ را در نظر بگیرید که چند سازمان محصولی دارد و می‌خواهد بداند آموزش گردش‌کار عامل نتیجه داده است یا نه. مالک ابتدا سیاست متریک و دسترسی مجاز را بررسی می‌کند، سپس یک دوره پایه ۲۸روزه می‌گیرد. در خروجی پایه، هفت ردیف قدیمی و در دوره جدید، در صورت قرارگرفتن بازه پس از تغییر، chat و vscode_agent را کنار همان هفت ردیف ثبت می‌کند. تیم نباید سازمان‌ها را برای ساختن مجموع سازمان بزرگ با هم جمع کند، زیرا یک کاربر می‌تواند عضو چند سازمان باشد و مجموع‌های سازمانی هم‌پوشانی داشته باشند.
پس از آموزش، مدیر می‌بیند کاربران در دو روز یا بیشتر با Chat درگیر شده‌اند، اما اندازه cohortهای پذیرش همان است. این یافته با خبر رسمی سازگار است و شکست آموزش را ثابت نمی‌کند؛ ممکن است افراد مسیر مکالمه‌ای را پیدا کرده باشند، درحالی‌که آن مسیر عمداً در مرحله‌های پذیرش وارد نمی‌شود. برای تصمیم بعدی، تیم از توسعه‌دهندگان می‌پرسد آیا پاسخ‌ها قابل استفاده بوده، بازبینی انسانی چگونه انجام شده و چه موانعی برای انتقال از گفت‌وگو به کار واقعی وجود داشته است. سپس تغییرات pull request را فقط به‌صورت قرینه، با توجه به پیچیدگی و ترکیب تیم، بررسی می‌کند.
اگر در همان دوره، پنجره Agents در VS Code نیز رشد کند، این دو عدد را بی‌احتیاط به‌جای هم ننشانید. منبع رسمی می‌گوید Chat شامل استفاده‌ای است که متریک‌ها از Copilot Chat ثبت می‌کنند، از جمله agent mode؛ بنابراین هم‌پوشانی مفهومی یا شمارشی میان این دو ردیف ممکن است. مدیر محصول باید بداند افزایش مجموع دو ردیف الزاماً افزایش همان مقدار در افراد یکتا نیست. برای تصمیم بودجه، روند چند دوره، داده‌های کیفیت و بازخورد افراد را کنار هم بگذارید.
حریم خصوصی و حداقل‌گرایی داده
این گزارش‌ها برای فهم پذیرش و کمک آموزشی ساخته شده‌اند، نه برای رتبه‌بندی شتاب‌زده افراد. دسترسی را به صاحبان و نقش‌هایی بدهید که مجوز رسمی لازم دارند و در گزارش اشتراکی، تا حد نیاز سازمانی داده را ارائه کنید. متریک فعالیت را با فهرست مجوز یا seat یکی نگیرید؛ مستندات می‌گوید متریک‌های مصرف، فعالیت را اندازه می‌گیرند و برای اطلاعات صندلی و مجوز باید از Copilot user management API استفاده کرد.
در نگهداری داده، شناسه گزارش، دامنه، بازه ۲۸روزه، زمان دریافت و تعریف شاخص را ثبت کنید؛ اما از افزودن نام یا جزئیات فردی به داشبورد مدیریتی بدون نیاز عملی پرهیز کنید. عدد پایین ممکن است از پوشش ناقص، خاموش بودن تله‌متری کلاینت، تأخیر داده یا تفاوت دامنه ناشی شود، نه بی‌علاقگی فرد. داده‌های Copilot ترکیبی از تله‌متری IDE، Copilot CLI و سطوح پشتیبانی‌شده است و رکورد کاملی از همه فعالیت‌ها نیست. جزئیات IDE نیز به کلاینت‌های پشتیبانی‌شده با تله‌متری فعال وابسته است؛ تله‌متری سمت سرور ممکن است فقط کاربر فعال را نشان دهد.
محدودیت‌های عدد و تاریخ
گزارش‌های پیش از این تغییر فقط همان هفت قابلیت اصلی را شامل می‌شوند. پس مقایسه دوره قبل و بعد بدون علامت‌گذاری تغییر پوشش می‌تواند اثر تغییر محصول را با اثر تغییر رفتار اشتباه کند. اگر سری زمانی دارید، نقطه ۶ نوامبر ۲۰۲۶ را به‌عنوان تغییر تعریف ثبت کنید و نتیجه را به‌صورت شکست ساختاری داده تفسیر کنید، نه الزاماً جهش واقعی استفاده. عددی که در منبع رسمی ذکر نشده، مانند درصد رشد، تعداد کاربران یا نرخ موفقیت، نباید از خودمان ساخته شود.
همچنین «در دسترس بودن داده» با «کامل بودن داده» فرق دارد. تأخیر دو روز کامل UTC را لحاظ کنید؛ گزارش سازمانی و سازمان بزرگ را در دامنه درست بخوانید؛ و برای روزهای ناقص برچسب موقت بزنید. وقتی یک کاربر در چند سازمان است، جمع‌زدن گزارش‌های سازمانی تصویر نادرستی از کل Enterprise می‌سازد. برای گزارش هیئت‌مدیره، روش محاسبه، هم‌پوشانی، پوشش سطح‌ها، زمان UTC و محدودیت علیت را کنار نمودار بیاورید.
چک‌لیست اجرایی IROSG
- تاریخ تغییر را ثبت کنید: ۶ نوامبر ۲۰۲۶، بدون ادعای انتشار نسخه‌ای که منبع نگفته است.
- فعال‌بودن سیاست Copilot usage metrics و داشتن مجوز
View Copilot Metricsرا بررسی کنید. - یک پنجره کامل ۲۸روزه و زمان دسترسی پس از دو روز کامل UTC را تعیین کنید.
- در گزارش جدید،
chatوvscode_agentرا جدا از هفت قابلیت قبلی بخوانید. - «نه تجربه» را با «نه مرحله پذیرش» یا «نه شاخص بهره‌وری» اشتباه نکنید.
- آستانه تعامل را دو روز از ۲۸ روز اعمال کنید، نه یک رویداد منفرد را.
- هم‌پوشانی افراد میان قابلیت‌ها و سازمان‌ها را مستند کنید.
Chat-first usersرا معادل جدیدPassive usersدر نمایش بدانید و مقدار API یعنیNo Cohortرا نگه دارید.- گزارش‌های قبل از تغییر را با برچسب «هفت قابلیت اصلی» مقایسه کنید.
- پذیرش، تعامل، پذیرش پیشنهاد، خطوط کد و چرخه pull request را جدا تحلیل کنید.
- برای اثر، از همبستگی به‌جای ادعای علت استفاده کنید و کیفیت و بازخورد توسعه‌دهنده را اضافه کنید.
- فعالیت Copilot را با تخصیص مجوز اشتباه نگیرید.
جمع‌بندی عملی این است: به‌روزرسانی گیت‌هاب مشاهده مدیر را دقیق‌تر می‌کند، نه اینکه به او اجازه دهد از یک شمارش ساده نتیجه امنیتی، مالی یا بهره‌وری قطعی بگیرد. اگر سازمان، تعریف‌ها، پنجره زمانی، هم‌پوشانی، پوشش تله‌متری و محدودیت علیت را هم‌زمان ثبت کند، دو ردیف تازه به جای تولید هیاهوی عددی، به پرسش‌های بهتر درباره آموزش، مسیر استفاده و تصمیم‌گیری مسئولانه کمک خواهند کرد.
