برنامه‌ریزی ظرفیت مهارت‌های AI برای تیم کوچک

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

ظرفیت مهارت با تعداد نفرات یا تعداد دوره‌های گذرانده‌شده یکی نیست. یک تیم ممکن است ده نفر داشته باشد اما هیچ‌کس نتواند کیفیت خروجی Agent را ارزیابی کند، permissionهای integration را بازبینی کند یا هزینهٔ مدل را به تصمیم محصول وصل کند. در این وضعیت، headcount بالا است اما capability پایین و شکننده است.

من ظرفیت مهارت را توان تیم برای انجام یک workflow مشخص تا quality bar قابل‌اعتماد می‌دانم. این توان شامل فهم مسئله، اجرای ابزار، تشخیص failure، تصمیم‌گیری دربارهٔ trade-off، کنترل ریسک و توضیح تصمیم به دیگران است. اگر فقط یک نفر این مسیر را بلد باشد، تیم یک bottleneck و یک نقطهٔ شکست ساخته است.

برای تیم کوچک، برنامه باید از workflow شروع شود نه از عنوان شغلی. مثلاً «آماده‌سازی draft تحلیل مشتری»، «triage issue»، «ساخت تست»، «بازبینی قرارداد» یا «پاسخ‌گویی به support» هرکدام skill، quality bar و ریسک متفاوتی دارند. مهارت مفید مهارتی است که به یک کار واقعی و قابل‌مشاهده وصل شده باشد.

• Skill capacity یعنی توان انجام یک workflow واقعی تا quality bar مشخص.
• دانستن نام ابزار با توان استفادهٔ قابل‌اعتماد از آن فرق دارد.
• یک skill بدون owner، تمرین و artifact به قابلیت سازمانی تبدیل نمی‌شود.
• اگر فقط یک نفر workflow را بلد است، ظرفیت تیم شکننده است.
• برنامهٔ مهارت باید به outcome و ریسک کار وصل باشد، نه به فهرست buzzwordها.

سه خبر جدید چه چیزی دربارهٔ مهارت‌ها می‌گویند؟

در ۱۸ سپتامبر، GitHub اعلام کرد چند مدل Copilot در ۱۹ اکتبر deprecated می‌شوند و برای آن‌ها alternative پیشنهاد کرد. اثر تصمیمی خبر برای تیم کوچک روشن است: اگر integration، prompt، ارزیابی یا مستندات شما به نام یک مدل گره خورده باشد، تغییر provider یا model می‌تواند کار را متوقف کند. مهارت لازم حفظ‌کردن نام مدل نیست؛ مهارت لازم طراحی وابستگی قابل‌تعویض و اجرای migration کم‌ریسک است.

در ۱۴ سپتامبر، انتخاب خودکار مدل Copilot سه tier به نام efficiency، balance و intelligence دارد. این تغییر به تیم می‌گوید کیفیت، هزینه و سرعت باید به‌عنوان یک trade-off دیده شوند. کسی که فقط «بهترین مدل» را می‌خواهد، ممکن است برای task ساده هزینه و latency غیرضروری ایجاد کند. کسی هم که همیشه ارزان‌ترین مسیر را انتخاب می‌کند، ممکن است quality bar را بشکند.

در ۱۶ سپتامبر، GitHub امکان درخواست افزایش budget برای Copilot Business و Enterprise با usage-based billing را عمومی کرد. این یعنی مصرف AI وارد گفت‌وگوی رسمی‌تری دربارهٔ بودجه و مالکیت می‌شود. اما افزایش budget به‌خودی‌خود ظرفیت یا ارزش نمی‌سازد. تیم باید توضیح دهد چه workflowی نیازمند هزینهٔ بیشتر است، چه signalی موفقیت را نشان می‌دهد و چه زمانی باید استفاده متوقف یا اصلاح شود.

• Model lifecycle بخشی از برنامهٔ مهارت است، نه کار بعدی و اضطراری.
• Model routing نیازمند فهم cost، quality و latency است.
• بودجه باید owner، سقف، trigger و توضیح ارزش داشته باشد.
• خبر محصول قابلیت را اعلام می‌کند؛ تیم باید اثر آن بر workflow را بسازد.
• هیچ‌کدام از این خبرها افزایش بهره‌وری یک تیم مشخص را ثابت نمی‌کنند.

