معیار ظرفیت تیم وقتی AI بهره‌وری را تغییر می‌دهد

ظرفیت تیم دقیقاً چیست؟

ظرفیت در برنامه‌ریزی معمولاً به مقدار کاری اشاره می‌کند که یک تیم در یک بازه می‌تواند تحویل دهد. اما «تحویل» باید تعریف داشته باشد. یک branch، یک draft، یک پاسخ مدل یا یک pull request بازشده الزاماً outcome یا Increment قابل‌استفاده نیست. اگر کار هنوز نیازمند review، تست، اصلاح، permission یا تصمیم release است، بخشی از ظرفیت تیم همچنان مصرف نشده و بخشی هم به مرحلهٔ بعد منتقل شده است.

برای همین سه مفهوم را جدا می‌کنم. ظرفیت gross مقدار activity تولیدشده است. ظرفیت قابل‌اعتماد مقدار کاری است که تا Definition of Done یا quality bar واقعی رسیده است. ظرفیت outcome مقدار تغییری است که برای کاربر یا کسب‌وکار ایجاد شده و شواهدی برای آن داریم. AI می‌تواند اولی را سریع زیاد کند، اما تصمیم دربارهٔ دومی و سومی به workflow کامل وابسته است.

این تفکیک در تیم‌های کوچک مهم‌تر است چون یک نفر ممکن است هم تولیدکننده، هم reviewer، هم owner انتشار و هم پاسخ‌گوی incident باشد. اگر Agent خروجی بیشتری تولید کند، ولی همان نفر مجبور شود همه‌چیز را با عجله بررسی کند، ظرفیت قابل‌اعتماد بالا نرفته است؛ فقط فشار از تولید به کنترل منتقل شده است.

• Gross capacity: چه مقدار activity یا خروجی اولیه تولید شد؟
• Reliable capacity: چه مقدار تا quality bar و Definition of Done رسید؟
• Outcome capacity: چه مقدار نتیجهٔ قابل‌استفاده برای کاربر یا کسب‌وکار ساخت؟
• Review capacity: تیم چقدر توان بررسی و اصلاح خروجی جدید را دارد؟
• Learning capacity: تیم چقدر فرصت فهم failure و بهترکردن workflow را دارد؟

سه خبر جدید چه چیزی را دربارهٔ measurement نشان می‌دهند؟

در ۱۸ سپتامبر، GitHub بهبودهایی برای Copilot Code Review اعلام کرد: مرور جدید یافته‌ها را به موارد باز، حل‌شده از review قبلی و مواردی که بعداً پیدا شده‌اند تفکیک می‌کند؛ پاسخ به comment و commitهای بعدی هم در resolve شدن یافته‌ها اثر دارد و برای batch suggestionهای پذیرفته‌شده commit message ساخته می‌شود. برداشت عملی من این نیست که review خودکار جای reviewer را می‌گیرد. برداشت این است که خود review یک جریان چندمرحله‌ای است و باید در ظرفیت تیم دیده شود.

در ۱۷ سپتامبر، داشبورد impact، engagement قابلیت‌ها را برای دورهٔ ۲۸روزه نشان می‌دهد. این گزارش می‌پرسد چند کاربر فعال، یک feature را در دست‌کم دو روز استفاده کرده‌اند و featureها را جدا می‌کند. این با login یا یک‌بار امتحان‌کردن ابزار فرق دارد. بااین‌حال، engagement هنوز outcome نیست؛ فقط شواهدی از واردشدن قابلیت به رفتار تکرارشونده است.

همان روز، GitHub گزارش متریک‌های customizationهای Agentic CLI را گسترش داد و skill، custom agent، MCP server، slash command و plugin را پوشش داد. این داده کمک می‌کند بفهمیم کدام اجزای workflow استفاده می‌شوند، اما مثلاً تلاش برای اتصال MCP الزاماً به معنی موفقیت tool call یا ارزش محصول نیست. این مرز بین activity و outcome باید در هر داشبوردی روشن بماند.

در کنار این changelogها، مستندات GitHub دربارهٔ cloud agent نشان می‌دهد Agent می‌تواند repository را بررسی کند، plan بسازد، روی branch تغییر ایجاد کند و به سمت pull request برود. هرچه اجرای Agent به workflow واقعی نزدیک‌تر شود، نیاز به اندازه‌گیری review، approval، failure و rollback هم بیشتر می‌شود.

