خزش محدوده (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 متوقف کنید — نه با «نه گفتن به همه»، بلکه با «بله آگاهانه به بعضی».
سوالات تکمیلی
چقدر طول می‌کشد ارزش را ببینیم؟
به طول اسپرینت و حجم درخواست‌های تغییر بستگی دارد. از همان اسپرینت اول، تعداد درخواست‌های واردشده، پذیرفته‌شده، ردشده و زمان تصمیم را ثبت کنید؛ وقتی داده کافی دارید روند را بسنجید، نه اینکه یک زمان ثابت و بی‌منبع وعده دهید.
داده ناقص چطور؟
در جلسه صریح بگویید چه چیزی را نمی‌بینید — شکاف را با حدس پر نکنید.
از کجا شروع کنیم؟
یک پروژه آزمایشی، یک چارچوب از این مقاله، چهار هفته اندازه‌گیری، بعد گسترش.
چک‌لیست عملی این هفته
یک پروژه دارای تغییرات پرتکرار را انتخاب کنید. هدف اسپرینت، تصمیم‌گیرنده تغییر و معیار پذیرش را ثبت کنید؛ سپس هر درخواست جدید را فقط همراه اثر زمانی یا هزینه‌ای وارد تصمیم کنید.