چه چیزی را بخریم و چه چیزی را داخل تیم بسازیم؟

خرید ابزار برای سرعت‌گرفتن در capabilityهای عمومی منطقی است: احراز هویت، مدل پایه، فضای اجرا، dashboard اولیه یا قابلیت‌هایی که نگهداری‌شان مزیت رقابتی شما نیست. اما خرید ابزار نباید تصمیم‌گیری دربارهٔ مسئله، quality bar، ریسک، داده و معیار outcome را از تیم بگیرد.

قابلیت داخلی را برای بخش‌هایی بسازید که به context کسب‌وکار، دادهٔ محرمانه، workflow خاص یا تصمیم‌های تکرارشوندهٔ شما وابسته‌اند. این ساختن الزاماً به معنی آموزش مدل یا نوشتن زیرساخت از صفر نیست. گاهی یک runbook، evaluator، adapter، قرارداد داده، test set یا integration تمیز مهم‌ترین capability داخلی است.

شریک بیرونی زمانی مفید است که مسئله تخصصی یا پرریسک است و ساختن آن با ظرفیت فعلی تیم زمان زیادی می‌برد. بااین‌حال، خروجی شریک باید به artifact قابل‌تحویل تبدیل شود: معماری، تست، مستندات، تصمیم‌های ثبت‌شده و آموزش owner داخلی. اگر شریک تنها کسی باشد که سیستم را می‌فهمد، هزینهٔ آینده را خریده‌اید نه capability را.

• Buy: قابلیت عمومی، تکراری و غیرمتمایز که provider بهتر نگهداری می‌کند.
• Build: context، evaluator، integration و تصمیم‌هایی که به کسب‌وکار شما وصل‌اند.
• Partner: تخصص کوتاه‌مدت یا ریسک بالا، همراه با انتقال دانش و artifact.
• هر انتخاب باید هزینهٔ نگهداری و مسیر خروج داشته باشد.
• اگر owner داخلی ندارید، خرید یا برون‌سپاری هنوز مسئله را حل نکرده است.

چهار لایهٔ مهارت برای یک تیم کوچک

برای جلوگیری از فهرست‌های پراکنده، مهارت‌ها را در چهار لایه می‌چینم. لایهٔ اول مسئله و محصول است: تشخیص friction، تعریف outcome، تعیین scope و فهم اینکه AI کجا واقعاً ارزش می‌سازد. لایهٔ دوم اجراست: استفاده از ابزار، context دادن، طراحی workflow و مدیریت handoff.

لایهٔ سوم quality و governance است: ساخت test set، ارزیابی خروجی، تعریف permission، رسیدگی به دادهٔ حساس، ثبت failure و تعیین مسیر escalation. لایهٔ چهارم سیستم و اقتصاد است: model routing، هزینه، latency، provider dependency، observability، migration و rollback.

در تیم کوچک لازم نیست هر نفر در هر چهار لایه expert باشد. اما تیم باید در هر لایه حداقل یک owner و یک نفر پشتیبان داشته باشد. اگر لایهٔ چهارم فقط نزد فروشنده است یا لایهٔ سوم فقط به سلیقهٔ یک reviewer وابسته است، برنامهٔ ظرفیت ناقص است.

• Problem framing: مسئله، outcome، scope و اولویت.
• Workflow operation: context، ابزار، handoff و مدیریت exception.
• Quality and governance: evaluation، permission، privacy و escalation.
• System and economics: routing، cost، latency، portability و rollback.
• برای هر لایه owner، backup و artifact قابل‌بررسی تعیین کنید.

ماتریس مهارت را بر اساس سطح استقلال بسازیم

به‌جای امتیازدهی مبهم از صفر تا پنج، چهار سطح کاربردی تعریف کنید. در سطح observe، فرد می‌داند workflow چه می‌کند و می‌تواند خروجی خوب و بد را تشخیص دهد. در سطح operate، می‌تواند کار معمول را طبق runbook انجام دهد و failure را گزارش کند. در سطح own، می‌تواند quality bar، metric و تصمیم مربوط به workflow را نگه دارد. در سطح teach، می‌تواند دانش را به نفر دیگری منتقل کند و مسیر را بهبود دهد.

