مرز کار را ببند: محدوده، محدودیت و خارج از محدوده

این درس چه چیزی به شما می‌دهد؟

در درس قبل، درخواست مبهم «برای فهرست کارها یک فیلتر بگذار» را به Problem Brief v1 تبدیل کردید: مسئله روشن شد، نتیجهٔ قابل مشاهده مشخص شد و معلوم شد کدام گزاره واقعیت، فرض یا ابهام است. هنوز یک خطر مهم باقی مانده است: حتی وقتی مسئله را درست فهمیده‌اید، مرز تغییر می‌تواند بی‌صدا بزرگ شود. یک عامل AI یا توسعه‌دهنده ممکن است هم‌زمان persistence، مدل داده، ظاهر صفحه یا refactorهای جانبی را هم «برای بهترشدن کار» تغییر دهد.

در این درس Scope Box v1 می‌سازید. این artifact چهار تصمیم را قابل بازبینی می‌کند: چه چیزی داخل محدوده است، راه‌حل چه محدودیت‌هایی باید رعایت کند، چه چیزهایی عمداً خارج از محدوده‌اند، و تغییر به کدام dependencyها تکیه دارد بدون اینکه مالک آن‌ها شود.

این درس هنوز معیارهای پذیرش را تعریف نمی‌کند. FND-001-P03 مسئول این است که مشخص کند رفتار مورد انتظار با چه شرط و شاهدی pass/fail می‌شود. اینجا فقط مرزِ چیزی را می‌بندیم که قرار است در آن درس سنجیده شود.

زمان فعال تقریبی: ۴۵ دقیقه.

این درس مناسب شماست اگر: بعد از روشن‌شدن مسئله، هنوز جمله‌هایی مثل «هر چیزی لازم است اصلاح کن» یا «ساده نگه دار» در درخواست شما وجود دارد و یک reviewer نمی‌تواند دقیقاً تشخیص دهد چه تغییرهایی مجاز یا ممنوع‌اند.

این درس برای این کارها نیست: نوشتن acceptance criteria، پیش‌بینی قطعی همهٔ فایل‌های نهایی، تغییر dependency مشترک فقط برای آسان‌شدن task، یا refactor جانبی خارج از scope.

پیش‌نیاز سخت — FND-001-P01: باید بتوانید یک Problem Brief v1 محدود بسازید و مسئله، نتیجهٔ قابل مشاهده و fact/assumption/unknown را بدون پنهان‌کردن تصمیم‌ها جدا کنید.

پروب کوتاه پیش‌نیاز FND-001-P01

درخواست تازه: «در صفحهٔ سفارش‌ها search اضافه کن.» می‌دانیم شمارهٔ سفارش در داده موجود است. نمی‌دانیم جست‌وجو باید نام مشتری را هم پوشش دهد یا نه.

در چهار خط بنویسید: actor/context، شکاف فعلی، نتیجهٔ قابل مشاهده، و یک fact/assumption/unknown صریح. هنوز UI، scope نهایی، constraint یا acceptance criteria نسازید.

PASS فقط با ۴/۴: (۱) مسئله را با راه‌حل UI یکی نکنید؛ (۲) نتیجه را بیرونی و قابل مشاهده بنویسید؛ (۳) وجود شمارهٔ سفارش را fact و پوشش نام مشتری را unknown/assumption نگه دارید؛ (۴) تصمیم downstream را به‌جای حدس‌زدن باز بگذارید.

اگر یکی از این چهار مورد شکست خورد، فقط همان بخش از FND-001-P01 را repair کنید و probe را دوباره انجام دهید. ورود به این درس با Problem Brief شکننده مجاز نیست؛ Scope Box خوب روی مسئلهٔ بد فقط ابهام را رسمی می‌کند.

مسیر مناسب خودتان را انتخاب کنید

همهٔ مسیرها باید به همان Scope Box v1 و همان evidence bar برسند؛ تفاوت فقط در مقدار scaffold است.

پروب چهارمفهومی مسیر

بدون نگاه‌کردن به توضیح‌های بعدی، برای هر مورد یک پاسخ کوتاه بدهید:

1. Scope: چرا «فایل‌های TaskList.tsx و Filter.tsx را تغییر بده» تعریف scope کافی نیست؟
2. Constraint: جملهٔ «ساختار ذخیره‌سازی فعلی نباید تغییر کند» چه نوع مرزی است و چگونه می‌توان رعایتش را بررسی کرد؟
3. Out of scope / non-goal: «بازطراحی کامل ظاهر task list در این تغییر انجام نمی‌شود» چه اثر اجرایی روی diff دارد؟
4. Dependency boundary: اگر فیلتر به status موجود taskها تکیه دارد ولی مالک data model نیست، چه وضعیت/ریسکی باید ثبت شود؟

