مشکل: Done زیاد، release کم، انگیزه کم
افت انگیزه تیم وقتی اضافهکاری «فرهنگ» شده، Done زیاد ولی release کم — دوبارهکاری و قهرمانبازی. پیروزی نامرئی؛ فقط urgent دیده میشود. نقشهٔ بار یک نام را ماهها قرمز نشان میدهد.
راهحل: سقف بار + پیروزی دیدهشده + اسپرینت بازیابی.
علائم و هزینه
| علامت | هزینه |
|---|---|
| OT عادیشده | turnover |
| همیشه فوری | بدبینی |
| یک نفر همیشه قرمز | بار غیرقابل دوام |
| دوبارهکاری | خستگی |
| گناه مرخصی | فرسودگی |
چارچوب بار و پیروزی (۷ گام)
1. نقشهٔ بار هفتگی. با نقشه حرارتی بار (workload_heatmap) بیشبار قبل از assign.
2. سقف کار در جریان. add = drop یا تأخیر.
3. اسپرینت بازیابی. بدهی فنی + مرخصی واقعی.
4. پیروزی دیدهشده. Done مرتبط هدف در demo.
5. حذف کار کمارزش. leadership add=drop بپذیرد.
6. sanity ساعت. خلاصه زمان (time_summary) overtime.
7. جلسهٔ بازبینی فرسودگی. کاهش بار نه pizza party.
اشتباهات رایج
- pizza party
- نیرو بدون cut محدوده
- ignore نقشهٔ بار
- تمجید heroics
- skip recovery
نقش WKFGo
workload_heatmap— بار per نفرtime_summary— روند ساعت- اسپرینت — بازیابی
- Goals — OKR
هوش مصنوعی باید سبکسنگین کردن گزینهها را به زبان ساده و با متریک واقعی بگوید؛ درصد بازگشت سرمایه ساختگی نسازد.
سناریوهای واقعی
crunch release: OT سه ماه. support+قابلیت: همان تیم.
| سناریو | چه زمانی بررسی شود | کد ابزار |
|---|---|---|
| تأخیر انتشار | اگر قرارداد/کیفیت اجازهٔ جابهجایی تاریخ بدهد | delay_release |
| کاهش محدوده | اگر تاریخ ثابت است و کار کمارزش قابل تعویق است | cut_scope |
| افزودن نیرو | اگر گلوگاه ظرفیت است نه وابستگی پیچیده | add_people |
| توقف پروژه | اگر پورتفولیو بیشبار است و باید شروع کار جدید قطع شود | freeze_project |
سؤالات متداول
متریک فرسودگی؟
نقشهٔ بار + OT + turnover.
remote؟
wins + demo.
deadline؟
cut_scope نه OT.
MCP؟
workload_heatmap، time_summary.
ریتم پیشنهادی
مدیرانی که این موضوع را فقط در جلسات بحران میبینند، هزینه واکنشگرایی میپردازند. متریک پیشرو هفتگی از آتشنشانی ماهانه ارزانتر است. ابزار بهتنهایی کافی نیست؛ سیاست، ریتم و مسئول نامبرده لازم است.
در یک دورهٔ آزمایشی دو اسپرینتی، یک تیم کوچک را با همین چارچوب اجرا کنید. شواهد قبل از الزام سازمانی به کل پورتفولیو. راهنمای عملی موفق را در ویکی بگذارید تا گسترش شود.
بازبینی هفتگی پانزده دقیقه با همان شاخص از کارگاه ماهانه مؤثرتر است. وقتی علامت برمیگردد، اول سیاست و تعریف را بازبینی کنید نه سرزنش فرد.
رهبری باید سبکسنگین کردن گزینهها را صریح بپذیرد: افزودن کار بدون حذف کار دیگر، یا رفع موضعی، همان الگوی شکست قبلی را تکرار میکند. مدیر پروژه تفسیر اضافه میکند؛ عدد از سیستم میآید.
هر فصل جدول علائم را دوباره بازبینی کنید — بازار و تیم عوض میشوند. شروع کوچک امروز از برنامهریزی بزرگ فردا بهتر است.
دوشنبه: خلاصهٔ MCP قبل از هماهنگی — همان شاخص از جدول علائم. چهارشنبه: ماندگی کار یا نقشهٔ بار اگر مرتبط با جریان کار است. جمعه: اگر آزمایش عوض شد، ویکی را یک خط بهروز کنید.
سؤال تست: «اگر فردا ظرفیت ۳۰٪ کم شود، کدام بخش میشکند؟» — جواب باید به سیستم (فرآیند، ابزار، سیاست) اشاره کند نه فقط نام یک نفر.
تیمی که آزمایشی دو اسپرینت جدی بگیرد، قبل از گسترش شواهد دارد. جلسهٔ بازبینی فصلی: آیا شاخص پیشرو بهبود داشت؟ اگر نه، آزمایش عوض کنید نه ابزار.
امتحان کنید
این الگوها را روی داده زنده پروژه اجرا کنید — نه اسلاید.