تغییر scope در پروژهٔ AI چگونه مدیریت شود؟

Scope در پروژهٔ AI دقیقاً شامل چیست؟

در یک پروژهٔ معمولی، scope را اغلب با feature، خروجی، milestone و acceptance criteria توضیح می‌دهیم. در یک قابلیت AI، همین فهرست کافی نیست. باید بدانیم مدل در چه taskهایی دخالت می‌کند، چه داده‌ای می‌بیند، چه ابزارهایی را صدا می‌زند، چه خطایی قابل‌قبول است، در چه زبان یا channelی کار می‌کند و چه کسی خروجی را قبل یا بعد از اقدام بررسی می‌کند.

من scope را برای گفتگو به پنج لایه تقسیم می‌کنم: outcome محصول، رفتار و کیفیت AI، مرز workflow، الزامات operational و سطح اعتماد یا اختیار کاربر. گاهی یک تیم فقط یک provider را عوض می‌کند و می‌گوید scope تغییر نکرده؛ اما اگر مدل context متفاوت، tool متفاوت یا نرخ خطای متفاوت داشته باشد، بخشی از scope کیفی تغییر کرده است.

این تفکیک جلوی یک سوءتفاهم را می‌گیرد: تغییر implementation همیشه تغییر scope نیست، اما تغییر outcome، audience، کیفیت، مجوز، SLA یا تعهد زمانی تقریباً همیشه باید به‌عنوان تغییر قابل‌تصمیم دیده شود.

• Outcome: کاربر یا کسب‌وکار در پایان چه تغییری می‌بیند؟
• AI behavior: مدل چه taskی را با چه معیار کیفیتی انجام می‌دهد؟
• Workflow boundary: ورودی، retrieval، ابزار و action کجا شروع و تمام می‌شوند؟
• Operational scope: latency، هزینه، ظرفیت، monitoring و fallback چیست؟
• Trust boundary: کدام خروجی draft است و کدام action نیاز به approval دارد؟

فرق تغییر هدف، تغییر راه‌حل و تغییر فرصت را بدانیم

هر درخواست تازه‌ای که در پروژه ظاهر می‌شود، از جنس یکسان نیست. اگر شواهد جدید نشان می‌دهد مسئلهٔ کاربر چیز دیگری است، Product Goal یا outcome ممکن است نیازمند بازنگری باشد. اگر outcome ثابت است اما provider، prompt، retrieval یا معماری تغییر می‌کند، احتمالاً با تغییر راه‌حل فنی روبه‌رو هستیم. اگر مدل یا vendor قابلیتی تازه معرفی کرده که می‌تواند فرصت جدیدی بسازد، هنوز فقط یک opportunity است و باید جدا از تعهد فعلی بررسی شود.

خطای رایج این است که opportunity را به scope committed تبدیل کنیم. مدل جدید می‌تواند ابزار بیشتری داشته باشد، context بزرگ‌تری بدهد یا کد بیشتری تولید کند؛ اما این موضوع به‌تنهایی نمی‌گوید آن قابلیت برای کاربر ارزشمند، پایدار، امن و اقتصادی است. در review اولیه باید آن را به یک آزمایش محدود تبدیل کنیم، نه اینکه مستقیم وارد roadmap قطعی شود.

این جداسازی به تیم اجازه می‌دهد بدون دفاع کورکورانه از plan اولیه، یادگیری را وارد تصمیم کند. scope قابل‌تغییر است؛ commitment باید با evidence تغییر کند.

• تغییر هدف: مسئله، کاربر یا outcome عوض شده است.
• تغییر راه‌حل: برای همان outcome، مدل، ابزار یا معماری عوض می‌شود.
• فرصت جدید: قابلیت تازه ارزش بالقوه دارد اما هنوز evidence و تعهد ندارد.
• تغییر تعهد: زمان، کیفیت، هزینه یا سطح ریسک مورد توافق جابه‌جا می‌شود.

Scrum دربارهٔ تغییر scope چه مرزی می‌گذارد؟

Scrum Guide، Sprint Goal را single objective برای Sprint می‌داند و در عین حال برای exact work لازم جهت رسیدن به آن انعطاف قائل است. اگر کار متفاوت از انتظار پیش برود، Developers با Product Owner دربارهٔ scope Sprint Backlog مذاکره می‌کنند، بدون اینکه Sprint Goal را خراب کنند. خود Sprint Backlog هم باید با آموخته‌های جدید به‌روزرسانی شود.