• خبر اول: review خودش یک جریان با open، resolved و re-review است.
• خبر دوم: usage یک‌باره با engagement تکرارشونده تفاوت دارد.
• خبر سوم: customization قابل‌اندازه‌گیری است، اما invocation مساوی value نیست.
• نتیجهٔ تحلیلی: metric باید به مرحلهٔ workflow و تصمیم مشخص وصل باشد.

چرا throughput خام بعد از AI گمراه‌کننده می‌شود؟

Throughput یا تعداد آیتم‌های تمام‌شده برای دیدن جریان کار مفید است، اما وقتی تعریف تمام‌شدن تغییر کند، مقایسهٔ قبل و بعد هم بی‌اعتبار می‌شود. اگر AI تعداد pull request را بالا ببرد ولی reviewهای باز، rollback یا defect بیشتر شود، سیستم فقط خروجی اولیهٔ بیشتری دیده است. این خروجی ممکن است حتی صف بعدی را شلوغ‌تر کند.

یکی از دام‌ها این است که تولیدکنندهٔ کار و مصرف‌کنندهٔ review یک نفر یا یک تیم نیستند. Agent می‌تواند در چند دقیقه چند تغییر پیشنهاد کند، اما reviewer باید با context، تست و تصمیم محصول آن‌ها را بررسی کند. اگر ظرفیت reviewer در مدل forecast نیامده باشد، برنامه روی یک ظرفیت خیالی بنا شده است.

دام دوم، مخلوط‌کردن اندازه و ارزش است. یک customization ممکن است زیاد استفاده شود چون دسترسی به آن آسان است، نه چون outcome خوبی می‌سازد. یک قابلیت کم‌استفاده ممکن است برای یک workflow حساس ارزشمند باشد. بنابراین تعداد invocation باید سؤال ایجاد کند، نه اینکه به‌تنهایی target مدیریت شود.

• Output بیشتر می‌تواند صف review را طولانی‌تر کند.
• Task بسته‌شده می‌تواند هنوز تا outcome فاصله داشته باشد.
• مصرف زیاد ابزار ممکن است از failure یا retry زیاد بیاید.
• عدد قابل‌مقایسه نیست مگر تعریف stage و quality ثابت مانده باشد.
• Metric باید رفتار ناخواسته و مسیر بازی‌دادن خودش را هم بررسی کند.

ظرفیت review را جدا اندازه بگیریم

در بسیاری از برنامه‌ها، زمان تولید تخمین زده می‌شود اما زمان بررسی به‌عنوان کار پنهان باقی می‌ماند. بعد از ورود AI، این خطا پرهزینه‌تر می‌شود. پیشنهاد مدل یا تغییر Agent باید از نظر correctness، امنیت، dependency، تجربهٔ کاربر و نگهداری بررسی شود. اگر این review حذف شود، ریسک به production منتقل می‌شود؛ اگر بیش از حد زیاد شود، flow می‌خوابد.

برای هر workflow بپرسید review چه نوعی است و کدام بخش را می‌توان به‌صورت نمونه‌ای بررسی کرد. یک تغییر کم‌ریسک در کد داخلی با تغییری که permission، دادهٔ شخصی یا billing را لمس می‌کند یک quality bar ندارد. AI ممکن است review اولیه را دسته‌بندی کند، اما معیار پذیرش و تصمیم نهایی باید به ریسک کار وابسته باشد.

تجربهٔ جدید Copilot Code Review از همین زاویه مهم است: open، resolved و previously missed یک وضعیت ثابت نیستند. وقتی review با commitهای جدید دوباره اجرا می‌شود، ظرفیت تیم فقط زمان review اول نیست؛ زمان فهمیدن اینکه کدام یافته واقعاً حل شده، کدام false positive بوده و کدام issue هنوز باز است هم باید دیده شود.

• زمان تا اولین review انسانی
• زمان باقی‌ماندن finding باز
• نسبت suggestion پذیرفته‌شده، اصلاح‌شده و ردشده
• re-review بعد از commit و تعداد رفت‌وبرگشت‌ها
• defect یا rollback مرتبط با خروجی Agent
• زمان صرف‌شده برای توضیح و انتقال context به reviewer

Usage، engagement و outcome را از هم جدا کنیم