این سطح‌بندی برای اپلای و برند حرفه‌ای هم بهتر از فهرست ابزار است. نوشتن «کار با Agent» ادعای ضعیفی است؛ توضیح اینکه یک workflow را اجرا کرده‌اید، خروجی را با چه معیارهایی سنجیده‌اید و چه artifactی ساخته‌اید evidence بهتری است. همان منطق باید داخل تیم هم حاکم باشد.

در هر چرخه فقط یک یا دو skill را از سطح operate به own نزدیک کنید. تیم کوچک با ده‌ها هدف آموزشی شکست می‌خورد چون ظرفیت یادگیری، کار اصلی و review هم‌زمان مصرف می‌شوند. تمرکز کم اما پیوسته، از خرید دوره و ابزار بیشتر نتیجهٔ بهتری می‌دهد.

• Observe: فهم workflow و تشخیص خروجی قابل‌اعتماد.
• Operate: اجرای کار معمول طبق runbook و ثبت failure.
• Own: مالکیت quality bar، metric، هزینه و تصمیم workflow.
• Teach: انتقال دانش، بازبینی runbook و بهبود فرایند.
• سطح skill را با artifact و رفتار واقعی ثابت کنید، نه self-rating تنها.

ظرفیت یادگیری را چگونه در برنامه جا بدهیم؟

آموزش رایگان نیست حتی اگر ابزار رایگان باشد. زمان خواندن مستندات، آزمودن prompt، ساختن test set، اصلاح workflow و توضیح تصمیم به هم‌تیمی از ظرفیت delivery کم می‌کند. اگر این زمان را در برنامه نیاوریم، تیم در ساعات پنهان شب یا با کاهش کیفیت کار اصلی آن را پرداخت می‌کند.

برای هر skill یک بستهٔ کوچک یادگیری بسازید: یک مسئلهٔ واقعی، یک runbook کوتاه، چند مثال خوب و بد، یک معیار قبولی و یک artifact نهایی. artifact می‌تواند evaluator، checklist، prompt versioned، integration test، decision log یا آموزش کوتاه باشد. مهم این است که بعد از یادگیری چیزی در سیستم بماند.

چرخهٔ یادگیری را با یک demo یا review کوتاه ببندید. در این جلسه سؤال این نیست که چه کسی بیشتر prompt زده است؛ سؤال این است که کدام فرض درست یا غلط بود، چه failureی پیدا شد و چه بخشی از workflow باید تغییر کند. این رویکرد یادگیری را به outcome وصل می‌کند.

• برای یادگیری skill زمان مشخص و محدود در sprint یا چرخه قرار دهید.
• هر skill باید مسئلهٔ واقعی و معیار قبولی داشته باشد.
• یادگیری را به artifact قابل‌استفاده تبدیل کنید.
• demo و review را برای کشف failure به‌کار ببرید، نه نمایش ابزار.
• اگر skill به workflow وصل نشد، آن را فعلاً در backlog آموزش نگه دارید.

مدل سادهٔ ظرفیت برای تیم سه تا پنج‌نفره

برای شروع به مدل پیچیده نیاز نیست. ظرفیت هر چرخه را در سه سبد ببینید: delivery کار اصلی، enablement و نگهداری. enablement شامل یادگیری، ساخت evaluator، مستندسازی و تمرین workflow است. نگهداری شامل بررسی هزینه، permission، تغییر provider، رفع integration و رسیدگی به failure است.

در یک تیم کوچک، ابتدا ۷۰ تا ۸۰ درصد ظرفیت را برای delivery قابل‌اعتماد، ۱۰ تا ۲۰ درصد را برای enablement و ۱۰ درصد را برای نگهداری و ریسک کنار بگذارید. این عدد قانون عمومی نیست؛ baseline اولیه است. بعد از دو یا سه چرخه، بر اساس waiting، rework، incident و زمان واقعی آن را اصلاح کنید.