این اصل برای پروژهٔ AI بسیار کاربردی است. اگر evaluation نشان دهد راه‌حل فعلی برای هدف Sprint بیش‌ازحد پرهزینه است، تیم می‌تواند implementation را کوچک کند، یک tool را حذف کند یا action خودکار را به draft تبدیل کند. اما اگر درخواست تازه هدف Sprint را عوض می‌کند، بهتر است آن را به Product Backlog برگردانیم و دربارهٔ اولویت و هدف جدید تصمیم بگیریم.

Sprint Review هم فقط محل نمایش خروجی نیست؛ تیم و stakeholderها outcome و تغییر محیط را inspect می‌کنند و Product Backlog می‌تواند بر اساس فرصت‌های جدید adjust شود. بنابراین تغییر scope باید در یک گفت‌وگوی شفاف و evidenceدار رخ دهد، نه در پیام‌های پراکنده یا اضافه‌شدن silent ticket به Sprint.

• داخل Sprint، scope کار را برای حفظ Sprint Goal مذاکره کنید.
• وقتی هدف یا ارزش مورد انتظار عوض شده، Product Backlog و اولویت را بازبینی کنید.
• تعهد زمانی، quality bar و Definition of Done را با تغییر scope پنهان جابه‌جا نکنید.
• تصمیم تغییر را در جایی ثبت کنید که تیم و stakeholderها بتوانند inspect کنند.

چرا قابلیت مدل baseline را ناپایدار می‌کند؟

Baseline فقط یک تاریخ تحویل یا مبلغ قرارداد نیست. برای AI باید فرض‌های مهم کیفیت، هزینه، latency، حجم استفاده، review انسانی و ریسک را هم ثبت کنیم. وقتی مدل، provider، قیمت، context window یا ابزارهای در دسترس تغییر می‌کند، ممکن است چند فرض baseline دیگر معتبر نباشد.

در بررسی مستندات رسمی OpenAI در ۱۵ سپتامبر ۲۰۲۶، catalog مدل‌ها بین مدل‌های flagship و مدل‌های متعادل یا cost-sensitive تفاوت‌هایی در reasoning، قیمت input و output، context window، سقف خروجی و ابزارهای قابل‌استفاده نشان می‌دهد. این یک خبر یا capability vendor است، نه proof موفقیت پروژه؛ اما به‌اندازه‌ای مهم هست که baseline انتخاب مدل، هزینه و latency را دوباره بررسی کنیم.

همین‌طور مستندات رسمی GitHub توضیح می‌دهد cloud agent می‌تواند repository را research کند، plan بسازد، روی branch تغییر بدهد و آن را برای review و iteration به pull request برساند. این یعنی هزینهٔ تولید پیشنهاد یا تغییر اولیه ممکن است کم شود؛ اما review، test، merge، ownership و risk surface حذف نمی‌شوند. اگر تیم فقط بخش ارزان‌تر را در forecast ببیند، baseline به‌صورت مصنوعی خوش‌بینانه می‌شود.

پس baseline باید versioned باشد. کنار هر برآورد بنویسید این فرض به کدام مدل، prompt، data path، سطح review و حجم استفاده وابسته است. در غیر این صورت تغییر capability با تغییر رایگان scope اشتباه گرفته می‌شود.

فرایند پنج‌مرحله‌ای برای تصمیم تغییر scope

برای تیم‌های کوچک، یک فرایند پنج‌مرحله‌ای می‌تواند جلوی scope creep را بگیرد بدون اینکه هر تصمیم به کمیتهٔ سنگین تبدیل شود. مهم است که هر مرحله با یک evidence کوچک اما قابل‌ردگیری تمام شود.

مرحلهٔ اول، signal را ثبت کنید: چه چیزی تغییر کرده، منبع آن چیست و چرا اکنون مهم است؟ مرحلهٔ دوم، اثر را به outcome و goal وصل کنید: آیا این تغییر به هدف فعلی کمک می‌کند یا هدف جدیدی می‌سازد؟ مرحلهٔ سوم، impact را در شش محور بسنجید: زمان، هزینه، کیفیت، ریسک، عملیات و ظرفیت review. مرحلهٔ چهارم، گزینه‌ها را مقایسه کنید: انجام کامل، آزمایش محدود، کاهش scope، defer یا stop. مرحلهٔ پنجم، تصمیم و baseline جدید را ثبت کنید و زمان بازبینی تعیین کنید.

