اعلان زیاد = اعلان بیاثر
خستگی اعلان: وقتی همه چیز فوری است، تیم اعلان را خاموش میکند. سیاست: فقط تصمیم، مهلت واقعی، mention مستقیم.
list_notifications و mark_notifications_read — کمتر سر و صدا.
علائم و هزینه
| علامت | هزینه |
|---|---|
| هر تغییر کوچک روی هر تسک برای همه اعضا اعلان میفرستد | تیم بعد از چند روز کل اعلانها را خاموش میکند |
| اعلان واقعاً فوری (منشن مستقیم، تغییر مهلت) بین صد اعلان دیگر گم میشود | تصمیم مهم دیر دیده میشود |
| هر پروژه و هر تیم یک قانون اعلان جدا و شفاهی دارد | عضو جدید یا اطلاعرسانی میکند یا سکوت میکند، هیچکدام درست نیست |
| اعلان ایمیلی و اعلان درونبرنامهای دو منبع جدا هستند | پیام دو بار خوانده میشود یا اصلاً خوانده نمیشود |
| هیچکس اعلانهای خواندهنشده را پاکسازی نمیکند | صف اعلان به آرشیو بیفایده تبدیل میشود |
چارچوب عملی
1. اعلانها را به دو دسته تقسیم کنید: تصمیم و اطلاع
«فلان تسک مهلتش نزدیک شد و مسئول تویی» یک تصمیم است. «فلانکس یک کامنت اضافه کرد» فقط اطلاع است. اگر هر دو با یک صدا و یک شکل به همه میرسند، مغز تیم دیگر فرقشان را یاد نمیگیرد.
2. اعلان پیشفرض را کم کنید، نه اضافه
نقطهٔ شروع درست، خاموشبودن اکثر اعلانهای فرعی است — نه روشنبودن همه و بعد امید به اینکه هرکس خودش کم کند. کمتر اعضا این کار را میکنند و نتیجه همان انباشت قبلی است.
3. فقط منشن مستقیم، مهلت، و تغییر مسئولیت را برجسته کنید
این سه مورد تقریباً همیشه نیاز به واکنش واقعی دارند. بقیه — کامنت عمومی، تغییر برچسب، جابهجایی ستون — میتوانند در نمای بورد بمانند بدون پوش نوتیفیکیشن جداگانه.
4. اعلانهای خواندهشده را مرتب پاکسازی کنید
mark_notifications_read صف را کوتاه نگه میدارد. صف طولانیِ خواندهنشده باعث میشود آدم اصلاً باز نکند — دقیقاً نقطهٔ مقابل هدف اعلان.
5. برای هر پروژه یک سیاست واحد بنویسید، نه سلیقهٔ فردی
اگر هر عضو تنظیمات شخصی متفاوت دارد، هماهنگی تیمی سخت میشود («مگه بهت اطلاع ندادم؟»). یک استاندارد ساده در ویکی پروژه — چه چیزی اعلان میشود، چه چیزی نه.
6. اعلان فوری واقعی را از صف تصمیم جدا کنید
مواردی که نیاز به تصمیم مدیریتی دارند، جای درستشان decision_inbox است، نه یک اعلان معمولی بین صد مورد دیگر. اعلان فقط باید بگوید «اینجا یک تصمیم منتظر است»، خودِ محتوا در صف تصمیم زندگی میکند.
7. بعد از دو هفته، صندوق ورودی هر عضو را بررسی کنید
اگر بعد از تنظیم سیاست هنوز کسی دهها اعلان بازنشده دارد، یا سیاست اجرا نشده یا هنوز عمومی است. یک نگاه سریع کافی است تا بفهمید کدام حالت است.
نکات تکمیلی برای اجرا
خستگی اعلان معمولاً از حسننیت شروع میشود — تیم میخواهد همه چیز را به همه اطلاع دهد تا کسی جا نماند. نتیجهٔ عملی برعکس است: وقتی همهچیز اعلان میشود، مغز آدم یاد میگیرد که کل اعلانها را نادیده بگیرد، حتی مورد واقعاً فوری.
راهحل «اعلان بیشتر» نیست، «اعلان دقیقتر» است. تیمی که فقط سه نوع رویداد را اعلان میکند — منشن مستقیم، مهلت نزدیک، تغییر مسئولیت — معمولاً با حجم کمتر، واکنش سریعتری میگیرد از تیمی که همهچیز را اعلان میکند.
اشتباهات رایج
- روشنگذاشتن همهٔ اعلانها بهعنوان پیشفرض «برای احتیاط»
- اعلان تصمیم مهم را با همان شکل اعلان کامنت معمولی فرستادن
- نداشتن سیاست مکتوب — هر عضو تنظیمات خودش را حدس میزند
- عدم پاکسازی اعلانهای خواندهشده — صف بیفایده میشود
- استفاده از اعلان بهجای صف تصمیم برای مواردی که واقعاً نیاز به تصمیم دارند
نقش WKFGo
list_notifications (اعلانها) — یک نمای واحد، قابل فیلتر بر اساس نوع رویداد.
mark_notifications_read (خواندهشده) — صف را کوتاه نگه میدارد تا مورد فوری واقعی گم نشود.
decision_inbox (صف تصمیم) — مواردی که واقعاً نیاز به تصمیم دارند را از اعلانهای عادی جدا نگه میدارد.
سناریوی عملی در تیم ایرانی
الگوی رایج: عضو جدید که وارد تیم میشود، همهٔ اعلانها را روشن نگه میدارد چون نمیداند کدام مهم است. بعد از دو هفته، دیگر باز نمیکند — و همان لحظهای که یک مهلت واقعی نزدیک است را هم از دست میدهد. راهحل این نیست که به او بگویید «خودت تنظیم کن»؛ سیاست پیشفرض پروژه باید از اول کم و دقیق باشد، نه اینکه هر عضو جدید مجبور شود خودش کشف کند چه چیزی را خاموش کند.
همترازی با ذینفعان
| نقش | سؤال هفتگی | اقدام در WKFGo |
|---|---|---|
| مدیر پروژه | گلوگاه کجاست؟ | برد + گزارش |
| لید فنی | چه کسی مسدود است؟ | my_queue (صف من) |
| مدیر اجرایی | چه تصمیمی لازم است؟ | decision_inbox (صف تصمیم) |
| مالی | هزینه همخوان است؟ | finance_summary (خلاصه مالی) |
سؤالات متداول
اگر همه اعضا سلیقهٔ متفاوت برای اعلان داشته باشند چه؟
یک حداقل مشترک برای کل پروژه تعیین کنید (منشن، مهلت، مسئولیت) و اجازه دهید فرد فقط روی موارد اضافهتر تنظیم شخصی داشته باشد — نه برعکس.
اعلان ایمیلی هم باید کم شود؟
بله، با همان قاعده. ایمیل برای خلاصهٔ دورهای مناسب است (مثل دایجست هفتگی)، نه برای هر رویداد لحظهای که در اعلان درونبرنامه هم هست.
چطور بفهمیم سیاست جدید جواب داده؟
تعداد اعلانهای باز/نخوانده در پایان هفته را نگاه کنید. اگر عدد پایین آمد و مورد فوری هنوز دیده میشود، سیاست کار کرده.
WKFGo چه کمکی میکند؟
اعلانهای قابل فیلتر، صف تصمیم جدا از اعلان معمولی، و پاکسازی سریع خواندهشدهها — بدون نیاز به ابزار جدا برای هشدار.
جمعبندی
خستگی اعلان با کاهش پیشفرض، جداسازی تصمیم از اطلاع، و یک سیاست مشترک برای کل پروژه قابل حل است — نه با اعلان بیشتر.