یک درصد دقیق بدون داده، فقط نمایش مدیریتی است
پرسش «احتمال موفقیت پروژه چند درصد است؟» جذاب است، اما جواب‌هایی مثل ۷۲٪ معمولاً بیشتر از آنکه تحلیل باشند، خوش‌بینی را با ظاهر آماری ارائه می‌کنند. اگر معلوم نباشد عدد بر چه داده‌ای تکیه دارد، چه فرض‌هایی پشت آن است و چه زمانی باید دوباره محاسبه شود، نه قابل ممیزی است و نه بعداً می‌توان دقت آن را سنجید.
روش قابل اتکاتر این است که موفقیت را مشروط تعریف کنیم: «اگر محدوده تا پایان این اسپرینت ثابت بماند، صف بازبینی از سه روز عبور نکند و تأمین‌کننده تا تاریخ مشخص تحویل دهد، رسیدن به تاریخ هدف محتمل است.» سپس چند تصمیم واقعی را با داده زنده پروژه مقایسه کنیم.
در WKFGo ابزار simulate_scenario برای همین مقایسه طراحی شده است. این ابزار قرار نیست آینده را پیشگویی کند؛ مسیرهایی مانند delay_release، cut_scope، add_people و freeze_project را با فرض‌ها و عدم‌قطعیت‌های روشن کنار هم می‌گذارد تا مدیر بتواند تصمیم بگیرد و آن تصمیم را بعداً کالیبره کند.
قبل از شبیه‌سازی چه داده‌ای لازم است؟
حداقل این پنج دسته سیگنال را آماده کنید:
| سیگنال | پرسش مدیریتی | منبع پیشنهادی |
|---|---|---|
| ماندگی کار | کدام آیتم‌ها بیش از حد در یک ستون مانده‌اند؟ | flow_aging |
| روند جریان | صف Review یا Testing در حال رشد است؟ | flow_cfd |
| ظرفیت | گلوگاه روی یک فرد یا نقش خاص است؟ | workload_heatmap |
| هزینه | نرخ مصرف بودجه با تحویل واقعی هم‌خوان است؟ | finance_summary |
| وابستگی و تصمیم | چه مانعی خارج از کنترل تیم مانده است؟ | گزارش پروژه و decision_inbox |
اگر این داده‌ها ناقص‌اند، خروجی باید صریحاً «شکاف داده» را اعلام کند. هوش مصنوعی نباید جای خالی را با عددی مطمئن‌نما پر کند.
چارچوب عملی: سیگنال → سناریو → تصمیم → کالیبراسیون
۱. موفقیت را قابل آزمون تعریف کنید
«پروژه موفق» تعریف قابل سنجشی نیست. مشخص کنید منظور تحویل چه محدوده‌ای، تا چه تاریخی، با چه سقف بودجه و با چه معیار پذیرشی است. اگر این چهار مورد روشن نباشد، هیچ مدل یا داشبوردی احتمال معنادار تولید نمی‌کند.
۲. خط پایه بسازید
حداقل دو اسپرینت یا چهار هفته داده واقعی بردارید: تعداد کارهای تکمیل‌شده، سن آیتم‌های باز، زمان انتظار برای تأیید، واریانس هزینه و تعداد تغییرات محدوده. داده یک هفته خاص ممکن است تحت تأثیر تعطیلات یا انتشار اضطراری باشد.
۳. دست‌کم دو مسیر را مقایسه کنید
یک سناریو فقط همان برنامه فعلی را توجیه می‌کند. برای مثال این سه مسیر را کنار هم بگذارید:
- تاریخ ثابت، کاهش قابلیت‌های کم‌ارزش؛
- حفظ محدوده، جابه‌جایی تاریخ تحویل؛
- افزودن نیرو با درنظرگرفتن زمان onboarding و افزایش هماهنگی.
هر مسیر باید فرض، هزینه، ریسک و نشانه شکست زودهنگام داشته باشد. simulate_scenario این گفت‌وگو را ساختاریافته می‌کند، اما انتخاب نهایی همچنان با تیم رهبری است.
۴. به‌جای درصد جادویی، بازه و شرط ارائه کنید
گزارش خوب می‌گوید: «با حذف قابلیت X و ثابت‌ماندن ظرفیت Review، تاریخ هدف قابل دفاع است؛ اگر صف Review دو هفته متوالی بالاتر از آستانه بماند، باید تاریخ یا محدوده دوباره تصمیم‌گیری شود.» این جمله برای ذی‌نفع قابل پیگیری‌تر از «احتمال موفقیت ۶۸٪» است.
۵. تصمیم را ثبت کنید
مسیر انتخاب‌شده، فرض‌ها، مالک اقدام، زمان بازبینی و معیاری که تصمیم را رد می‌کند در log_decision ثبت شود. بدون این رسید، بعد از شکست همه می‌توانند ادعا کنند از ابتدا نظر دیگری داشته‌اند.
۶. پیش‌بینی را کالیبره کنید
در تاریخ بازبینی، خروجی واقعی را با سناریوی ثبت‌شده مقایسه کنید: کدام فرض درست نبود؟ آیا سیگنال پیشرو را دیر دیدید؟ آیا تصمیم اثر مورد انتظار را روی متریک گذاشت؟ هدف کالیبراسیون سرزنش نیست؛ هدف این است که پیش‌بینی بعدی کمتر متکی به حس باشد.
نمونه جلسه ۴۵ دقیقه‌ای قبل از تعهد به مشتری
شرکت می‌خواهد تاریخ انتشار را در قرارداد اعلام کند، اما یکپارچه‌سازی پرداخت هنوز وابسته به فروشنده بیرونی است و صف Code Review رو به رشد است.
- مدیر پروژه گزارش، وابستگی‌ها و ده آیتم پیر را قبل از جلسه آماده می‌کند.
- مدیر محصول مشخص می‌کند کدام قابلیت واقعاً برای پذیرش مشتری لازم است.
- لید فنی ظرفیت Review و ریسک فروشنده را تأیید می‌کند.
- تیم دو خروجی
simulate_scenarioبرای «کاهش محدوده» و «تأخیر انتشار» مقایسه می‌کند. - تصمیم با یک trigger ثبت می‌شود: اگر فروشنده تا تاریخ توافق‌شده تحویل نداد، سناریوی دوم فعال شود.
خروجی جلسه یک درصد تزئینی نیست؛ یک تعهد مشروط و قابل اجراست.
چه زمانی این روش مناسب نیست؟
- وقتی برد به‌روز نمی‌شود و داده جریان قابل اعتماد نیست؛
- وقتی پروژه کاملاً پژوهشی است و هنوز تعریف خروجی ندارد؛
- وقتی تصمیم اصلی حقوقی، ژئوپلیتیک یا وابسته به عاملی خارج از داده سازمان است؛
- وقتی مدیریت صرفاً عددی برای تأیید تصمیم ازپیش‌گرفته‌شده می‌خواهد.
در این وضعیت‌ها ابتدا کیفیت داده و اختیار تصمیم را اصلاح کنید. اضافه‌کردن AI فقط اطمینان کاذب را سریع‌تر تولید می‌کند.
پرسش‌های متداول
آیا simulate_scenario مونت‌کارلو اجرا می‌کند؟
این ابزار سناریوهای ساختاریافته را با فرض‌های مشخص مقایسه می‌کند و نباید بدون سند به‌عنوان شبیه‌سازی کامل مونت‌کارلو معرفی شود.
می‌توان این بررسی را هفتگی خودکار کرد؟
مانیتورها می‌توانند با عبور سیگنال‌ها از آستانه، آیتمی در decision_inbox بسازند؛ تفسیر و تصمیم نهایی باید انسانی بماند.
اگر داده کافی نداریم چه کنیم؟ دامنه ادعا را کوچک کنید، شکاف داده را بنویسید و ابتدا یک خط پایه دو اسپرینتی بسازید؛ عدد ساختگی از «هنوز نمی‌دانیم» خطرناک‌تر است.
این روش چه تفاوتی با گانت دارد؟ گانت برنامه و وابستگی زمانی را نشان می‌دهد؛ تحلیل سناریو بررسی می‌کند آن برنامه تحت فرض‌های واقعی تا چه حد دوام می‌آورد.
یک تصمیم واقعی را با داده پروژه آزمایش کنید
اگر اکنون میان کاهش محدوده، جابه‌جایی تاریخ یا افزودن نیرو مردد هستید، یک پروژه واقعی را وارد پایلوت کنید و دو سناریو را پیش از جلسه بعدی مدیریت مقایسه کنید.