صندوق تصمیم اجرایی: جدا کردن وضعیت از تصمیم
صندوق ورودی مدیرعامل: دویست ایمیل، پانزده رشته در چت تیمی، سه داشبورد. همه «فوری». هیچکدام تصمیم صریح نیست — بیشتر وضعیت با عنوان گمراهکننده. نتیجه: هفته در حالت واکنشی؛ تصمیمهای راهبردی به «بعد از فصل» موکول میشود. مدیر پروژه با ده گلولهٔ وضعیت پاسخ همگانی میفرستد؛ مدیر مالی نمیداند کدام مورد نیاز به امضا دارد.
صندوق تصمیم اجرایی در WKFGo همان ابزار صندوق تصمیم (decision_inbox) است: صف اولویتبندیشده از مواردی که نیاز به تصمیم انسان دارند — یا توسط پایشگر پسزمینه وقتی سیگنال از آستانه رد میکند بالا میآید، یا دستی با افزودن آیتم تصمیم (add_decision_item). هر مورد شواهد دارد؛ حلقهٔ استاندارد: خلاصه → بحث → شبیهسازی → بستن. مدیران به وضعیت بیشتر نیاز ندارند — به انتخاب ساختیافته نیاز دارند.
علائم و هزینهٔ سیل اعلان
| علامت | هزینهٔ پنهان |
|---|---|
| دویست ایمیل «فوری» | حالت واکنشی؛ کار راهبردی عقب میافتد |
| «تسک فلان معوق است» بدون گزینه | آگاهی بدون اقدام |
| پیام چت = اولویت | قطع تمرکز بدون رتبهبندی |
| جلسه = ریختن وضعیت | تصمیم در پنج دقیقهٔ آخر |
| بستن بدون مالک | پاسخگویی صفر |
تفاوت صندوق تصمیم با اعلان معمولی
| اعلان | آیتم صندوق تصمیم |
|---|---|
| «تسک فلان معوق است» | «کاهش محدوده یا تأخیر انتشار؟ شواهد: دوازده مورد بحرانی معوق» |
| خلاصهٔ اطلاعرسانی | تصمیم با مالک و مهلت |
| پیام لحظهای در چت | صف اولویتبندیشده |
| خواندن منفعل | اقدام: بستن آیتم تصمیم (resolve_decision_item) |
دامنهٔ اعلانهای WKFGo (فهرست اعلانها / list_notifications) جداست — اعلان برای آگاهی، صندوق برای تصمیم. خلاصهٔ اجرایی یکپارچه در هر چرخهٔ پایشگر یک پیام تجمیعی میفرستد، نه دهها اعلان جدا برای هر مدیر.
حلقهٔ تصمیم چهارمرحلهای
۱. جهتگیری — صندوق تصمیم
صبح یا قبل از جلسه: decision_inbox را باز کنید و مورد اول را بخوانید.
۲. شواهد — خلاصهٔ اجرایی
برای همان مورد: خلاصهٔ اجرایی (executive_brief) با نقش مناسب (مثلاً مدیر عملیات برای تحویل). واقعیتها و تشخیص را بخوانید و شکافهای داده را صادقانه بپذیرید — عدد نسازید.
۳. گزینهها — شبیهسازی سناریو
قبل از تعهد، شبیهسازی سناریو (simulate_scenario) را با حالتهای فارسینام اجرا کنید:
| فارسی | کد ابزار |
|---|---|
| تأخیر انتشار | delay_release |
| کاهش محدوده | cut_scope |
| افزودن نیرو | add_people |
| توقف پروژه | freeze_project |
خروجی معمولاً پنج بُعد با سطح اطمینان و فرضها است — آیندهها را کنار هم بگذارید، نه یک عدد جادویی.
۴. تعهد — بستن آیتم
تصمیم بگیرید و با resolve_decision_item ببندید. ثبت خودکار برای کالیبراسیون هفتهٔ بعد در بخش روند خلاصهٔ اجرایی استفاده میشود.
چارچوب هفتگی برای تیم رهبری
دوشنبه — بیست دقیقه: سه مورد اول صندوق؛ برای هر کدام مالک تعیین کنید.
چهارشنبه: شبیهسازی برای موردی که گیر کرده.
جمعه: بستن + ثبت تصمیم (record_decision) برای ردپای ممیزی.
شاخص: موارد بازشده در برابر بستهشده در برابر بهتعویقافتاده. افزایش مداوم موارد باز = مشکل ظرفیت یا کیفیت داده.
قانون اولویت وقتی صندوق شلوغ است
اگر بیش از پنج مورد باز دارید:
- اثر بر تحویل — انتشار و مشتری اول
- برگشتناپذیری — تصمیم سختبرگشت بالاتر
- فرسایش زمان — نزدیکترین مهلت اول
- کیفیت شواهد — اطمینان بالاتر اول
اگر مساوی ماند، مدیرعامل یکی را انتخاب میکند و بقیه را صریح به تعویق میاندازد — نه اینکه همه «فوری» بمانند.
نمونهٔ جلسهٔ فقطتصمیم (سی دقیقه)
| بازه | کار |
|---|---|
| ۰ تا ۵ | مورد اول صندوق |
| ۵ تا ۱۵ | شواهد از executive_brief — بدون قطع |
| ۱۵ تا ۲۲ | گزینههای simulate_scenario |
| ۲۲ تا ۲۸ | بحث؛ مدیرعامل تنش را حل میکند |
| ۲۸ تا ۳۰ | resolve_decision_item + مالک |
بحث وضعیت ممنوع است؛ به بورد ناهمزمان ارجاع دهید.
کالیبراسیون و پاسخگویی روند
بعد از بستن، خلاصهٔ بعدی بخش روند را نشان میدهد: پیشبینی درست بود؟ شاخص هدف جابهجا شد؟ این حلقه یادگیری سازمانی است — نه تئاتر اسلاید.
هر مورد را همین هفته تصمیم نگیرید. بستن با وضعیت «بهتعویقافتاده» و تاریخ بازبینی معتبر است. صندوق شلوغ شکست نیست؛ موارد بدون مالک شکست است.
ضدالگوها
- تبدیل صندوق به انبار وضعیت — فقط مواردی که نیاز به تصمیم دارند
- رد شدن از شبیهسازی و تعهد کور
- بستن بدون مالک و زمانبندی
- محدود کردن
decision_inboxفقط به مدیرعامل — موارد مدیر عملیات و مدیر مالی جدا میمانند - ایمیل اطلاعرسانی را آیتم صندوق نکنید؛ لینک داشبورد بدهید
ابزارهای حلقهٔ تصمیم در WKFGo
decision_inboxوadd_decision_itemexecutive_briefوsimulate_scenarioresolve_decision_item،record_decision، جستوجوی تصمیمها (search_decisions)، ثبت دستی تصمیم (log_decision)
همه با دسترسی ویژگی (FeatureAccess) همان کاربر؛ ابزار رهبری معمولاً محدود به نقش مناسب است.
صندوق تصمیم در برابر داشبورد و ایمیل
داشبورد وضعیت را نشان میدهد؛ ایمیل آگاهی پخش میکند؛ صندوق تصمیم میپرسد «الان چه انتخابی لازم است؟». اگر موردی فقط اطلاع است، لینک داشبورد یا اعلان کافی است. اگر مورد نیاز به «بله / خیر / تعویق با تاریخ» دارد، جایش در صندوق است. این تفکیک ساده جلوی پر شدن صندوق از وضعیت روزمره را میگیرد و جلسهٔ رهبری را از ریختن گزارش نجات میدهد.
در عمل، تیمهایی که این مرز را رعایت میکنند سریعتر به حلقهٔ شواهد → شبیهسازی → تعهد میرسند و کمتر در بحث بیپایان «وضعیت چیست» گیر میکنند.
سوالات متداول
چه کسی آیتم اضافه میکند؟
پایشگر خودکار وقتی سیگنال از آستانه رد کند، بهعلاوهٔ مدیر پروژه با add_decision_item.
مجوز چگونه است؟
همان دسترسی ویژگی؛ ابزارهای رهبری معمولاً محدودند.
آیا جای جلسه را میگیرد؟
خیر. صندوق دستور کار جلسه را تغذیه میکند؛ جلسه برای حل تنش و تعهد است.
بعد از بستن چه میشود؟
روند در خلاصهٔ بعدی نشان میدهد آیا پیشبینی با واقعیت همخوان بود.