AI می‌تواند در جمع‌کردن context، مقایسهٔ diff، استخراج dependency و ساختن سناریو کمک کند؛ اما قبول یا رد تغییر باید به owner محصول و تیمی که کیفیت و اجرا را بر عهده دارد برگردد.

• Signal: تغییر را همراه منبع، تاریخ و فرض اصلی ثبت کن.
• Goal fit: ارتباط آن با Product Goal یا Sprint Goal چیست؟
• Impact: زمان، هزینه، کیفیت، ریسک، عملیات و review چه تغییری می‌کنند؟
• Options: full، pilot، reduce، defer یا stop را مقایسه کن.
• Decision: owner، تصمیم، baseline جدید و تاریخ inspect را ثبت کن.

از request مبهم به change record قابل‌تصمیم

در بسیاری از پروژه‌ها درخواست «این feature را هم با AI اضافه کنیم» مستقیم وارد backlog می‌شود. پیش از آن، یک change record کوتاه بسازید. این سند قرار نیست PRD کامل باشد؛ باید جلوی تصمیم‌گیری با هیجان و حافظهٔ ناقص را بگیرد.

یک قالب مناسب می‌تواند این باشد: «signal چیست؟ outcome فعلی چیست؟ scope دقیقاً کدام لایه را تغییر می‌دهد؟ چه فرضی شکسته یا تأیید شده؟ کمترین آزمایش برای کاهش عدم‌قطعیت چیست؟ چه چیزی از scope فعلی کم یا جابه‌جا می‌شود؟ معیار قبول و stop چیست؟ owner و تاریخ بازبینی چه کسی و چه زمانی است؟»

در تصمیم‌های AI، حتماً یک بخش «چه چیزی تغییر نمی‌کند؟» هم اضافه کنید. مثلاً ممکن است مدل عوض شود اما Sprint Goal، quality bar و human approval تغییر نکند. این جمله از scope پنهان جلوگیری می‌کند و به تیم می‌گوید قرار نیست capability تازه، قرارداد کیفیت را بی‌صدا پایین بیاورد.

اگر تغییر هنوز به evidence کافی نرسیده، status آن را hypothesis یا experiment نگه دارید. backlog نباید محل نگهداری تعهدهای مبهمی باشد که فقط چون تولید draft با AI آسان شده، وارد آن شده‌اند.

• تغییر پیشنهادی و دلیل زمانی آن را بنویسید.
• اثر روی goal، baseline و Definition of Done را جدا کنید.
• یک آزمایش محدود با معیار pass، fail و stop تعریف کنید.
• scopeای را که باید حذف، defer یا کوچک شود صریح کنید.
• فرض، owner و تاریخ بازبینی را versioned ثبت کنید.

معیارهای تصمیم: چه زمانی تغییر را قبول کنیم؟

یک تغییر scope زمانی قابل‌قبول‌تر است که به outcome موجود کمک کند، evidence آن از یک نمونه یا آزمایش محدود بیاید، کیفیت و ریسک آن با DoD پوشش داده شود و تیم ظرفیت اجرای بخش‌های جدید را داشته باشد. صرفاً اینکه vendor می‌گوید capability موجود است یا مدل در یک demo خوب جواب می‌دهد، کافی نیست.

برای pilot، معیارها را کوچک ولی واقعی انتخاب کنید: task success، نرخ اصلاح انسانی، کیفیت citation یا خروجی، latency، هزینهٔ هر task، نرخ fallback و زمان review. به یک metric واحد اجازه ندهید تصمیم را دیکته کند. مثلاً کاهش latency اگر با افت correctness یا افزایش rework همراه باشد، ممکن است بهبود واقعی نباشد.

همچنین معیار stop را قبل از اجرا تعیین کنید. اگر بعد از دو هفته هنوز دادهٔ کافی برای قضاوت نداریم، شاید آزمایش بد طراحی شده یا scope بیش‌ازحد بزرگ است. stop کردن یک experiment شکست نیست؛ گاهی بهترین راه محافظت از capacity تیم و جلوگیری از تعهد دیرهنگام است.

• اثر بر outcome فعلی و user value قابل‌توضیح است.
• evidence از context واقعی، نه فقط demo vendor، آمده است.
• هزینهٔ ساخت، run، review و نگهداری در برآورد هست.
• quality bar، privacy، security و fallback حفظ یا آگاهانه تغییر داده شده‌اند.
• معیار قبول، معیار توقف و زمان تصمیم بعدی از قبل روشن است.

چه چیزهایی را نباید به AI بسپاریم؟