اگر AI فقط سرعت draft را زیاد کند اما enablement و نگهداری را حذف کند، چند هفته بعد هزینهٔ پنهان ظاهر می‌شود. مدل ظرفیت باید نشان دهد چه کسی owner است، چه کاری در صف review است و اگر مدل یا provider تغییر کرد چه بخشی از برنامه باید جابه‌جا شود.

• Delivery: کار محصول تا Definition of Done.
• Enablement: یادگیری، evaluator، runbook و انتقال دانش.
• Maintenance: هزینه، permission، integration، migration و incident.
• نسبت ۷۰/۲۰/۱۰ فقط baseline است و باید با دادهٔ واقعی اصلاح شود.
• ظرفیت پشتیبان برای ownerهای تک‌نفره را در برنامه حساب کنید.

خبر تغییر مدل، برنامهٔ portability را ضروری می‌کند

وقتی یک مدل deprecated می‌شود، مهاجرت فقط عوض‌کردن یک رشته در configuration نیست. باید prompt، output schema، tool call، latency، cost، safety و quality را دوباره بررسی کرد. اگر این مسیر از قبل تمرین نشده باشد، تیم در لحظهٔ فشار مجبور می‌شود هم یاد بگیرد و هم production را حفظ کند.

برای هر وابستگی مدل یک inventory کوتاه داشته باشید: کجا استفاده شده، owner کیست، quality bar چیست، جایگزین احتمالی کدام است و با چه test setی مقایسه می‌شود. لازم نیست از روز اول چند provider را فعال نگه دارید؛ اما باید بدانید مهاجرت چه تصمیم‌ها و چه زمان واقعی‌ای می‌خواهد.

Portability هم مطلق نیست. گاهی یک provider به‌دلیل کیفیت، قیمت یا ابزارهایش انتخاب درستی است. مسئله پنهان‌کردن این وابستگی نیست؛ مسئله این است که وابستگی آگاهانه، مستند، قابل‌سنجش و دارای exit plan باشد.

• Model inventory و owner هر integration را ثبت کنید.
• برای alternative یک test set کوچک اما واقعی داشته باشید.
• prompt، schema، tool call، latency و cost را در migration بسنجید.
• تقویم deprecation را بخشی از roadmap فنی کنید.
• وابستگی آگاهانه بهتر از portability نمایشی و بدون کیفیت است.

سواد هزینه یعنی چه؟

سواد هزینه یعنی تیم بداند هر تصمیم AI چه trade-off مالی و عملیاتی دارد. اگر auto model selection بر اساس efficiency، balance یا intelligence وزن متفاوتی به cost، quality و latency بدهد، owner باید بتواند توضیح دهد کدام task به کدام tier نزدیک‌تر است و این فرض را با داده بررسی کند.

برای شروع، هزینه را به workflow وصل کنید نه فقط به token یا invoice. هزینهٔ یک پاسخ شامل مدل، retry، ابزارهای جانبی، review انسانی، تأخیر و نگهداری هم می‌شود. ممکن است مدل ارزان‌تر باشد اما زمان review را بالا ببرد؛ در این صورت صرفه‌جویی واقعی کمتر از چیزی است که dashboard اولیه نشان می‌دهد.

درخواست budget بیشتر باید یک سؤال تصمیمی بسازد: چه چیزی را می‌خواهیم یاد بگیریم یا تحویل دهیم که بدون این budget نمی‌توانیم؟ اگر پاسخ فقط «مصرف تیم زیاد شده» باشد، هنوز دلیل کافی برای scale نداریم.

• Cost per workflow را کنار quality و زمان بخوانید.
• retry، tool call، review و نگهداری را از هزینه حذف نکنید.
• برای budget owner، سقف و trigger توقف تعیین کنید.
• tier انتخاب مدل را با نوع task و quality bar هماهنگ کنید.
• مصرف بیشتر فقط وقتی ارزشمند است که سؤال یا outcome مشخصی را جلو ببرد.

برنامهٔ ۳۰، ۶۰ و ۹۰روزه

در ۳۰ روز اول یک workflow محدود را انتخاب کنید و skill inventory بسازید. مشخص کنید چه کسی observe، operate، own و teach است؛ baseline زمان، کیفیت، هزینه و failure را ثبت کنید؛ و یک artifact مثل runbook یا evaluator تحویل دهید. هنوز هدف scale نیست؛ هدف فهمیدن gap واقعی است.

