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