هر پاسخ فقط وقتی PASS است که مفهوم را با چیزی که معمولاً با آن اشتباه می‌شود جدا کند. ۴/۴ → مسیر باتجربه/Fast Path؛ ۲ یا ۳/۴ → مسیر ترمیم فقط برای مفهوم‌های شکست‌خورده؛ ۰ یا ۱/۴ → مسیر پایه.

• مسیر پایه: کیس مشترک task list و قالب کامل Scope Box را قدم‌به‌قدم جلو ببرید.
• مسیر ترمیم: فقط contrast مربوط به مفهوم شکننده را بخوانید و همان بخش artifact را بازسازی کنید.
• مسیر باتجربه / Fast Path: با ۴/۴ مستقیم به تمرین مستقل بروید؛ brief شما اطلاعات ناقص و dependency مبهم خواهد داشت.

شرط خروج از Fast Path: تجربه معیار را کم نمی‌کند. artifact باید همان چهار بعد بحرانی را پاس کند.

مدل ذهنی: چهار دیوارهٔ Scope Box

Scope Box را مثل یک جعبهٔ تصمیم ببینید، نه فهرست فایل و نه برنامهٔ اجرا. چهار دیواره دارد:

جدول ردیابی این درس همین رابطهٔ «مفهوم → بخش artifact → شاهد/مرز» را نشان می‌دهد. نکتهٔ مهم این است که constraint با acceptance criterion یکی نیست: constraint مسیر یا محیط راه‌حل را محدود می‌کند؛ P03 بعداً تعریف می‌کند چه چیزی نشان می‌دهد خروجی مورد انتظار واقعاً قبول‌شدنی است.

چهار مفهوم پایه

۱) محدوده / Scope

Scope بخشی از مسئله و سیستم است که این تغییر مشخصاً مسئول آن است. Scope را با فایل‌های فعلی یکی نکنید؛ ممکن است در حین کار فایل دیگری کشف شود، اما مسئولیت رفتاری باید از قبل مرز داشته باشد.

ضعیف: «هر فایل لازم بود تغییر بده.» بهتر: «این تغییر فقط مسئول محدودکردن نمای task list به کارهای ناتمام و بازگشت به نمای کامل است.»

آزمون: آیا هر تغییر پیشنهادی را می‌توان به یک مسئولیت in-scope ردیابی کرد؟

۲) محدودیت / Constraint

Constraint قاعده یا شرطی است که راه‌حل باید حین رسیدن به هدف رعایت کند. جملهٔ «ساده نگه دار» constraint قابل داوری نیست؛ دو reviewer ممکن است معنای متفاوتی از «ساده» داشته باشند.

بهتر: «ساختار ذخیره‌سازی taskها در این تغییر تغییر نمی‌کند.» منبع/دلیل این قاعده باید معلوم باشد و بعداً با inspection یا evidence مرتبط بررسی شود.

مرز مهم: constraint نمی‌گوید خروجی چه زمانی قبول است؛ آن کار متعلق به acceptance criteria در FND-001-P03 است.

۳) خارج از محدوده / عدم‌هدف

Out of scope یا non-goal یعنی چیزی که عمداً در این تغییر حل نمی‌شود، حتی اگر نزدیک یا مفید باشد. «بعداً شاید» به‌تنهایی کافی نیست؛ non-goal باید امروز اثر اجرایی داشته باشد.

مثال: «بازطراحی بصری کامل task list و refactor unrelated CSS در این تغییر انجام نمی‌شود.» اگر diff به آن سمت رفت، باید متوقف یا با Change Request جداگانه توجیه شود.

۴) مرز وابستگی / Dependency boundary

یک dependency برای انجام کار لازم است، اما خودش لزوماً هدف تغییر نیست. باید بدانید چه stateای از dependency لازم است، authority/owner آن چیست یا هنوز unknown است، و شکست آن چه اثری روی task دارد.

مثال: فیلتر به status موجود taskها تکیه دارد. Scope این درس مجوز تغییر قرارداد مشترک status را فقط چون «راه محلی سریع‌تر است» صادر نمی‌کند.

Scope Box v1 را چگونه بسازیم؟

از Problem Brief v1 شروع کنید، نه از solution. فقط اطلاعاتی را منتقل کنید که برای بستن چهار مرز لازم است.

قالب خالی Scope Box v1

