خزش محدوده (Scope Creep) — چطور پروژه را میبلعد و چطور جلویش را بگیریم
«فقط یک دکمه کوچک اضافه کنید.» «مشتری گفت رنگها باید عوض شود.» «اگر export JSON هم باشد عالی است — کار زیادی نیست.»
سه ماه بعد، تیم روی همان MVP اولیه کار میکند، بودجه ۴۰٪ رد شده، و مدیر پروژه میگوید: «ما اصلاً کی قرار بود این همه قابلیت داشته باشیم؟»
این خزش محدوده (Scope Creep) است: انباشت تغییرات کوچک و «بیضرر» که مجموعاً محدوده، زمان، و هزینه را از کنترل خارج میکند.
Scope Creep به فارسی همان خزش محدوده است — تصور کنید مرز پروژه مثل خطی روی شن است؛ هر موج کوچک (درخواست «فقط یک چیز») خط را کمی جابهجا میکند تا یک روز بفهمید محدوده اصلاً همان اول نیست.
علائم و هزینه خزش محدوده
| علامت | معنی |
|---|---|
| Backlog همیشه بزرگتر میشود، نسبت Done پایین | ورودی بدون خروجی |
| هدف اسپرینت هر بار عوض میشود | مرز اسپرینت وجود ندارد |
| «ما قبلاً توافق کرده بودیم» در برابر «من یادم نیست» | تصمیمها ثبت نشده |
| نرخ مصرف بالا، ارزش تحویلی پایین | کار زیاد، نتیجه کم |
خزش محدوده فقط تأخیر ایجاد نمیکند — اعتماد ذینفع را میخورد. وقتی هر درخواست «بله» میگیرد، هیچکس نمیداند چه چیزی واقعاً تحویل میشود.
چارچوب ۵ مرحلهای کنترل خزش محدوده
۱. مرز اسپرینت را مقدس کنید (نه انعطاف را)
اسپرینت باید هدف مشخص داشته باشد: «تا پایان اسپرینت 4، کاربر میتواند login و dashboard ببیند.» هر چیزی خارج از آن هدف — حتی کوچک — به backlog بعدی میرود مگر اینکه تغییر آگاهانه محدوده تأیید شود.
انعطاف در چطور کار کنید؛ سختگیری در چه تحویل دهید.
۲. هر تغییر محدوده از مسیر کنترل تغییر (Change Control)
فرآیند ساده کافی است:
- درخواست تغییر را بنویسید (چه، چرا، چه کسی خواست).
- تأثیر روی زمان، هزینه، و ریسک را تخمین بزنید.
- تصمیمگیرنده تأیید یا رد کند — ثبتشده.
- فقط بعد از تأیید، به اسپرینت یا backlog اضافه شود.
بدون مرحله ۳، «فقط یک دکمه» همان خزش محدوده است.
۳. Approvals برای تغییرات با اثر بالا
برای تغییراتی که روی deadline، budget، یا قرارداد اثر دارد، از workflow approvals (گردش تأیید) استفاده کنید. SLA مشخص: «تغییر محدوده ظرف ۴۸ ساعت پاسخ میگیرد.»
۴. Decision Log — حافظه پروژه
«ما قبلاً توافق کردیم export PDF خارج از محدوده است» — اگر در decision log ثبت شده باشد، بحث ۲۰ دقیقهای جلسه حذف میشود.
۵. بازبینی دورهای: محدوده در برابر واقعیت
هر دو اسپرینت یکبار: «آیا آنچه میسازیم هنوز همان چیزی است که در kick-off گفتیم؟» اگر drift زیاد است، re-baseline کنید — محدوده جدید رسمی، نه انباشت خاموش.
اشتباهات رایجی که خزش محدوده را تشدید میکنند
«بله» پیشفرض برای ذینفع قدرتمند. راه درست: «بله، اگر item Z از اسپرینت خارج شود — تأیید میکنید؟»
Backlog بینهایت بدون پالایش دورهای. backlog شلوغ = فشار برای جا دادن قابلیت اضافه در هر اسپرینت.
عدم ارتباط محدوده با مالی. تغییر محدوده بدون خط بودجه یعنی مدیر مالی آخر پروژه غافلگیر میشود.
بازبینی بدون اقدام. تیم میگوید «خزش محدوده داشتیم» اما قاعدهٔ جدیدی تعریف نمیکند.
WKFGo در کنترل خزش محدوده
- اسپرینت boundaries: تسکها به اسپرینت assign میشوند؛ my_queue و board نشان میدهند چه چیزی داخل مرز فعلی است.
- Approvals: تغییر محدوده با اثر بالا از workflow تأیید عبور میکند.
- Decision log: تصمیمهای «این خارج از محدوده است» ثبت و searchable هستند.
- Comments روی تسک: درخواست «فقط یک قابلیت» به comment تبدیل میشود — تاریخچه شفاف.
چکلیست ضد خزش محدوده (هر اسپرینت)
- اسپرینت goal یک جمله — قابل test
- Change request بدون approver وارد اسپرینت نشده
- decision log این اسپرینت حداقل یک entry دارد
- «فوری» side-channel به backlog رسمی تبدیل شده
- Retro: یک rule جدید برای اسپرینت بعد
سوالات متداول
خزش محدوده و تغییر مشروع محدوده چه فرقی دارند؟
تغییر مشروع: ثبتشده، تأثیر برآورد شده، ذینفع موافق. خزش محدوده: انباشت بیصدا بدون بازبینی.
آیا باید هر درخواست کوچک را رد کنیم؟
نه — باید سبکسنگین آگاهانه کنید: «بله به export JSON = نه به قابلیت Y در این اسپرینت.»
اسپرینت ثابت خزش را حل میکند؟
مرز اسپرینت کمک میکند اما کافی نیست — اگر change control نباشد، هدف اسپرینت خودش عوض میشود.
decision log جایگزین هیئت کنترل تغییر (CCB) است؟
برای تیمهای کوچک، decision log + approvals کافی است. پروژه enterprise ممکن است CCB رسمی هم بخواهند.
خزش محدوده را با مرز اسپرینت، approvals آگاهانه، و decision log متوقف کنید — نه با «نه گفتن به همه»، بلکه با «بله آگاهانه به بعضی».
سوالات تکمیلی
چقدر طول میکشد ارزش را ببینیم؟
بیشتر تیمها با ریتم هفتگی ثابت، از هفته سوم تا ششم بهبود قابلاندازهگیری میبینند.
آیا نیاز به تغییر ابزار داریم؟
اغلب فرآیند و عادت مهمتر است — WKFGo وقتی ارزش دارد که تیم در همان جایی که کار میکند داده را بهروز نگه دارد.
داده ناقص چطور؟
در جلسه صریح بگویید چه چیزی را نمیبینید — شکاف را با حدس پر نکنید.
از کجا شروع کنیم؟
یک پروژه آزمایشی، یک چارچوب از این مقاله، چهار هفته اندازهگیری، بعد گسترش.
چکلیست عملی این هفته
| روز | اقدام |
|---|---|
| دوشنبه | یک گام چارچوب روی پروژه آزمایشی |
| سهشنبه | مانع داده یا مجوز را رفع کنید |
| چهارشنبه | نتیجه را با لید همخوان کنید |
| پنجشنبه | یک تصمیم یا رفع مانع را در ابزار ثبت کنید |
| جمعه | جلسهٔ بازبینی: چه سیگنال زودتر از هفته قبل آمد؟ |
ثبتنام رایگان · امکانات · قیمتگذاری · مستندات API · تماس · بلاگ