چرا جمع درصدهای تخصیص، ظرفیت واقعی را نشان نمی‌دهد؟
روی فایل برنامه‌ریزی ممکن است یک توسعه‌دهنده ۳۰٪ در پروژه A، سی درصد در B و چهل درصد در C باشد. جمع دقیقاً صد درصد است؛ پس چرا هر سه پروژه عقب می‌افتند؟ چون ظرفیت انسان مانند فضای دیسک تقسیم نمی‌شود. هر جابه‌جایی میان دامنه، جلسه، مخزن و ذی‌نفع هزینه دارد و کارهای اضطراری نیز از قبل در آن صد درصد دیده نشده‌اند.
اضافه‌بار چندپروژه معمولاً با سه علامت دیده می‌شود: تعداد زیادی کار هم‌زمان باز، صف انتظار روی یک تخصص کمیاب، و اولویت‌هایی که هر مدیر آن‌ها را «شماره یک» می‌نامد. راه‌حل، فشار بیشتر روی فرد نیست؛ تصمیم در سطح پرتفوی است.
ظرفیت اسمی و ظرفیت قابل تعهد را جدا کنید
ظرفیت اسمی همان ساعت کاری تقویم است. ظرفیت قابل تعهد پس از کسر پشتیبانی، جلسه، مرخصی، کار عملیاتی و حاشیه عدم‌قطعیت باقی می‌ماند. برای برنامه‌ریزی اولیه این جدول را برای هر نقش بسازید:
| نقش یا فرد | ظرفیت اسمی | کار عملیاتی ثابت | تعهد پروژه‌ای باز | ریسک |
|---|---|---|---|---|
| توسعه‌دهنده Backend | ۴۰ ساعت | ۸ ساعت پشتیبانی | سه پروژه | جابه‌جایی زیاد |
| طراح محصول | ۴۰ ساعت | ۴ ساعت جلسه | دو انتشار هم‌زمان | صف بازبینی |
| کارشناس امنیت | ۴۰ ساعت | ۱۶ ساعت عملیات | چهار تأیید انتشار | گلوگاه تخصصی |
اعداد نمونه‌اند؛ داده واقعی خودتان را وارد کنید. هدف این جدول محاسبه بهره‌وری فردی نیست، بلکه آشکارکردن تعهدهای ناسازگار است.
چارچوب اصلاح اضافه‌بار در سطح پرتفوی
۱. همه تعهدها را در یک نما جمع کنید
اگر هر مدیر پروژه فقط بورد خودش را ببیند، یک نفر می‌تواند هم‌زمان در چند بورد «ظرفیت آزاد» به نظر برسد. نمای پرتفوی و workload_heatmap باید تخصیص و کار باز فرد را در همه پروژه‌ها نشان دهند. کار پشتیبانی و وظایف تکرارشونده را نیز پنهان نکنید.
۲. کار در جریان بین‌پروژه‌ای را محدود کنید
محدودیت فقط برای ستون Kanban نیست. برای هر نقش کمیاب مشخص کنید چند جریان فعال را می‌تواند هم‌زمان پشتیبانی کند. مثلاً کارشناس امنیت ممکن است دو بازبینی فعال داشته باشد و درخواست سوم وارد صف شفاف شود. صف شفاف بهتر از سه وعده هم‌زمان و سه تأخیر پنهان است.
۳. اولویت را به تصمیم قابل اجرا تبدیل کنید
فهرست پروژه‌های P1 هیچ کمکی نمی‌کند اگر همه P1 باشند. جلسه پرتفوی باید مشخص کند در تعارض ظرفیت، کدام پروژه جلو می‌رود و کدام تاریخ، محدوده یا ترتیبش تغییر می‌کند. تصمیم را با log_decision ثبت کنید تا هفته بعد دوباره از صفر مذاکره نشود.
۴. کار را به بسته‌های قابل جابه‌جایی تقسیم کنید
انتقال یک فرد وسط کار عمیق، هزینه بیشتری از جابه‌جایی میان دو بسته مستقل دارد. وابستگی و معیار Done را روشن کنید تا در صورت تغییر اولویت، یک واحد کامل متوقف یا منتقل شود؛ نه اینکه ده کار نیمه‌تمام جا بماند.
۵. اثر تصمیم را با سیگنال جریان بسنجید
بعد از تخصیص مجدد، فقط ساعت ثبت‌شده را نگاه نکنید. سن کارهای باز، تعداد آیتم‌های مسدود، زمان انتظار برای تخصص مشترک و نرخ تکمیل را مقایسه کنید. اگر بار ظاهراً متعادل شد اما صف Review رشد کرد، گلوگاه فقط جابه‌جا شده است.
مثال: یک مهندس DevOps میان چهار تیم
چهار پروژه برای انتشار آخر ماه به یک مهندس DevOps وابسته‌اند. هر مدیر دو روز از وقت او را رزرو کرده، اما مجموع جلسات، بررسی دسترسی و رفع خطا از ظرفیت هفته بیشتر است.
به‌جای درخواست اضافه‌کاری، PMO این تصمیم‌ها را می‌گیرد:
- پروژه مشتری دارای تعهد قراردادی اولویت اول می‌شود.
- انتشار داخلی یک هفته جابه‌جا می‌شود.
- کارهای تکراری استقرار به یک runbook و مالک دوم منتقل می‌شوند.
- دو درخواست بدون معیار آمادگی از صف خارج می‌شوند.
- تاریخ بازبینی تصمیم برای هفته بعد ثبت می‌شود.
این تصمیم ممکن است همه ذی‌نفعان را خوشحال نکند، اما از چهار وعده غیرواقعی بهتر است.
اشتباهات رایج
- استفاده از درصد تخصیص بدون دیدن تعداد کارهای هم‌زمان؛
- حل گلوگاه با افزودن فردی که onboarding او زمان می‌برد؛
- پاداش‌دادن به قهرمان‌بازی و اضافه‌کاری مداوم؛
- مخفی‌کردن کار پشتیبانی خارج از بورد؛
- واگذاری حل تعارض به خود فردی که چند مدیر به او فشار می‌آورند؛
- سنجش «مشغول‌بودن» به‌جای زمان انتظار و خروجی تکمیل‌شده.
WKFGo کجا کمک می‌کند؟
نمای پرتفوی تصویر پروژه‌ها را کنار هم قرار می‌دهد و workload_heatmap تمرکز بار روی افراد یا نقش‌ها را آشکار می‌کند. بورد، وابستگی و بسته کاری نشان می‌دهند جابه‌جایی ظرفیت چه کاری را متوقف می‌کند؛ decision_inbox و log_decision نیز تعارض اولویت را به تصمیم ثبت‌شده تبدیل می‌کنند.
این ابزارها ظرفیت ایجاد نمی‌کنند و جای گفت‌وگوی سخت درباره توقف یا تعویق پروژه را نمی‌گیرند. ارزش آن‌ها این است که هزینه انتخاب را پیش از شکستن تعهدها قابل مشاهده می‌کنند.
پرسش‌های متداول
آیا چندپروژه‌ای‌بودن همیشه بد است؟ خیر. بعضی نقش‌ها ذاتاً میان پروژه‌ها مشترک‌اند. مشکل زمانی است که تعداد جریان فعال، زمان تمرکز و صف انتظار اندازه‌گیری نمی‌شود.
برای فرد متخصص چند پروژه مناسب است؟ عدد جهانی وجود ندارد. نوع کار، اندازه بسته‌ها و حجم پشتیبانی تعیین‌کننده‌اند. از داده جریان خود تیم برای تعیین محدودیت استفاده کنید.
آیا استخدام مشکل را حل می‌کند؟ گاهی، اما اگر اولویت و ورودی کنترل نشود، نیروی جدید نیز سریعاً میان همان صف‌ها پخش می‌شود. ابتدا مشخص کنید گلوگاه ظرفیت است یا تصمیم و فرایند.
یک جلسه پرتفوی با تصمیم واقعی اجرا کنید
فهرست همه افراد مشترک میان پروژه‌ها را استخراج کنید، سه تمرکز بار بزرگ را پیدا کنید و برای هرکدام یک تصمیم «ادامه، تعویق، کاهش محدوده یا انتقال» ثبت کنید.