این قالب را برای یک درخواست تازه پر کنید؛ هر مورد باید دلیل، شاهد یا unknown صریح داشته باشد.

• Problem Brief trace: مسئله/نتیجهٔ مبنا — …
• In scope: رفتار یا مسئولیت این تغییر — …
• Constraints: قاعده + منبع/دلیل + روش بررسی — …
• Out of scope / non-goals: کارِ عمداً حذف‌شده + اثر اجرایی — …
• Dependency boundary: dependency + state موردنیاز + owner/authority یا unknown + اثر شکست — …
• Handoff to P03: تصمیم‌های pass/fail که هنوز باید با evidence بسته شوند — …

یک Scope Box خوب باید برای reviewer مستقل قابل فهم باشد. اگر دو نفر از روی آن نمی‌توانند روی «این تغییر اجازه دارد چه چیزی را دست بزند؟» توافق کنند، هنوز بسته نشده است.

AI کجا کمک می‌کند و کجا نه؟

AI می‌تواند موارد احتمالی scope creep را پیشنهاد دهد، متن constraint را از نظر قابل‌بررسی‌بودن نقد کند، non-goalهای فراموش‌شده را مطرح کند یا dependencyهای احتمالی را برای بررسی فهرست کند. اما پیشنهاد AI authority نیست. AI نباید unknown را به requirement تبدیل کند، scope را بی‌اجازه گسترش دهد، یا تصمیم قبول/رد انسانی را جعل کند.

مثال حل‌شده: Scope Box برای فیلتر کارهای ناتمام

از P01 این Problem Brief محدود را داریم: کاربر در فهرست ترکیبی taskها نمی‌تواند سریع فقط کارهای ناتمام را ببیند؛ نتیجهٔ قابل مشاهده این است که بتواند نمای ناتمام را ببیند و به نمای کامل برگردد. persistence هنوز unknown است.

نسخهٔ خطرناک: «فیلتر را اضافه کن، هر فایل لازم بود تغییر بده، ظاهر را هم تمیز کن، اگر لازم شد data model را اصلاح کن و انتخاب را دائمی نگه دار.» این متن تقریباً همهٔ مرزها را پاک کرده است.

Scope Box v1:

• In scope: رفتار task-list برای نمایش «همهٔ taskها» یا «فقط taskهای ناتمام» و امکان جابه‌جایی میان این دو نمای رفتاری.
• Constraint: ساختار ذخیره‌سازی فعلی taskها در این تغییر تغییر نمی‌کند. دلیل: صورتِ مسئلهٔ نمونه این مرز را صریح تعیین می‌کند. روش بررسی: تغییرات data/schema در review باید صفر یا دارای Change Request جداگانه باشند.
• Out of scope / non-goals: redesign کامل صفحه، تغییر schema و cleanup/refactor نامرتبط. persistence انتخاب فیلتر بین sessionها عمداً در این فهرست قرار نمی‌گیرد، چون authority آن هنوز unknown است.
• یادداشت مرزیِ حل‌نشده: persistence بین sessionها نه in-scope اعلام شده و نه non-goal. تا وقتی authority معتبر این مرز را تعیین نکند، آن را به‌صورت unknown نگه دارید و implementation نباید بی‌صدا آن را اضافه یا ممنوع کند.
• Dependency boundary: رفتار فیلتر به status موجود completed/unfinished تکیه دارد. state موردنیاز: status باید برای taskهای موجود قابل دسترس و معنادار باشد. owner/authority نام‌گذاری‌شده در brief فعلی مشخص نشده و نباید اختراع شود. اگر semantics این status مبهم یا ناسازگار باشد، آن را به‌عنوان dependency risk ثبت کنید و برای تصمیم ارجاع دهید؛ تا روشن‌شدن اختیار، قرارداد مشترک status را در محدودهٔ همین تغییر تصاحب نکنید.
• Handoff to P03: P03 باید تعیین کند برای همین رفتارهای in-scope چه شرایط و evidenceای نشان می‌دهند کار واقعاً pass شده است. این Scope Box آن معیارها را از پیش اختراع نمی‌کند.

اکنون reviewer می‌تواند یک پیشنهاد تازه را با چهار سؤال بسنجد: آیا به in-scope trace می‌شود؟ constraint را می‌شکند؟ به non-goal برخورد می‌کند؟ یا ownership یک dependency را بی‌اجازه تصاحب می‌کند؟

چهار خطای محتمل و روش ترمیم

خطا ۱: scope را با فهرست فایل‌ها یکی می‌کنیم

