Rolling Planning Horizons

1. مسئله واقعی: یک تقویم ثابت، قطعیت جعلی می‌سازد

وقتی همه‌ی آیتم‌ها روی یک تقویم واحد با یک سطح تعهد نمایش داده می‌شوند، کار این هفته و ایده‌ی سه ماه بعد ظاهراً هم‌ارز می‌شوند. Rolling Planning Horizon این خطا را با سه پنجره‌ی NOW / NEXT / LATER و حالت DEFERRED اصلاح می‌کند؛ هرچه افق دورتر است، تعهد باید ضعیف‌تر و بازبینی صریح‌تر باشد.

2. مرز درس و Artifact مالک

خروجی این درس Rolling Planning Horizon Decision Ledger v1 است. این Ledger برای هر آیتم evidence cutoff، signal window، confidence، commitment، capacity cost، dependency state، review trigger، replan reason و provenance را ثبت می‌کند. تشخیص Content Gap متعلق به PLN-010 و Privacy در Inbox متعلق به PLN-008 است و این درس آن‌ها را جذب نمی‌کند.

3. Horizon یعنی سطح تصمیم، نه صرفاً تاریخ

NOW یعنی آیتمی که در پنجره‌ی نزدیک ظرفیت و dependency لازم را دارد و شواهدش برای تعهد عملی کافی است. NEXT یعنی گزینه‌ی معتبر اما با تعهد کمتر یا وابستگی/شاهدی که هنوز باید تکمیل شود. LATER محل امکان‌های کم‌تعهد و قابل‌بازنگری است. DEFERRED یعنی فعلاً ظرفیت، dependency یا شواهد اجازه‌ی حرکت نمی‌دهد.

4. Evidence Cutoff را قبل از جابه‌جایی ثبت کن

هر تصمیم باید بگوید «با کدام شواهد تا چه زمان» گرفته شده است. اگر cutoff مشخص نباشد، مقایسه‌ی تصمیم امروز با تصمیم چرخه‌ی بعد ناممکن می‌شود. داده‌ای که بعد از cutoff آمده می‌تواند trigger بازبینی باشد، اما نباید تاریخچه‌ی تصمیم قبلی را بی‌صدا بازنویسی کند.

5. Search Console فقط Signal زمان‌مند می‌دهد

Performance report در Search Console بازه‌ی تاریخ و مقایسه‌ی دوره‌ها را پشتیبانی می‌کند؛ بنابراین می‌تواند query/page signal را برای review window محدود فراهم کند. این داده priority، capacity یا commitment را تعیین نمی‌کند. بازه و granularity باید کنار provenance ثبت شوند.

6. Google Trends مقدار مطلق تقاضا نیست

Google Trends از نمونه‌ی جست‌وجوها استفاده می‌کند و داده را نسبت به زمان و مکان نرمال می‌کند. پس عدد 100 یا یک spike کوتاه‌مدت «دستور انتشار» نیست. Trend فقط یکی از signalهاست و باید در context همان window و geography خوانده شود.

7. Confidence Band باید قابل توضیح باشد

به‌جای عدد تزئینی، از bandهای HIGH / MEDIUM / LOW استفاده کن و دلیل آن را بنویس. HIGH یعنی شواهد مستقل و تازه با dependency روشن؛ MEDIUM یعنی بخشی از evidence یا dependency هنوز در حال تکمیل؛ LOW یعنی signal ضعیف، کوتاه‌مدت یا متناقض. UNKNOWN را به LOW تبدیل نکن؛ UNKNOWN باید همان UNKNOWN بماند.

8. Commitment Gradient را با Horizon هماهنگ کن

تعهد NOW باید از NEXT قوی‌تر و NEXT از LATER قوی‌تر باشد. اگر همه‌ی افق‌ها با یک commitment ثابت قفل شوند، rolling plan تبدیل به تقویم ثابت با سه برچسب می‌شود. نمونه‌ی مناسب: NOW=COMMITTED، NEXT=PROVISIONAL، LATER=OPTIONAL؛ اما نام و آستانه‌ی دقیق وابسته به محیط است.

9. Capacity Gate قبل از Promotion

هر promotion به NOW باید از capacity budget عبور کند. اگر ظرفیت ۴۰٪ کم شود، اولویت‌ها و horizon placement باید دوباره محاسبه شوند؛ حفظ همان فهرست NOW و فقط فشرده‌کردن زمان، تصمیم قابل‌دفاع نیست. Capacity cost هر آیتم را کنار بودجه‌ی موجود ثبت کن.

10. Dependency State جلوی خوش‌بینی را می‌گیرد

READY، PENDING و BLOCKED را از هم جدا کن. آیتم BLOCKED نمی‌تواند فقط به‌خاطر trend spike وارد NOW شود. PENDING ممکن است در NEXT بماند و review trigger داشته باشد. اگر dependency حیاتی نامعلوم است، تصمیم باید REVIEW_REQUIRED باشد.

11. Review Trigger باید finite باشد

«بعداً بررسی می‌کنیم» trigger نیست. مثال‌های معتبر: رسیدن dependency X، پایان window هفت‌روزه، عبور هزینه از بودجه، دریافت cohort evidence یا تاریخ جلسه‌ی ماهانه. Trigger باید قابل آزمون و دارای زمان/رویداد مشخص باشد.

12. Replan بدون Reason ممنوع است

حرکت LATER→NOW، NEXT→DEFERRED یا هر تغییر horizon باید replan reason داشته باشد: evidence تازه، تغییر ظرفیت، dependency جدید، تغییر context یا expiry. اگر آیتم بدون reason و provenance جابه‌جا شود، نتیجه REVIEW_REQUIRED است؛ حتی اگر مقصد ظاهراً منطقی باشد.

13. مثال کارشده: چهار آیتم، چهار سطح تعهد

فرض کن ظرفیت NOW برابر ۵ واحد است. A با confidence بالا، cost=2 و dependency آماده وارد NOW می‌شود. B با confidence متوسط و dependency در انتظار در NEXT می‌ماند. C فقط یک spike کوتاه دارد و در LATER با review هفت‌روزه می‌ماند. D با cost=4 در شرایطی که فقط 2 واحد ظرفیت آزاد مانده، DEFERRED می‌شود. Ledger علت هر تصمیم را مستقل از برچسب ذخیره می‌کند.

14. Failure Probeهای قطعی

چهار shortcut باید رد شوند: (۱) یک commitment برای همه‌ی horizonها؛ (۲) کاهش ۴۰٪ ظرفیت بدون بازتصمیم؛ (۳) اجازه دادن به spike کوتاه برای کنارزدن evidence قوی‌تر؛ (۴) انتقال LATER→NOW بدون evidence/replan reason. در هر چهار حالت تاریخچه باید حفظ و تصمیم محدود شود، نه اینکه plan بی‌صدا بازنویسی شود.

15. Transfer: برنامه‌ی مستندسازی با Release ماهانه

در برنامه‌ای با release ماهانه، طول NOW/NEXT/LATER الزاماً مثل برنامه‌ی هفتگی نیست. پس تاریخ‌ها را کپی نکن. با ظرفیت ۴۰٪ کمتر، windowها، commitmentها و review triggerها را از نو محاسبه کن؛ Contract ثابت می‌ماند اما parameterها باید از context جدید به‌دست آیند. خروجی نهایی باید نشان دهد چه چیزی عوض شد، چرا عوض شد و کدام evidence آن را پشتیبانی کرد.