Usage پاسخ می‌دهد ابزار چند بار فراخوانی شده است. Engagement می‌پرسد آیا قابلیت وارد رفتار تکرارشونده شده است. Outcome می‌پرسد آیا نتیجهٔ مهمی برای کاربر، محصول یا تیم ایجاد شده است. این سه لایه به هم مرتبط‌اند اما جای یکدیگر را نمی‌گیرند.

مثلاً ممکن است یک custom agent صدها بار start شود، ولی هر بار context ناقص بدهد و reviewer مجبور به اصلاح شود. برعکس، یک workflow ممکن است دفعات کمی اجرا شود اما زمان پاسخ به یک درخواست مهم را کم کند و کیفیت قابل‌قبولی داشته باشد. بدون تعریف outcome، dashboard فقط محبوبیت ابزار را گزارش می‌کند.

در گزارش GitHub، کاربر می‌تواند در چند feature شمرده شود و داده‌ها aggregate باشند. این برای دیدن الگوی سازمانی مفید است، اما برای نتیجه‌گیری دربارهٔ افراد یا عملکرد یک تیم کافی نیست. از نگاه حکیم، گزارش باید هم عدد را نشان دهد و هم بگوید چه چیزی را نمی‌سنجد.

• Usage: آیا قابلیت فراخوانی شده است؟
• Engagement: آیا در چند روز یا چند چرخه تکرار شده است؟
• Adoption: آیا در workflow استاندارد تیم جا افتاده است؟
• Quality: آیا خروجی با quality bar سازگار است؟
• Outcome: آیا نتیجهٔ موردنظر واقعاً بهتر شده است؟

MCP، plugin و custom agent چه باری به ظرفیت اضافه می‌کنند؟

وقتی Agent به ابزار و MCP متصل می‌شود، تیم فقط مدل را مدیریت نمی‌کند؛ connection، permission، schema، timeout، خطای ابزار و تغییر version را هم باید ببیند. متریک تلاش برای اتصال می‌تواند signal خوبی برای مشکل configuration یا علاقهٔ تیم باشد، اما نمی‌گوید نتیجهٔ هر اتصال چه بوده است.

همچنین باید از جمع‌زدن بی‌دقت metricها پرهیز کرد. GitHub توضیح می‌دهد plugin skillها زیرمجموعهٔ skillها حساب می‌شوند؛ اگر هر دو را جمع کنیم، activity را دوبار می‌شماریم. این یک جزئیات کوچک است اما نشان می‌دهد طراحی dashboard به فهم مدل داده نیاز دارد، نه فقط کپی‌کردن اعداد.

برای هر customization یک owner و یک حد نگهداری تعیین کنید. اگر تیم پنج Agent، ده plugin و چند MCP دارد اما نمی‌داند کدامشان فعال، سالم یا قابل‌اعتماد است، تعداد ابزارها به‌جای افزایش ظرفیت، tax عملیاتی ساخته است. adoption بدون ownership فقط انباشت dependency است.

• Owner و purpose هر custom agent یا skill
• آخرین زمان بررسی permission و secretها
• نسبت اتصال موفق و ناموفق MCP
• زمان و هزینهٔ نگهداری integration
• مسیر fallback وقتی customization در دسترس نیست
• شرط sunset برای ابزار کم‌استفاده یا پرخطا

یک مدل ساده برای forecast بعد از AI

برای forecast، ظرفیت اسمی تیم را با یک ضریب خوش‌بینانه بزرگ نکنید. ابتدا workflow را به stageهای قابل‌مشاهده تقسیم کنید: discovery، تولید، review، تست، approval، release و follow-up. سپس برای هر stage دادهٔ تاریخی یا یک بازهٔ عدم‌قطعیت بسازید. AI ممکن است stage تولید را کوتاه کند، اما اگر stage review و approval ثابت بماند، زمان کل به همان نسبت کم نمی‌شود.

برای تیم کوچک، یک جدول سه‌ردیفه کافی است: مقدار activity، مقدار کار قابل‌اعتماد و مقدار outcome. در هر چرخه، دلیل فاصلهٔ این سه را ثبت کنید. اگر activity بالا رفت و reliable capacity ثابت ماند، گلوگاه review یا quality است. اگر reliable capacity بالا رفت اما outcome ثابت ماند، مشکل احتمالاً priority یا محصول است. اگر outcome بهتر شد اما effort نگهداری بالا رفت، باید هزینهٔ کامل را بسنجید.