«فقط این دو فایل را تغییر بده» شاید راهنمای مفیدی باشد، اما scope رفتاری نیست. فایل‌های واقعی ممکن است بعداً کشف شوند. ترمیم: مسئولیت تغییر را بنویسید و فایل‌ها را در حد context نگه دارید.

خطا ۲: constraint مبهم می‌نویسیم

«ساده نگه دار» یا «تمیز باشد» قابل داوری نیست. ترمیم: قاعده‌ای بنویسید که reviewer بتواند با inspection/test/evidence رعایتش را بررسی کند و منبع/دلیل آن را ثبت کند. آن را با acceptance criterion یکی نکنید.

خطا ۳: non-goal را به wishlist بی‌اثر تبدیل می‌کنیم

«فعلاً redesign نمی‌کنیم، مگر اینکه بهتر شود» عملاً مرز ندارد. ترمیم: اثر اجرایی بدهید؛ diff مربوط به redesign بدون Change Request جدا پذیرفته نمی‌شود.

خطا ۴: dependency را چون سریع‌تر است تصاحب می‌کنیم

عامل قرارداد مشترک یا data model را تغییر می‌دهد چون راه محلی راحت‌تر است. ترمیم: state موردنیاز، owner/authority یا unknown و اثر شکست را ثبت کنید. dependency ممکن است لازم باشد، اما خودش هدف تغییر نیست.

اصل مشترک: سرعت مجوز حذف مرز نیست. اگر مرز روشن نیست، unknown را صریح نگه دارید؛ یک «نمی‌دانیم» قابل‌ردیابی بهتر از requirement ساختگی است.

پل مسیر باتجربه: شواهد متناقض و مالکیت نامشخص

در کار واقعی ممکن است ticket بگوید «فقط unfinished»، یک screenshot قدیمی سه حالت فیلتر نشان دهد، و یک پیام تیمی قدیمی بگوید persistence باید فعال باشد. هم‌زمان dependency status از یک package مشترک می‌آید که ownership آن در brief مشخص نیست.

مسیر باتجربه نباید از روی تجربه حدس بزند کدام روایت «احتمالاً درست» است. Scope Box را با supported scope ببندید، constraint و non-goal را فقط از authority موجود بگیرید، evidence متناقض را به unknown تبدیل کنید و dependency را با risk صریح ثبت کنید. اگر تصمیمی blocking است و authority ندارد، MODIFY یا DEFER انسانی از false certainty بهتر است.

چه چیزی را مرز می‌نامیم و چه چیزی را نه؟

سه اشتباه طراحی artifact رایج است:

• Scope خیلی باز: آزادی اجرا زیاد می‌شود اما reviewer نمی‌تواند scope creep را تشخیص دهد.
• Scope بیش‌ازحد فایل‌محور: حس کنترل می‌دهد، اما اگر implementation فایل دیگری لازم داشته باشد یا ساختار تغییر کند، artifact شکننده می‌شود.
• Scope mega-spec: همهٔ تصمیم‌های downstream را همین حالا می‌بندد و مسئولیت P03 و مراحل بعدی را می‌بلعد.

تعادل مطلوب این درس: مسئولیت رفتاری روشن + constraints قابل بررسی + non-goalهای اجرایی + dependency boundary صریح. هنوز دربارهٔ pass/fail نهایی رفتار حکم نمی‌دهیم؛ آن تصمیم به P03 منتقل می‌شود.

تمرین هدایت‌شده و مستقل

تمرین هدایت‌شده

یک ابزار داخلی سفارش‌ها درخواست «search سفارش» دارد. Problem Brief می‌گوید اپراتور برای پیداکردن سفارش خاص بین صفحات جابه‌جا می‌شود و شمارهٔ سفارش در داده وجود دارد. معلوم نیست جست‌وجوی نام مشتری لازم است یا نه. تیم همچنین گفته schema سفارش در این تغییر نباید عوض شود.

Scope Box v1 بسازید:

1. یک in-scope behavior که مستقیماً به Problem Brief trace شود؛
2. constraint مربوط به schema با روش بررسی؛
3. حداقل دو non-goal نزدیک؛
4. dependency روی دادهٔ شمارهٔ سفارش با state/owner-or-unknown/risk؛
5. یک خط handoff به P03 بدون نوشتن acceptance criteria.

تمرین مستقل — مقصد Fast Path

ورودی معتبر این تمرین یک Problem Brief v1 محدود است:

