تطبیق‌دهنده‌ی هفتگیِ عقب‌موندگی: برنامه‌ی هفته‌ی گذشته در برابر واقعیت رو تبدیل کن به اولویت‌های واقع‌بینانه‌ی این هفتهEXCERPT: یه Prompt تشخیص-تطبیق-بازبرنامه‌ریزی که اول دلیل عقب افتادن برنامه‌ی هفته‌ی گذشته رو پیدا می‌کنه و بعد می‌ذاره برنامه‌ی این هفته رو بچینی؛ یعنی دیگه همون لیست غیرواقعی قبلی رو از نو نمی‌سازی.
چرا این پرامپت اهمیت دارد
Carrying forward 100% of unfinished work without diagnosing why it slipped just rebuilds the same overcommitted list — so the same items stall again, trust in your own estimates erodes, and the backlog of almost-done work keeps growing instead of shrinking. Naming the actual slippage pattern (sequencing, dependency, underestimate, interrupt, overcommitment) is the only way to stop repeating it.
ما از آن برای چه استفاده می‌کنیم
You are a product manager (or any individual contributor juggling multiple workstreams) who ends most Fridays with 2-3 planned priorities still undone, and every Monday you face the same choice: silently carry everything forward, or sit down and actually figure out what happened before deciding what is realistic this week.
پرامپت
Role: Act as a ruthless but constructive chief-of-staff who specializes in diagnosing why plans don't survive contact with the week. Context: - My role/function: [YOUR ROLE OR JOB] - Last week's planned priorities: [PASTE THE LIST YOU COMMITTED TO LAST WEEK] - What actually happened: [PASTE A ROUGH LOG — WHAT GOT DONE, WHAT GOT BUMPED, WHAT UNEXPECTED THINGS ATE YOUR TIME] - This week's fixed calendar load: [HOURS ALREADY COMMITTED TO MEETINGS / FIXED OBLIGATIONS] - This week's candidate priorities: [PASTE YOUR ROUGH, UNORDERED LIST FOR THIS WEEK] Task: Step 1 — Diagnose: For each item from last week that slipped, identify the TRUE root cause, choosing from: underestimated effort, dependency on someone else, a higher-priority interrupt, poor sequencing, or simply committing to too many items. Name the single most common cause across all slipped items. Step 2 — Reconcile: For each slipped item, decide whether it still genuinely matters this week or whether its relevance has decayed and it should be formally dropped — not silently carried forward and not silently forgotten. Step 3 — Replan: Build this week's priority list using available hours (total working hours minus the fixed calendar load from Context), sequenced by dependency and cost of delay, not just by who asked most recently. Constraints: - Do not carry over 100% of unfinished items by default — that is denial, not reconciliation. - Cap the final list at no more than [MAX NUMBER OF PRIORITIES, e.g. 5] items. - If the available-hours math does not support even the capped list, say so explicitly rather than quietly padding a list that will slip again. - Name capacity delusion directly when you see it (e.g., "this plan assumes zero interrupts, which contradicts what happened last week"). Output Format: 1. Root Cause Summary (2-3 sentences, naming the dominant slippage pattern) 2. Dropped Items table: Item | Why It No Longer Matters 3. This Week's Priorities table: Priority | Why It's In | Estimated Hours | Dependency Risk 4. One direct, blunt paragraph starting with: "If you only change one thing this week, it's..."
نتیجه
**Root Cause Summary** Three of your four slipped items shared the same root cause: poor sequencing, not lack of effort. You started the vendor contract review and the Q4 roadmap draft in parallel on Monday, both stalled waiting on the same finance input, and neither finished. The onboarding doc rewrite wasn't a sequencing problem — it was a straightforward underestimate; you scoped it at 2 hours and it needed 6.
**Dropped Items** | Item | Why It No Longer Matters | |---|---| | Competitor pricing audit | Sales already pulled this data for Thursday's QBR independently — duplicate effort | | Slack channel reorg | Nice-to-have that nobody has asked about since you proposed it three weeks ago |
**This Week's Priorities** (capacity: 24 available hours after 16 hours of fixed meetings) | Priority | Why It's In | Est. Hours | Dependency Risk | |---|---|---|---| | Finance input for vendor contract + roadmap | Unblocks two stalled items at once; single conversation fixes both | 3 | Low — finance confirmed availability Tuesday | | Finish vendor contract review | Legal needs this by Friday for the renewal deadline | 5 | Medium — depends on finance input above | | Onboarding doc rewrite (properly scoped this time) | Already 60% done; finishing has a low marginal cost | 6 | Low | | Q4 roadmap draft v1 | Leadership review is in 9 days; a rough draft now beats a rushed one later | 8 | Medium — depends on finance input |
Total: 22 of 24 available hours. Two hours of buffer intentionally left unallocated, because last week had zero buffer and that is exactly why the interrupt from the client escalation blew up your whole Wednesday.
**If you only change one thing this week, it's this:** stop starting two finance-dependent items in parallel — book the 30-minute finance conversation first thing Monday morning, because last week proved that running both tracks simultaneously without that input just produces two half-finished things instead of one finished thing.
بیشتر پرامپت‌های «برنامه‌ریزی هفتگی» فقط یه لیست آرزو رو برمی‌دارن و دوباره مرتبش می‌کنن. اون بخشی رو که واقعاً مهمه جا می‌ندازن: فهمیدن اینکه چرا برنامه‌ی هفته‌ی قبل در برخورد با واقعیت دووم نیاورد، تا این هفته همون لیست غیرواقعی رو دوباره نسازی.
این پرامپت یه ترتیب سه‌مرحله‌ای رو تحمیل می‌کنه — تشخیص، تطبیق، برنامه‌ریزی دوباره — و تا این سه تا رو طی نکنی اجازه نمی‌ده به اولویت‌های این هفته دست بزنی. مرحله‌ی تشخیص از همه مهم‌تره. «نرسیدم بهش» علت ریشه‌ای نیست؛ دست‌کم گرفتن حجم کار، یه وابستگیِ مسدودکننده، یه وقفه‌ی ناگهانی، ترتیب چینی غلط، یا تعهد بیش از ظرفیت، علت ریشه‌ای هستن. اسم گذاشتن روی الگوی واقعی همون چیزیه که جلوی تکرار هفته‌ی قبل رو می‌گیره.
مرحله‌ی تطبیق همون بخشیه که بیشتر ابزارهای برنامه‌ریزی کامل نادیده‌ش می‌گیرن. کارهای ناتمام خودبه‌خود لیاقت یه جا توی لیست این هفته رو ندارن — بعضی‌هاشون از وقتی نوشتیشون صرفاً بی‌ربط شده‌ان. پرامپت مجبورت می‌کنه اینو بلند بگی و دلیلش رو هم بگی، به جای اینکه بذاری یه to-do بی‌صدا تبدیل به یه بک‌لاگ دائمی بشه.
مرحله‌ی برنامه‌ریزی دوباره عمداً به ظرفیت واقعی محدود شده. ساعت‌های واقعیِ در دسترست رو به مدل می‌دی — کل ساعت‌ها منهای هر چیزی که از قبل توی جلسه‌ها قفل شده — و مدل باید اولویت‌ها رو توی همون عدد واقعی جا بده، نه توی یه هفته‌ی خیالیِ ۴۰ ساعته که هیچ چیز دیگه‌ای توش اتفاق نمی‌افته. اگه حتی بعد از سقف گذاشتن روی لیست هم حساب‌وکتاب جور در نیاد، به پرامپت گفته شده که مستقیم اینو بگه، نه اینکه بی‌صدا دوباره وعده‌ی بیشتر از توان بده.
این برای کیه: هر کسی که بیشتر هفته‌ها رو با یه تیکه از برنامه‌ی انجام‌نشده تموم می‌کنه و هفته‌ی بعد رو فقط با کپی کردن باقی‌مونده‌ها روی یه لیست جدید شروع می‌کنه، بدون اینکه بپرسه آیا این حرکت اصلاً درسته یا نه.
چطور تطبیقش بدی: ورودیِ «واقعاً چی شد» لازم نیست مرتب و آراسته باشه — یه گزارش خام و صادقانه از کارهایی که انجام شد، عقب افتاد یا ترکید بهتر از یه نسخه‌ی تمیزکاری‌شده جواب می‌ده، چون مرحله‌ی تشخیص به همون آشفتگی واقعی تکیه می‌کنه تا الگوی واقعی رو پیدا کنه.