AI می‌تواند درخواست‌های جدید را cluster کند، رابطهٔ آن‌ها با backlog را نشان دهد، dependency احتمالی را استخراج کند و چند سناریوی impact بسازد. این کار برای کاهش زمان آماده‌سازی مفید است. اما مدل نباید به‌تنهایی تصمیم بگیرد کدام stakeholder را نادیده بگیریم، کدام quality bar را کم کنیم، کدام ریسک را بپذیریم یا کدام تعهد را به تیم اضافه کنیم.

مخصوصاً مراقب برآوردهای ظاهراً دقیق باشید. مدل ممکن است effort را با زبان مطمئن ارائه کند، اما uncertainty داده، هماهنگی انسانی، integration، review و failure handling را کم‌برآورد کند. خروجی را به‌عنوان range و فرض ببینید و اگر ممکن است با دادهٔ cycleهای قبلی یا یک spike کوتاه کالیبره کنید.

در scope change، accountability مهم‌تر از اتوماسیون است. انسان‌ها باید بدانند چه تصمیمی گرفته‌اند و چرا. AI می‌تواند decision record را بهتر بنویسد؛ نباید تبدیل شود به کسی که بعداً تقصیر تغییر برنامه را به او نسبت می‌دهیم.

• AI پیشنهاد و سناریو بسازد، نه commitment نهایی.
• برآورد مدل را range همراه فرض و confidence بخوانید.
• تغییر quality bar، ریسک و approval boundary را انسانی تأیید کنید.
• هر تصمیم را با owner و دلیل ثبت کنید، نه با عبارت «مدل پیشنهاد داد».

اثر AI بر هزینه و قرارداد پروژه

تغییر scope در پروژهٔ AI فقط مسئلهٔ backlog نیست؛ بر quotation، قرارداد و expectation مشتری هم اثر می‌گذارد. اگر provider ارزان‌تر شد، الزاماً قیمت کل پروژه به همان نسبت کم نمی‌شود، چون evaluation، migration، regression، monitoring و review هنوز هزینه دارند. اگر مدل قوی‌تر شد، شاید قابلیت بیشتری ممکن شود، اما ممکن است latency، privacy، vendor lock-in یا نیاز به کنترل بیشتر هم اضافه شود.

در قرارداد یا proposal، outcome و assumption را از implementation جدا کنید. مشخص کنید کیفیت چگونه پذیرش می‌شود، چه داده‌ای در scope است، چه تغییر provider یا مدل change request محسوب می‌شود، هزینهٔ مصرف و نگهداری بر عهدهٔ چه کسی است و برای افت کیفیت یا قطع سرویس چه fallbackای وجود دارد.

برای یک پروژهٔ کوچک، یک جدول سادهٔ baseline کافی است: فرض فعلی، evidence، owner، اثر تغییر و تصمیم. این کار هم گفت‌وگوی مشتری را شفاف می‌کند و هم از وعدهٔ «هر قابلیت جدید بدون زمان و هزینهٔ اضافه» جلوگیری می‌کند.

یک الگوی عملی برای تیم کوچک

اگر بخواهم این روش را برای یک تیم کوچک و یک Sprint دو هفته‌ای اجرا کنم، در ابتدای Sprint هدف و quality bar را ثابت و visible می‌کنم. هر signal تازه در یک change log کوتاه ثبت می‌شود. AI context و impact اولیه را آماده می‌کند؛ Product Owner و Developers آن را در یک گفت‌وگوی کوتاه بررسی می‌کنند.

تغییرهای کوچک که Sprint Goal را حفظ می‌کنند، با مذاکرهٔ روشن وارد Sprint Backlog می‌شوند و بخشی از scope دیگر کم یا جابه‌جا می‌شود. تغییرهای بزرگ به یک spike یا pilot محدود تبدیل می‌شوند. تغییرهایی که outcome یا ریسک را عوض می‌کنند، به Product Backlog و Sprint بعد می‌روند. در پایان Sprint، نتیجهٔ آزمایش، rework، هزینه، latency و failure caseها به baseline و roadmap برمی‌گردند.

این مدل نه به معنی خشک‌کردن backlog است و نه به معنی پذیرفتن هر ایده. هدف آن حفظ focus همراه با یادگیری است. تیم می‌تواند سریع تغییر کند، اما هر تغییر باید قابل‌توضیح و قابل‌بازگشت باشد.