• Actor/context: دانشجو در صفحهٔ تحویل تکلیف، یک فایل را برای همان تکلیف upload می‌کند.
• Current gap: شواهد پشتیبانی نشان می‌دهد بعضی دانشجوها پیش از اینکه بفهمند upload اول ثبت شده یا نه، همان فایل را دوباره می‌فرستند.
• Observable outcome: دانشجو بعد از تلاش برای upload می‌تواند بفهمد همان ارسال ثبت شده است یا نه، پیش از اینکه دربارهٔ ارسال دوباره تصمیم بگیرد.
• Facts/authority: duplicate submission مشاهده شده است؛ صفحهٔ فعلی از upload API موجود استفاده می‌کند؛ تیم صریحاً گفته contract همین API با صفحهٔ فعلی باید compatible بماند، storage provider نباید جایگزین شود، و redesign صفحهٔ دوره جزو این درخواست نیست.
• Unknowns: شکل دقیق feedback در UI، نیاز یا عدم‌نیاز به retry خودکار، و مجازبودن هر تغییر عمیق در upload pipeline هنوز تعیین نشده است. upload service / storage integration برای این رفتار dependency است، اما owner/authority تغییر آن در این brief داده نشده است.

یک پیشنهاد AI می‌گوید: «برای اطمینان، هم progress bar اضافه کن، هم سیستم upload را refactor کن، هم retry خودکار بساز.» این پیشنهاد فقط ورودی نقد است و authority جدید ایجاد نمی‌کند.

بدون کپی‌کردن wording کیس task list، Scope Box v1 بسازید. برای هر بخش یک دلیل/evidence یا unknown صریح ثبت کنید. در پایان دقیقاً مشخص کنید چه چیزی در P02 بسته شد و چه چیزی باید برای FND-001-P03 باقی بماند.

چطور بفهمیم Scope Box کافی است؟

قبل از عبور از این درس چهار بعد بحرانی را بررسی کنید:

1. Concept closure: هر چهار مفهوم حاضر و از مفهوم‌های مشابه جدا شده‌اند.
2. Artifact traceability: هر in-scope behavior به Problem Brief برمی‌گردد؛ constraint منبع/دلیل و روش بررسی دارد؛ non-goal اثر اجرایی دارد؛ dependency state/authority-or-unknown/risk دارد.
3. Neighbor boundary: P02 معیارهای پذیرش را ننوشته و مسئولیت FND-001-P03 را جذب نکرده است.
4. Human judgment/evidence: تصمیم‌های blocking به evidence/authority یا unknown صریح متکی‌اند؛ AI oracle پذیرش یا scope نیست.

شاهد کافی برای این درس Scope Box v1 به‌اضافهٔ توضیح مرز و حداقل یک تصمیم انسانیِ قابل‌ردیابی است. machine validation لازم است، اما جای reviewer انسانی را نمی‌گیرد.

ارزیابی و انتقال

ارزیابی پنج حرکت را می‌سنجد: یک distinction محدود را توضیح دهید، Scope Box را از یک case تازه بسازید، یک artifact failure را تشخیص دهید، دربارهٔ پیشنهاد مبهم AI تصمیم انسانی بگیرید، و artifact را به دامنه‌ای متفاوت منتقل کنید.

در سؤال‌های blocking، پاسخ بدون artifact/evidence/rationale کافی نیست. در transfer باید invariantهای چهارگانه حفظ شوند، نه wording کیس task list. همچنین باید صریح بگویید کدام تصمیم‌ها هنوز متعلق به FND-001-P03 هستند.

منابع و تازگی

چهار مفهوم و مرز آموزشی این درس در طراحی همین دوره تعریف شده‌اند؛ هیچ استاندارد خارجی یا workflow یک vendor، قالب Scope Box v1 را تعریف نمی‌کند.

برای زمینهٔ requirements engineering، وضعیت ISO/IEC/IEEE 29148 در 2026-09-05 دوباره بررسی شد. نسخهٔ 2018 (Edition 2) همچنان International Standard منتشرشده و جاری است، اما در وضعیت «to be revised» قرار دارد. Edition 3 در حال حاضر Draft International Standard است و هنوز جایگزین normative نسخهٔ 2018 نشده است.

اسناد زندهٔ Codex، GitHub Copilot و Claude Code نیز در همین تاریخ recheck شدند. این نسخه از درس هیچ رفتار جاریِ محصولی را به‌عنوان authority آموزشی استفاده نمی‌کند؛ بنابراین تغییر آیندهٔ UI یا workflow این ابزارها مفهوم Scope/Constraint/Non-goal/Dependency boundary را عوض نمی‌کند. هر claim محصولیِ آینده باید دوباره به primary source جاری bind شود.