پیش‌بینی باید با سناریو انجام شود، نه یک عدد قطعی. سناریوی محتمل می‌تواند فرض کند quality bar ثابت است؛ سناریوی پرریسک افزایش rework یا review را در نظر بگیرد؛ سناریوی خوش‌بینانه فقط وقتی پذیرفتنی است که evidence چرخه‌های قبلی آن را پشتیبانی کند. این ادامهٔ همان رویکرد سناریومحور است که در مقالهٔ برنامه‌ریزی پروژه مطرح شد.

• Forecast را از stage bottleneck شروع کنید، نه از تعداد prompt.
• برای هر سناریو فرض، trigger و تاریخ بازبینی داشته باشید.
• ظرفیت review و approval را مثل ظرفیت تولید وارد plan کنید.
• عدد را با range و uncertainty گزارش کنید، نه deadline قطعی.
• بعد از هر چرخه، علت variance را به مدل تصمیم برگردانید.

داشبوردی که به تصمیم stop، adapt یا scale وصل باشد

داشبورد خوب مجموعه‌ای از عددهای زیاد نیست؛ یک صفحه برای تصمیم بعدی است. برای pilot AI، من داشبورد را با پنج بخش شروع می‌کنم: flow، quality، review، adoption و outcome. هر بخش باید فقط metricهایی را داشته باشد که اگر تغییر کنند، اقدام ما هم تغییر کند.

در flow، cycle time و waiting را ببینید. در quality، defect، regression، failure و برگشت را ثبت کنید. در review، زمان تا بررسی، findingهای باز و بار reviewer را ببینید. در adoption، engagement تکرارشونده و مسیر استفادهٔ واقعی را بسنجید. در outcome، metric محصول یا رضایت کاربر را کنار هزینه و ریسک قرار دهید.

برای هر metric یک owner و یک action threshold تعیین کنید. اگر engagement بالا رفت ولی quality پایین آمد، scale متوقف می‌شود. اگر quality ثابت ماند و waiting کم شد، می‌توان pilot را گسترش داد. اگر metricها به‌خاطر دادهٔ ناقص قابل تفسیر نیستند، وضعیت باید خاکستری بماند و تصمیم ما اول تکمیل evidence باشد.

• Flow: cycle time، waiting و handoff
• Quality: defect، regression، failure و rollback
• Review: زمان بررسی، finding باز و re-review
• Adoption: engagement، استفادهٔ تکرارشونده و coverage workflow
• Outcome: نتیجهٔ محصول، زمان پاسخ، رضایت یا هزینهٔ واقعی
• Decision: stop، adapt یا scale با owner و تاریخ بازبینی

برنامهٔ ۳۰روزه برای سنجش ظرفیت تیم

در هفتهٔ اول، یک workflow مشخص انتخاب کنید؛ مثلاً code review، آماده‌سازی تست یا بررسی issue. تعریف کنید «کار تمام‌شده» یعنی چه و baseline را از چند چرخهٔ واقعی بردارید. در همین مرحله، ابزارهای متصل، permission و reviewerهای درگیر را فهرست کنید.

در هفتهٔ دوم، AI را با scope محدود وارد کنید و activity، quality، review و زمان را جدا ثبت کنید. هنوز دربارهٔ افزایش بهره‌وری نتیجه‌گیری نکنید. هدف این هفته پیدا کردن محل تغییر و failureهای تازه است.

در هفتهٔ سوم، workflow را چند بار تکرار کنید و به‌جای مقایسهٔ خام خروجی، سه لایهٔ gross، reliable و outcome را کنار هم بگذارید. اگر داده‌ها متناقض‌اند، دلیل تناقض را بنویسید. dashboard ناقص بهتر است از dashboardی که uncertainty را پنهان می‌کند.

در هفتهٔ چهارم، تصمیم stop، adapt یا scale را با شواهد ثبت کنید. اگر scale انتخاب شد، owner، review cadence، fallback و معیار sunset را هم تعیین کنید. اگر stop انتخاب شد، artifactها و یادگیری را نگه دارید تا تیم دوباره همان آزمایش را تکرار نکند.

• روز ۱ تا ۷: انتخاب workflow، Definition of Done و baseline
• روز ۸ تا ۱۴: pilot محدود و ثبت activity، quality و review
• روز ۱۵ تا ۲۱: تکرار، مقایسهٔ reliable capacity و outcome
• روز ۲۲ تا ۳۰: تصمیم stop/adapt/scale و تعیین owner
• بعد از روز ۳۰: بازبینی ماهانهٔ metricها و هزینهٔ نگهداری

