مشکل: «کند هستیم»، ولی کسی نمیداند کجا
تیم حس میکند کند شده — ددلاین عقب میافتد، جلسهٔ وضعیت طولانیتر میشود — ولی تا رسیدن به بحران هیچکس نمیداند گلوگاه دقیقاً کجاست. معمولاً وقتی مدیر پروژه بالاخره بورد را با دقت نگاه میکند، انبوهی از کارت در یک ستون (اغلب Review) هفتههاست ماندهاند؛ چیزی که با یک نگاه هفتگی به flow_aging خیلی زودتر دیده میشد.
ابزار اصلی برای این تشخیص flow_aging است — سن هر کارت در ستون فعلیاش. برای دیدن روند در طول زمان، نمودار جریان تجمعی (flow_cfd) نشان میدهد کدام باند دارد پهنتر میشود، یعنی کار پشت همان مرحله انباشته میشود.
علائم و هزینه
| علامت | هزینه |
|---|---|
| حدس بهجای داده | تصمیم دیر |
| ابزار جدا از سیستم PM | duplicate |
| هوش مصنوعی بدون بازبینی | اشتباه |
| متریک ظاهری | دستور شکستخورده |
| بدون owner | تکرار |
چارچوب تشخیص گلوگاه (۷ گام)
1. سیگنال پیشرو را تعریف کنید. کدام شاخص، قبل از رسیدن به ددلاین، نشان میدهد کاری گیر کرده — سن کارت در یک ستون، تعداد آیتم مسدود، یا پهنشدن یک باند در CFD؟ بدون یک سیگنال مشخص، «کند هستیم» فقط یک حس باقی میماند.
2. یک خط پایهٔ واقعی بسازید. دو اسپرینت flow_aging را بدون قضاوت ثبت کنید — عدد واقعی از سیستم، نه حکایت یک نفر در جلسهٔ روزانه.
3. از ابزار MCP بخوانید، نه از اکسل دستی. خروجی flow_aging و flow_cfd مستقیماً از بورد میآید؛ کپی دستی در اکسل همان روز کهنه میشود.
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 قبل از هماهنگی — همان شاخص از جدول علائم. چهارشنبه: ماندگی کار یا نقشهٔ بار اگر مرتبط با جریان کار است. جمعه: اگر آزمایش عوض شد، ویکی را یک خط بهروز کنید.
سؤال تست: «اگر فردا ظرفیت ۳۰٪ کم شود، کدام بخش میشکند؟» — جواب باید به سیستم (فرآیند، ابزار، سیاست) اشاره کند نه فقط نام یک نفر.
تیمی که آزمایشی دو اسپرینت جدی بگیرد، قبل از گسترش شواهد دارد. جلسهٔ بازبینی فصلی: آیا شاخص پیشرو بهبود داشت؟ اگر نه، آزمایش عوض کنید نه ابزار.
امتحان کنید
این الگوها را روی داده زنده پروژه اجرا کنید — نه اسلاید.