Executive Docket و Attention Compression

1. مسئله واقعی: مدیر به «پیام بیشتر» نیاز ندارد، به «تصمیم روشن‌تر» نیاز دارد

وقتی ایمیل، تیکت، هشدار، پیام و task زیاد می‌شوند، خلاصه‌سازی ساده فقط حجم متن را کم می‌کند؛ اما ممکن است همان تعهد را چهار بار نشان دهد یا یک مورد کم‌اهمیتِ پرسر‌وصدا را بالا بیاورد. Executive Docket باید تعداد سیگنال‌ها را به تعداد کمی decision item تبدیل کند و در عین فشرده‌سازی، دلیل، شواهد و مسیر drill-down را حفظ کند.

2. مرز درس و Artifact مالک

خروجی این درس Executive Attention Docket & Compression Ledger v1 است. هر ردیف باید underlying_object، source_refs، decision_needed، actionability، urgency، impact، confidence، owner، next_action، due_or_recheck، duplicate/suppression، priority_band، risk_if_ignored و drilldown_ref داشته باشد. Notification Routing متعلق به PLN-006 و PII/Privacy متعلق به PLN-008 است.

3. Signal را با Decision Item اشتباه نگیر

چهار پیام درباره یک تعهد، چهار تصمیم اجرایی نیستند. ابتدا signalها را normalize کن، سپس بر اساس موضوع زیربنایی تصمیم/تعهد/فرصت گروه‌بندی کن. تعداد پیام یا کانال فقط یک ویژگی مشاهده‌ای است؛ نه واحد توجه مدیریتی.

4. Compression باید reversible باشد

اگر مدیر فقط یک عنوان کوتاه ببیند ولی نتواند بفهمد این مورد از کدام شواهد ساخته شده، compression قابل حسابرسی نیست. هر docket item باید source_refs و drilldown_ref داشته باشد تا بتوان از خلاصه به شواهد اصلی برگشت. این همان جایی است که provenance از «تزئین متادیتا» به بخشی از تصمیم تبدیل می‌شود.

5. Actionability قبل از Urgency

Google SRE در حوزه alerting تأکید می‌کند alert باید actionable باشد؛ هشداری که انسان اقدام مشخصی برایش ندارد noise ایجاد می‌کند. در این درس از این اصل فقط به‌عنوان مرز عملی استفاده می‌کنیم: اگر decision_needed یا next_action روشن نیست، urgency بالا به‌تنهایی نباید آن مورد را به بالای docket ببرد.

6. Immediate و Later را از هم جدا کن

در راهنمای SRE، alert برای اقدام فوری و ticket برای اقدامی است که لازم است اما فوریت لحظه‌ای ندارد. Executive Docket همان taxonomy را کپی نمی‌کند؛ اما از این تفکیک یاد می‌گیرد که زمان پاسخ و وجود اقدام انسانی دو بعد جدا هستند. یک مورد می‌تواند مهم باشد ولی در window بعدی رسیدگی شود.

7. Impact، Urgency و Confidence سه چیز متفاوت‌اند

impact می‌گوید اگر موضوع درست باشد چه دامنه‌ای از اثر دارد. urgency می‌گوید window اقدام چقدر کوتاه است. confidence می‌گوید شواهد فعلی چقدر مطمئن‌اند. اشتباه خطرناک این است که confidence بالا را جای impact بگذاریم یا confidence پایین را دلیل حذف یک خطر بالقوه بزرگ بدانیم.

8. Priority Band را از قواعد چندبعدی بساز

Priority نباید فقط با یک score مرموز تعیین شود. برای هر ردیف، حداقل actionability، urgency، impact، confidence، risk_if_ignored و due/recheck را کنار هم ببین. اگر یک بعد تعیین‌کننده مبهم است، REVIEW_REQUIRED بهتر از رتبه‌بندی قطعی است. هدف «عدد دقیق» نیست؛ هدف تصمیم قابل توضیح است.

9. Duplicate Suppression باید evidence-preserving باشد

اگر یک تعهد در ایمیل، Slack، CRM و notification تکرار شده، یک docket item بساز و duplicate_count=4 و suppression_reason را ثبت کن. Suppression به معنی حذف provenance نیست؛ source refs تمام نمونه‌های مرتبط باید قابل drill-down بمانند.

10. Owner و Next Action باید اجرایی باشند

عبارت‌هایی مثل «تیم پیگیری کند» یا «بررسی شود» برای docket اجرایی کافی نیست. Owner باید یک role/مسئول مشخص در fixture داشته باشد و Next Action باید رفتاری قابل انجام باشد. اگر Owner معلوم نیست، item ممکن است REVIEW_REQUIRED شود حتی اگر impact بالا باشد.

11. Due/Recheck جلوی آیتم‌های بی‌انتها را می‌گیرد

هر item باید یا due مشخص داشته باشد یا condition بازبینی. REVIEW_REQUIRED بدون finite trigger یعنی صفی که هیچ‌وقت بسته نمی‌شود. مثال: «تا ۱۴:۰۰ سند privacy را بررسی کن؛ اگر authority تأیید نشد، escalate به reviewer» بهتر از «بعداً بررسی شود» است.

12. Worked Example: 26 پیام، فقط دو تصمیم

فرض کن 26 پیام جدید داریم. چهار پیام و دو notification همگی یک تعهد قراردادی را تکرار می‌کنند؛ هفت پیام status update کم‌اثرند؛ یک موضوع پرداخت نیازمند تصمیم امروز است. Ledger باید تکرارها را به یک item فشرده کند، statusها را DEFER/EXCLUDE کند و برای پرداخت، decision_needed و next_action صریح بسازد. تعداد پیام هرگز به‌تنهایی priority را تعیین نمی‌کند.

13. چهار حالت تصمیم را شفاف نگه دار

INCLUDE_NOW یعنی evidence کافی برای قرارگرفتن در attention window جاری وجود دارد. DEFER یعنی اقدام لازم است ولی نه در window فعلی. REVIEW_REQUIRED یعنی مسئله ممکن است مهم باشد اما evidence/owner/provenance تعیین‌کننده ناقص است. EXCLUDE یعنی actionable executive decision وجود ندارد یا signal informational/duplicate صرف است.

14. Failure Probeهای قطعی

چهار shortcut باید fail شوند: (۱) همان تعهد در چهار کانال و چهار ردیف docket؛ (۲) informational item با confidence بالا ولی impact/actionability پایین؛ (۳) privacy concern با impact بالا و confidence ناقص که صرفاً به‌خاطر confidence پایین حذف شود؛ (۴) summary بدون drill-down provenance. هرکدام باید تصمیم یا rationale متفاوت ایجاد کند، نه ranking خام بر پایه شمارش.

15. Transfer: خطر کم‌اطمینان کنار کارهای روتین پر‌اطمینان

در Transfer، چند task روتین با confidence بالا کنار یک privacy concern کم‌اطمینان اما پراثر قرار می‌گیرند. Baseline را کپی نکن. برای concern، impact و risk_if_ignored را مستقل از confidence محاسبه کن، missing evidence را صریح ثبت کن و یک recheck/escalation finite بساز. هدف این است که uncertainty حفظ شود بدون اینکه risk پنهان شود.