در روزهای ۳۱ تا ۶۰، یک skill حساس را از operate به own نزدیک کنید. workflow را چندبار تکرار کنید، review و failure را ثبت کنید و یک نفر پشتیبان برای owner تعیین کنید. در همین بازه، یک migration drill کوچک یا مقایسهٔ دو مدل انجام دهید تا portability از حرف به تجربه تبدیل شود.

در روزهای ۶۱ تا ۹۰، تصمیم stop، adapt یا scale بگیرید. اگر scale می‌کنید، بودجه، owner، آموزش، quality bar، lifecycle و cadence بازبینی را ثبت کنید. اگر متوقف می‌کنید، artifactها و یادگیری را نگه دارید. تیم کوچک نباید هر ماه همان آزمایش را با نام تازه تکرار کند.

• روز ۱ تا ۳۰: workflow، baseline، inventory و artifact اولیه.
• روز ۳۱ تا ۶۰: owner، backup، تکرار و migration drill.
• روز ۶۱ تا ۹۰: تصمیم stop، adapt یا scale با شواهد.
• هر چرخه باید یک skill قابل‌مشاهده و یک artifact بهتر بسازد.
• هدف برنامه افزایش ابزار نیست؛ کاهش وابستگی و افزایش توان تصمیم است.

نشانه‌های اینکه باید خرید، ساخت یا توقف کنیم

اگر مسئله عمومی است، provider کیفیت و نگهداری بهتری دارد و integration شما قابل‌تعویض است، خرید معمولاً انتخاب مناسبی است. اگر مسئله به داده، context یا تصمیم‌های خاص شما وابسته است و بارها تکرار می‌شود، ساختن capability داخلی ارزش بیشتری دارد. اگر ریسک بالا و دانش محدود است، ابتدا شریک بگیرید اما انتقال دانش را در قرارداد و تحویل قرار دهید.

نشانهٔ توقف این است که تیم هنوز نمی‌تواند outcome یا quality bar را تعریف کند، owner ندارد، دادهٔ کافی برای مقایسه ندارد یا هزینه با هدف محصول نمی‌خواند. در این شرایط خرید ابزار جدید فقط ابهام را گران‌تر می‌کند.

نشانهٔ scale این است که workflow چند چرخهٔ قابل‌مقایسه را با quality قابل‌قبول طی کرده، owner و backup دارد، هزینه قابل‌توضیح است و failure path روشن است. adoption یا رضایت اولیه به‌تنهایی برای scale کافی نیست.

• Buy وقتی capability عمومی، قابل‌تعویض و غیرمتمایز است.
• Build وقتی context، داده و تصمیم داخلی مزیت می‌سازد.
• Partner وقتی تخصص کوتاه‌مدت لازم است اما انتقال دانش ممکن است.
• Stop وقتی outcome، owner، baseline یا quality bar نامشخص است.
• Scale وقتی evidence چند چرخه و مسیر failure وجود دارد.

اشتباه‌های رایج در برنامه‌ریزی مهارت

اشتباه اول، ساختن فهرست ابزار به‌جای فهرست capability است. ابزارها عوض می‌شوند اما مسئلهٔ ارزیابی، مدیریت context و تصمیم دربارهٔ ریسک باقی می‌ماند. اشتباه دوم، تبدیل آموزش به رویداد یک‌باره است. skill بدون تمرین، feedback و artifact پایدار نمی‌ماند.

اشتباه سوم، حذف review و نگهداری از برنامه است. تیم می‌گوید AI زمان تولید را کم کرده، اما زمان بررسی، توضیح، رفع failure و migration را نمی‌بیند. اشتباه چهارم، وابسته‌کردن یک workflow به یک نفر یا یک مدل است. این کار تا روز تغییر یا غیبت owner خوب به‌نظر می‌رسد.

اشتباه آخر، سنجش افراد با metric مصرف است. تعداد prompt، invocation یا budget مصرف‌شده نشان نمی‌دهد فرد یا تیم تصمیم بهتری گرفته است. metric باید به outcome workflow، کیفیت و learning وصل شود و برای بهبود سیستم استفاده شود، نه رتبه‌بندی پنهان افراد.

