مشکل: overdue دیر است
تأخیر — وقتی due گذشت، انتخاب کم است. پیشبینی تأخیر با flow_aging کار stuck را قبل از overdue نشان میدهد.
ابزار اصلی: flow_aging.
علائم و هزینه
| علامت | هزینه |
|---|---|
| حدس بهجای داده | تصمیم دیر |
| ابزار جدا از سیستم PM | duplicate |
| هوش مصنوعی بدون بازبینی | اشتباه |
| متریک ظاهری | دستور شکستخورده |
| بدون owner | تکرار |
چارچوب تأخیر (۷ گام)
1. تعریف سیگنال. چه شاخص پیشرو نشان میدهد مشکل دارد؟.
2. baseline. دو اسپرینت عدد واقعی — نه anecdote..
3. ابزار MCP. از سیستم بخوانید نه Excel..
4. بازبینی انسانی. هوش مصنوعی روایت میکند — انسان تأیید میکند..
5. اقدام با owner. تسک + تاریخ بازبینی..
6. اندازهگیری دوباره. همان شاخص دو هفته بعد..
7. ویکی راهنمای عملی. موفق را مستند کنید..
اشتباهات رایج
- ChatGPT روی خروجی Excel
- بدون بررسی دسترسی
- بازگشت سرمایه ساختگی
- بدون آزمایش محدود
- جایگزین قضاوت انسانی
نقش WKFGo
flow_aging— داده زنده- MCP — با رعایت دسترسی
- ویکی — راهنمای عملی
هوش مصنوعی باید سبکسنگین کردن گزینهها را به زبان ساده و با متریک واقعی بگوید؛ درصد بازگشت سرمایه ساختگی نسازد.
سناریوهای واقعی
آزمایشی: یک تیم کوچک دو اسپرینت با flow_aging.
| سناریو | چه زمانی بررسی شود | کد ابزار |
|---|---|---|
| تأخیر انتشار | اگر قرارداد/کیفیت اجازهٔ جابهجایی تاریخ بدهد | delay_release |
| کاهش محدوده | اگر تاریخ ثابت است و کار کمارزش قابل تعویق است | cut_scope |
| افزودن نیرو | اگر گلوگاه ظرفیت است نه وابستگی پیچیده | add_people |
| توقف پروژه | اگر پورتفولیو بیشبار است و باید شروع کار جدید قطع شود | freeze_project |
سؤالات متداول
از کجا شروع تأخیر؟
دردناکترین سیگنال.
ChatGPT کافی است؟
بدون داده زنده نه.
آیا انسان لازم است؟
بله؛ تعهد و تصمیم نهایی همیشه با انسان است.
MCP؟
flow_aging.
ریتم پیشنهادی
مدیرانی که این موضوع را فقط در جلسات بحران میبینند، هزینه واکنشگرایی میپردازند. متریک پیشرو هفتگی از آتشنشانی ماهانه ارزانتر است. ابزار بهتنهایی کافی نیست؛ سیاست، ریتم و مسئول نامبرده لازم است.
در یک دورهٔ آزمایشی دو اسپرینتی، یک تیم کوچک را با همین چارچوب اجرا کنید. شواهد قبل از الزام سازمانی به کل پورتفولیو. راهنمای عملی موفق را در ویکی بگذارید تا گسترش شود.
بازبینی هفتگی پانزده دقیقه با همان شاخص از کارگاه ماهانه مؤثرتر است. وقتی علامت برمیگردد، اول سیاست و تعریف را بازبینی کنید نه سرزنش فرد.
رهبری باید سبکسنگین کردن گزینهها را صریح بپذیرد: افزودن کار بدون حذف کار دیگر، یا رفع موضعی، همان الگوی شکست قبلی را تکرار میکند. مدیر پروژه تفسیر اضافه میکند؛ عدد از سیستم میآید.
هر فصل جدول علائم را دوباره بازبینی کنید — بازار و تیم عوض میشوند. شروع کوچک امروز از برنامهریزی بزرگ فردا بهتر است.
دوشنبه: خلاصهٔ MCP قبل از هماهنگی — همان شاخص از جدول علائم. چهارشنبه: ماندگی کار یا نقشهٔ بار اگر مرتبط با جریان کار است. جمعه: اگر آزمایش عوض شد، ویکی را یک خط بهروز کنید.
سؤال تست: «اگر فردا ظرفیت ۳۰٪ کم شود، کدام بخش میشکند؟» — جواب باید به سیستم (فرآیند، ابزار، سیاست) اشاره کند نه فقط نام یک نفر.
تیمی که آزمایشی دو اسپرینت جدی بگیرد، قبل از گسترش شواهد دارد. جلسهٔ بازبینی فصلی: آیا شاخص پیشرو بهبود داشت؟ اگر نه، آزمایش عوض کنید نه ابزار.
امتحان کنید
این الگوها را روی داده زنده پروژه اجرا کنید — نه اسلاید.