جمع‌بندی از نگاه من

AI می‌تواند دست تیم را برای تولید و بررسی بازتر کند، اما ظرفیت واقعی را باید در کل مسیر تحویل دید. اگر Agent خروجی بیشتری می‌دهد، سؤال بعدی این نیست که چند task بیشتر بسته شد؛ سؤال این است که آیا تیم توانسته همان خروجی را با quality، context، approval و outcome قابل‌اعتماد جلو ببرد.

سه خبر جدید GitHub یک مسیر خوب برای فکرکردن نشان می‌دهند: review را به‌صورت جریان ببینیم، engagement را از usage جدا کنیم و customization را اندازه بگیریم بدون اینکه آن را با value اشتباه بگیریم. این‌ها ابزار measurement هستند، نه پاسخ آماده برای هر سازمان.

برای من، معیار خوب آن است که یک تصمیم بهتر بسازد. اگر عدد فقط برای گزارش‌دادن، مقایسهٔ تیم‌ها یا اثبات موفقیت rollout تولید می‌شود، احتمالاً هنوز به capacity واقعی نزدیک نشده‌ایم. ظرفیت تیم در عصر AI یعنی مقدار کار قابل‌اعتماد و نتیجه‌ای که با مسئولیت روشن می‌توانیم جلو ببریم.

هدف این نیست که تیم همیشه بیشتر تولید کند. هدف این است که بتواند بهتر انتخاب کند، با کیفیت ثابت‌تر تحویل دهد و بداند کدام بخش از سیستم کار باید تغییر کند.

منابع اولیه برای بررسی

GitHub Changelog دربارهٔ بهبود تجربهٔ Copilot Code Review، گروه‌بندی یافته‌های باز و حل‌شده، resolve هوشمند commentها و commit message برای batch suggestion: https://github.blog/changelog/2026-09-18-copilot-code-review-an-improved-review-experience — منتشرشده در 2026-09-18 و بررسی‌شده در 2026-09-20.

GitHub Changelog دربارهٔ اضافه‌شدن feature engagement به Copilot impact dashboard، دورهٔ rolling ۲۸روزه و تفکیک featureها: https://github.blog/changelog/2026-09-17-copilot-impact-dashboard-now-shows-feature-engagement — منتشرشده در 2026-09-17 و بررسی‌شده در 2026-09-20.

GitHub Changelog دربارهٔ ورود متریک skill، custom agent، MCP، slash command و plugin به Usage Metrics API و محدودیت تفسیر interaction count: https://github.blog/changelog/2026-09-17-agentic-cli-customizations-now-in-the-usage-metrics-api — منتشرشده در 2026-09-17 و بررسی‌شده در 2026-09-20.

مستندات رسمی GitHub دربارهٔ cloud agent برای research repository، ساخت plan، تغییر روی branch، اجرای تست و pull request: https://docs.github.com/en/copilot/concepts/agents/cloud-agent — بررسی‌شده در 2026-09-20.

Scrum Guide دربارهٔ شفافیت، inspection، adaptation، Sprint Goal و forecast بر اساس شواهد گذشته: https://scrumguides.org/scrum-guide.html — بررسی‌شده در 2026-09-20.

مرز شواهد و تحلیل

قابلیت‌ها، تاریخ‌ها و محدودیت‌های سه خبر از صفحات رسمی GitHub Changelog گرفته شده‌اند. تعریف ظرفیت gross، reliable و outcome، مدل پنج‌لایهٔ dashboard، برنامهٔ ۳۰روزه و تحلیل اثر AI بر Agile و مدیریت پروژه، چارچوب تحلیلی امین رضا سیدآبادی است و باید با context، داده و quality bar هر تیم تطبیق داده شود.

این مقاله ادعا نمی‌کند Copilot یا Agentic CLI برای هر تیم بهره‌وری را افزایش می‌دهد. مثال‌ها فرضی‌اند و هیچ metric سازمانی، benchmark یا نتیجهٔ محرمانه‌ای را گزارش نمی‌کنند. usage، engagement و interaction فقط وقتی ارزش تصمیمی دارند که با کیفیت، هزینه، ریسک، review و outcome واقعی کنار هم خوانده شوند.