• Tool count را با capability اشتباه نگیرید.
• آموزش را بدون تمرین و artifact تمام‌شده فرض نکنید.
• Review، maintenance و migration را کار رایگان فرض نکنید.
• یک owner یا یک مدل را به نقطهٔ شکست تبدیل نکنید.
• مصرف ابزار معیار عملکرد فردی نیست.

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

تیم کوچک با خریدن ابزار بزرگ نمی‌شود؛ با ساختن توان تصمیم، اجرا و یادگیری بزرگ می‌شود. لازم نیست همهٔ مدل‌ها، Agentها و integrationها را داخل سازمان بسازیم. لازم است بدانیم کدام قسمت را می‌توانیم آگاهانه برون‌سپاری کنیم و کدام قسمت اگر بیرون بماند، در زمان تغییر ما را متوقف می‌کند.

خبرهای تازهٔ GitHub یک درس عملی دارند: مدل‌ها تغییر می‌کنند، هزینه نیازمند owner است و انتخاب خودکار مدل trade-off را پنهان نمی‌کند؛ فقط آن را قابل‌تنظیم‌تر می‌کند. پس برنامهٔ skill باید model lifecycle، cost literacy، evaluation و انتقال دانش را کنار prompt و ابزار قرار دهد.

برای من، بهترین برنامهٔ مهارت برنامه‌ای است که بعد از ۹۰ روز سه چیز قابل‌مشاهده بسازد: یک workflow بهتر، یک owner داخلی که واقعاً بتواند تصمیم بگیرد و یک artifact که نفر بعدی بتواند آن را بررسی و ادامه دهد. اگر فقط ابزارهای بیشتری داریم اما این سه چیز وجود ندارد، capacity واقعی ساخته نشده است.

هدف این نیست که تیم کوچک شبیه یک سازمان بزرگ رفتار کند. هدف این است که با ظرفیت محدود، وابستگی‌ها را بشناسد، یادگیری را در کار واقعی جا بدهد و هر بار یک capability قابل‌اعتمادتر بسازد.

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

GitHub Changelog دربارهٔ deprecation چند مدل Copilot در ۱۹ اکتبر ۲۰۲۶، alternativeهای پیشنهادی و نیاز به به‌روزرسانی workflow و integration: https://github.blog/changelog/2026-09-18-upcoming-deprecation-of-selected-github-copilot-models-in-mid-october — منتشرشده در 2026-09-18 و بررسی‌شده در 2026-09-21.

GitHub Changelog دربارهٔ عمومی‌شدن درخواست افزایش budget برای Copilot Business و Enterprise با usage-based billing و امکان approve، adjust یا deny: https://github.blog/changelog/2026-09-16-copilot-budget-increase-requests-are-generally-available — منتشرشده در 2026-09-16 و بررسی‌شده در 2026-09-21.

GitHub Changelog دربارهٔ tierهای efficiency، balance و intelligence در Copilot auto model selection و trade-off میان cost، quality و response time: https://github.blog/changelog/2026-09-14-configure-cost-and-quality-in-copilot-auto-model-selection — منتشرشده در 2026-09-14 و بررسی‌شده در 2026-09-21.

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

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

تاریخ‌ها، قابلیت‌ها، مدل‌های اعلام‌شده و محدودیت‌های سه خبر از صفحات رسمی GitHub Changelog گرفته شده‌اند. مدل چهارلایهٔ skill، سطح‌بندی observe تا teach، نسبت اولیهٔ ۷۰/۲۰/۱۰، برنامهٔ ۳۰/۶۰/۹۰روزه و تحلیل buy/build/partner چارچوب تحلیلی امین رضا سیدآبادی است و باید با context، داده و quality bar هر تیم تطبیق داده شود.

این مقاله ادعا نمی‌کند مدل یا ابزار مشخص برای هر تیم بهترین است. همچنین افزایش budget، انتخاب خودکار مدل یا وجود alternative به‌تنهایی outcome، کیفیت یا بازگشت سرمایه را تضمین نمی‌کند. تصمیم باید با evidence workflow، هزینهٔ کامل، ریسک، ظرفیت review و توان انتقال دانش گرفته شود.