ممیز جلسات تکراری: تصمیم بگیرید کدام جلسات ثابت هنوز ارزش جای خود در تقویم را دارند

چرا این پرامپت اهمیت دارد
A mid-size team carrying even 3 unnecessary weekly meetings at 5-8 attendees and 30-45 minutes each burns 8-12 hours of collective team time every single week — 400-600+ hours a year, the rough equivalent of a quarter of a full-time employee's annual hours, spent on meetings that evaporate the moment someone asks "what decision does this produce?" and nobody has a clean answer.
ما از آن برای چه استفاده میکنیم
Your 12-person engineering team has 6 standing meetings on the calendar, several inherited from a reorg 18 months ago. Nobody fully remembers why half of them exist, and two engineers have separately mentioned losing a full morning a week to meetings. You need an objective, defensible way to decide what to cut without personally arguing the case in a room full of people who each created one of these meetings.
پرامپت
Role: Act as an operations efficiency consultant who has audited meeting calendars at dozens of companies and specializes in identifying "zombie meetings" — recurring meetings that have outlived their original purpose. Context: Team/company context: [TEAM SIZE AND FUNCTION, e.g., "12-person engineering team"]. Recurring meetings list — for each one, provide: name, frequency, duration, number of attendees, who created it and roughly when (if known), and its stated purpose (if known, otherwise write "unknown"): [LIST YOUR RECURRING MEETINGS, ONE PER LINE, WITH AS MUCH OF THE ABOVE AS YOU KNOW] Task: For each meeting, score it against four criteria: 1. Decision-making value — does this meeting produce a decision that couldn't be made async? 2. Information transfer that could be async — is most of the content a status update that could be a written doc or message instead? 3. Attendee necessity — are all attendees actually needed for the full duration, or could most of it be a smaller group? 4. Staleness — does the stated (or inferred) original purpose still match what the team actually needs today? Based on the scoring, output a verdict for each meeting: KEEP AS-IS / SHORTEN / MAKE ASYNC / KILL, with one or two sentences of reasoning, and — for SHORTEN or MAKE ASYNC verdicts — a specific suggested replacement (e.g., "a shared doc updated by Friday EOD" or "a 15-minute version with only the 3 people who make the decision"). Constraints: Do not recommend killing meetings that involve legally required reviews, client-facing calls, or 1:1s unless the input explicitly flags them as low-value. Be specific about what exactly becomes async — never just write "make this async" without naming the replacement format. Identify the single highest-value meeting on the list and explicitly flag it as one to protect from any future cuts. Output Format: ## Meeting-by-Meeting Verdicts [Table or list: Meeting Name | Verdict | Reasoning | Replacement (if applicable)] ## Protect This One [Name the single highest-value meeting and why] ## Time Reclaimed [If every SHORTEN and KILL recommendation is implemented, calculate total attendee-hours per week reclaimed, using the duration and attendee count provided for each affected meeting]
نتیجه
Meeting-by-Meeting Verdicts
| Meeting | Verdict | Reasoning | Replacement |
|---|---|---|---|
| Monday Status Sync (30 min, 8 people, weekly) | MAKE ASYNC | Each person reports what they did last week with no discussion or decisions made — pure status broadcast that doesn't need real-time attendance from 8 people. | A shared doc or Slack thread where each person posts 2-3 bullet points by Monday 10am. |
| Design Review (45 min, 6 people, weekly) | SHORTEN | Real decisions get made here, but only 3 of the 6 attendees speak in a typical session — the other 3 are there "for visibility." | 25-minute session with the 3 decision-makers; others get the decision summary afterward. |
| All-Hands Engineering (60 min, 12 people, weekly) | KEEP AS-IS | Genuinely serves cross-team alignment and surfaces blockers that would otherwise stay siloed — attendee feedback in the input confirms this is considered useful. | — |
| Retro (30 min, 8 people, bi-weekly) | KEEP AS-IS | Produces concrete process changes most cycles; this is decision-making work, not status reporting. | — |
| Legacy "Project Phoenix" Check-in (30 min, 5 people, weekly) | KILL | Project Phoenix shipped four months ago. Nobody on the list could state its current purpose when asked; this is a textbook zombie meeting. | None needed — cancel outright. |
Protect This One
The bi-weekly Retro is the highest-value meeting on this list — it's the only recurring meeting that reliably converts discussion into a tracked action item, and teams that cut retros under time pressure tend to lose the only structured mechanism they have for catching process problems before they compound.
Time Reclaimed
Making Monday Status Sync async: 8 people × 30 min = 4 hours/week reclaimed.
Shortening Design Review from 45 to 25 min: 6 people × 20 min = 2 hours/week reclaimed.
Killing the Project Phoenix check-in: 5 people × 30 min = 2.5 hours/week reclaimed.
Total: 8.5 attendee-hours reclaimed per week — roughly 442 hours per year, equivalent to about a quarter of one full-time employee's annual working hours.
جلسات تکراری همان سرویسهای اشتراکی تقویم شرکتی هستند: اضافهکردن آنها آسان است، تقریباً هرگز لغو نمیشوند، و بیشتر افراد نمیدانند هنوز بابت کدامیک «هزینه» میپردازند تا زمانی که کسی آنها را وادار به نگاهکردن به صورتحساب کند. جلسهای که برای حل مشکلی ایجاد شده که دیگر وجود ندارد همچنان ادامه مییابد، چون لغو آن نیازمند این است که کسی علناً اعلام کند ارزش وقت اتاق را ندارد — و هیچکس نمیخواهد کسی باشد که این را درباره جلسهای میگوید که مدیرش، یا مدیرِ مدیرش، آن را شروع کرده است.
پرامپت زیر این هزینه اجتماعی را با تبدیل ممیزی به یک تمرین امتیازدهی بهجای یک قضاوت شخصی حذف میکند. بهجای پرسیدن «آیا باید همگامسازی دوشنبه را حذف کنیم»، چهار سؤال محدودتر و سختتر برای بحث درباره هر جلسه میپرسد: آیا این جلسه تصمیمی تولید میکند، آیا محتوا میتواند غیرهمزمان باشد، آیا همه شرکتکنندگان واقعاً لازماند، و آیا هدف اصلی هنوز با واقعیت فعلی همخوانی دارد. یک جلسه میتواند در هر چهار معیار شکست بخورد بدون آنکه هیچکس در اتاق در ایجاد آن هجده ماه پیش اشتباه کرده باشد — فقط شرایط تغییر کرده است.
چرا «این را غیرهمزمان کنید» بهتنهایی یک پیشنهاد واقعی نیست
رایجترین حالت شکست در توصیههای کاهش جلسات این است که در «این میتواند یک ایمیل باشد» متوقف شود. این برای تقریباً هر جلسه وضعیتی درست است، و همچنین بهعنوان یک توصیه بیفایده است، چون هیچکس بر اساس توصیه مبهم عمل نمیکند. بخش محدودیتهای پرامپت یک قالب جایگزین مشخص را برای هر حکم کوتاهکردن یا غیرهمزمانکردن اجباری میکند — یک سند مشترک با مهلت، یک گروه کوچکتر با محدودیت زمانی، یک رشته اسلک با مهلت قطع — زیرا یک جایگزین نامگذاریشده پذیرفته میشود و یک جایگزین بینام بهآرامی اتفاق نمیافتد، و جلسه ظرف یک ماه دوباره به تقویم بازمیگردد.
چرا خروجی صراحتاً یک جلسه را محافظت میکند
تمرینهای حذف جلسه یک حالت شکست در جهت مخالف نیز دارند: وقتی تیمی شروع به اعمال دقت میکند، وسوسهانگیز است که فراتر از نقطه بازده نزولی به حذف ادامه دهد، از جمله جلساتی که بهآرامی کار واقعی انجام میدهند. بخش «این یکی را محافظت کنید» ممیزی را وادار میکند باارزشترین جلسه فهرست را نامگذاری و دلیل آن را توضیح دهد، تا این تمرین به پاکسازی بیرویه تقویم تبدیل نشود که تنها مکانیزم ساختاریافتهای که یک تیم برای یافتن مشکلات دارد — یک بازنگری، یک بازبینی طراحی، یک جلسه برنامهریزی — را همراه با وزن مرده واقعی اطراف آن حذف میکند.
چگونه از این بهخوبی استفاده کنیم
درباره تعداد شرکتکنندگان و مدت زمان در ورودی صادق باشید — عدد نهایی «زمان بازپسگرفتهشده» تنها به اندازه ورودیها معتبر است، و عددی که بر تخمینهای خوشبینانه ساخته شده در برابر محاسبه ذهنی سریع کسی در اتاق دوام نمیآورد و اشتباه از آب درمیآید. اگر واقعاً هدف اصلی یک جلسه را نمیدانید، بنویسید «نامشخص» بهجای حدسزدن یک هدف بخشنده؛ یک «نامشخص» صادقانه خود نشانه مفیدی است که یک جلسه از دلیل وجودی خود منحرف شده، و ممیزی باید با آن اینگونه رفتار کند، نه اینکه توجیهی اختراع کند که محتوای فعلی جلسه واقعاً از آن پشتیبانی نمیکند.