• هدف Sprint و Definition of Done را ثابت و قابل‌مشاهده نگه دارید.
• برای هر request جدید، signal و اثر را در change log بنویسید.
• داخل Sprint فقط با حفظ Sprint Goal و جابه‌جایی شفاف scope تغییر دهید.
• فرصت بزرگ را به spike یا pilot با stop criteria تبدیل کنید.
• در Retrospective، فرض‌های شکسته و هزینهٔ scope change را بررسی کنید.

چک‌لیست قبل از قبول تغییر scope

• این تغییر به کدام Product Goal یا Sprint Goal وصل است؟
• آیا هدف عوض شده یا فقط راه‌حل و ابزار؟
• کدام لایهٔ scope تغییر می‌کند: outcome، کیفیت، workflow، عملیات یا اعتماد؟
• چه evidence واقعی داریم و کدام بخش هنوز hypothesis است؟
• اثر بر زمان، هزینه، latency، کیفیت، ریسک و ظرفیت review چیست؟
• چه چیزی از scope فعلی کم یا defer می‌شود؟
• آیا Definition of Done و approval boundary حفظ شده‌اند؟
• معیار pass، fail، stop و زمان بازبینی چیست؟
• owner تصمیم و owner اجرای تغییر چه کسانی هستند؟
• اگر capability مدل فردا تغییر کرد، مسیر rollback یا fallback چیست؟

جمع‌بندی

واقعیت عمومی: Scrum Guide، Product Backlog را emergent و ordered می‌داند و اجازه می‌دهد تیم در طول Sprint برای رسیدن به همان Sprint Goal دربارهٔ scope کار مذاکره کند. در مستندات رسمی فعلی OpenAI، مدل‌ها از نظر reasoning، هزینه، context و ابزار متفاوت‌اند و در مستندات GitHub، cloud agent می‌تواند research، plan و تغییر روی branch را تا pull request پیش ببرد. این‌ها نشان می‌دهند قابلیت تولید و انتخاب راه‌حل سریع‌تر تغییر می‌کند؛ اما نتیجهٔ پروژه یا کیفیت delivery را تضمین نمی‌کنند.

تحلیل من: در پروژهٔ AI، scope را باید به outcome، رفتار AI، مرز workflow، عملیات و trust boundary بشکنیم. هر capability تازه ابتدا signal یا hypothesis است. تغییر زمانی وارد commitment می‌شود که اثر آن بر baseline، quality، ریسک، هزینه و ظرفیت تیم قابل‌توضیح باشد. اگر goal حفظ می‌شود، scope داخل Sprint قابل‌مذاکره است؛ اگر goal یا تعهد کیفیت عوض می‌شود، تصمیم باید در سطح Product Backlog و stakeholderها بازتعریف شود.

پیشنهاد حکیم: یک change record کوچک، یک pilot محدود و یک معیار stop بسازید. AI را برای جمع‌کردن context و ساختن سناریو به‌کار ببرید، اما commitment و accountability را نگه دارید. در عصر قابلیت‌های متغیر، تیمی برنده نیست که همیشه scope بیشتری قبول می‌کند؛ تیمی برنده است که سریع یاد می‌گیرد، آگاهانه انتخاب می‌کند و می‌تواند تصمیمش را با evidence توضیح دهد.

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

Scrum Guide نسخهٔ HTML برای Product Backlog، Sprint Goal، مذاکرهٔ scope در Sprint، Sprint Review و به‌روزرسانی Sprint Backlog: https://scrumguides.org/scrum-guide.html — بررسی‌شده در 2026-09-15.

مستندات رسمی OpenAI در catalog مدل‌ها برای تفاوت capability، reasoning، قیمت، context window، سقف خروجی و ابزارهای مدل‌های فعلی: https://developers.openai.com/api/docs/models — بررسی‌شده در 2026-09-15.

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

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

تعریف‌های Scrum و capabilityهای اعلام‌شدهٔ OpenAI و GitHub از منابع اولیهٔ بالا گرفته شده‌اند. تغییرات catalog، قیمت، مدل و سطح دسترسی vendorها ممکن است عوض شوند و این منابع تضمین نمی‌کنند که استفاده از یک مدل یا agent برای هر تیم outcome بهتری بسازد. چارچوب پنج‌لایهٔ scope، فرایند تصمیم، change record، معیارهای pilot و تحلیل اثر AI بر baseline، Agile، هزینه و مدیریت پروژه دیدگاه امین رضا سیدآبادی است و باید با context و دادهٔ واقعی همان پروژه تطبیق داده شود.