هفت ترفند MS Project که برنامهٔ شما را نجات می‌دهد

MS Project را همه بلدند باز کنند؛ ولی همان‌جایی که برنامهٔ واقعیِ یک نیروگاه یا پالایشگاه باید «زنده» بماند، یک‌سری قابلیت‌ها هستند که بیشتر برنامه‌ریزها سال‌ها بعد از اولین پروژه‌شان کشف می‌کنند. این هفت ترفند، همان‌هایی هستند که بعد از سال‌ها کار با MSP در پروژه‌های صنعتی بیشترین دردسر را برای من حل کرده‌اند — با مسیر دقیق منو و دلیل اینکه چرا کار می‌کنند.

۱. Deadline به‌جای Constraint

شایع‌ترین اشتباهی که در فایل‌های ورودی پیمانکارها می‌بینم: برای «تاریخ موعد تحویل» از محدودیت‌های سخت مثل Must Finish On یا Finish No Later Than استفاده می‌کنند. نتیجه؟ برنامه سرریز محدودیت می‌شود، مسیر بحرانی مصنوعی می‌سازد و هر بار Schedule تازه می‌گیرید، هشدارهای عجیب می‌بینید.

ترفند: به‌جای Constraint از Deadline استفاده کنید (ستون Deadline، یا دابل‌کلیک روی فعالیت → Advanced). Deadline تاریخ را «قفل» نمی‌کند؛ فقط اگر کار از موعد بگذرد، یک فلش قرمز روی نمودار گانت نشان می‌دهد و در ستون Total Slack اثر می‌گذارد. برنامه روان می‌ماند و موعد هم ناپدید نمی‌شود.

قاعدهٔ عملی من: Constraint فقط برای دو حالت — تاریخ اجباری قراردادی (مثل تاریخ گشایش LC که واقعاً در دست ما نیست) و محدودیت جفتی با برنامهٔ مرجع کارفرما. بقیهٔ تاریخ‌های «موعد»، همیشه Deadline.

۲. Task Calendar — تقویم سطح فعالیت

خیلی‌ها فکر می‌کنند برای این‌که کاری در روز جمعه هم جلو برود باید تقویم کل پروژه را عوض کنند. اشتباه است — تقویم پروژه را خراب می‌کنید. MSP یک لایهٔ تقویم دیگر دارد: Task Calendar.

مثال واقعی: تست جوش و بازرسی VT در کارگاه باید در شیفت روز کار کند، ولی فعالیت «سردکردن ری‌اکتور» باید ۲۴ ساعته و ۷ روز هفته اجرا شود. دابل‌کلیک روی فعالیت → Advanced → Calendar → تقویم «۲۴ Hours» را اختصاص دهید. نکتهٔ مهم: تیک Scheduling ignores resource calendars را خاموش نگه دارید مگر این‌که واقعاً می‌خواهید تقویم منبع نادیده گرفته شود — وگرنه هشدار مکرر می‌گیرید.

۳. Inactivate Tasks — سناریوسازی بدون حذف

برای تحلیل what-if در جلسات، بیشتر افراد یک نسخهٔ کپی از فایل می‌سازند («Project-final-v2-new-rev.mpp»!). روش درست: انتخاب فعالیت‌ها و زدن Inactivate (تب Task → گروه Schedule). فعالیت غیرفعال می‌ماند ولی از محاسبهٔ مسیر بحرانی، ارزش کسب‌شده و گزارش‌ها حذف می‌شود؛ رنگش هم خاکستری می‌شود تا خودتان گم نشوید.

i
هشدار: Inactivate فقط در نسخهٔ Project Professional هست، نه Standard. و اگر فایل را به P6 یا نرم‌افزار دیگری Export می‌کنید، اول فعالیت‌های غیرفعال را حذف یا فیلتر کنید.

۴. Lead/Lag قابل‌ردیابی با فیلد سفارشی

لَگ‌هایی که داخل وابستگی‌ها (SS+۱۴d) قایم شده‌اند، کابوس به‌روزرسانی دوره‌ای هستند: هیچ گزارشی نشان‌شان نمی‌دهد و در Rev جدید یکی دو روز جابجا می‌شوند و همه چیز می‌خزد.

راه‌حل: لَگ‌ها را صفر نگه دارید و مدت تأخیر را در یک فیلد عددی سفارشی (مثلاً Number1 با عنوان «Lag») روی فعالیت بریزید. بعد در ستون پیش‌نیازها، با فرمول ساده شمارهٔ فعالیت پیش‌نیاز + مقدار Lag را کنار هم ببینید:

Text1 = [Predecessors] & " +" & [Number1] & "d"

حالا یک فیلتر ساده (Number1 > 0) کل لَگ‌های پروژه را یک‌جا به شما نشان می‌دهد — و در جلسهٔ به‌روزرسانی، دفاعش هم آسان است چون لَگ به‌عنوان دادهٔ برنامه دیده می‌شود، نه یک عدد قایم‌شده در رابط.

۵. Baseline دوم — حافظهٔ جلسات مصوبه

Baseline فقط یکی نیست. فرض کنید برنامهٔ Rev.A مصوب شده، بعد از سه ماه Rev.B تأیید می‌شود. اگر Baseline را روی نسخهٔ جدید ست کنید، تاریخچهٔ انحراف نسبت به مصوبهٔ اول می‌سوزد — همان چیزی که در دعوای claims باید نشان بدهید.

ترتیب درست: Project → Set Baseline → Set baseline: Baseline1 (نه Baseline اصلی). بعد ستون‌های Variance مربوط به Baseline1 را در جدول Tracking نمایش دهید. این‌طوری همیشه «برنامهٔ مبنا» و «برنامهٔ بازنگری‌شده» را هم‌زمان دارید و می‌توانید انحراف‌ها را نسبت به هر دو گزارش کنید.

۶. Automatic Filtering برای جلسهٔ هفتگی

در جلسهٔ هفتگی نمی‌خواهید ۱۲هزار خط WBS را ورق بزنید. دو راه‌میان‌بُر:

۷. گانت‌چارت که مدیریت می‌فهمد: Bar Styles شرطی

رنگِ میله‌ها لازم نیست برای همه یکسان باشد. در Format → Bar Styles می‌توانید سطر جدیدی تعریف کنید که فقط فعالیت‌هایی را رنگی کند که در فیلد سفارشی‌شان مقدار خاصی دارند — مثلاً میلهٔ «فعالیت‌های تأخیرخوردهٔ این دوره» را قرمز، «تازه شروع‌شده» را آبی و milestoneهای نزدیک (Deadline ≤ ۳۰ روز) را لوزی نارنجی بکشد. شرطش را در ستون Show For … Tasks می‌نویسید (مثلاً Normal، و در Filters همان فیلد سفارشی).

نتیجه: فایل MSP به‌جای «یک کوه خط»، گزارشی بصری می‌شود که مدیر پروژه در ده ثانیه می‌خواند.

جمع‌بندی — کدام ترفند را اول اجرا کنم؟

اگر فقط سه‌تایش را می‌خواهید این‌ها را اعمال کنید: Deadline به‌جای Constraint (سلامت منطق برنامه)، Lag قابل‌ردیابی (پایداری به‌روزرسانی دوره‌ای) و Baseline دوم (دفاع‌پذیری در جلسات و claims). بقیه برای گزارش‌سازی و جلسات عالی‌اند.

اگر اهل محاسبات ارزش کسب‌شده هم هستید، داشبورد EVM آنلاین سایت و یادداشت محاسبهٔ ضریب وزن در اکسل و MSP مکمل همین ترفندها هستند؛ و برای کنار هم گذاشتن MSP با P6، یادداشت Global Change در Primavera P6 را دنبال کنید.

سوالات متداول

غیرمستقیم بله: اگر فعالیت از Deadline بگذرد، Total Slack منفی می‌شود و MSP آن را بحرانی گزارش می‌کند (مگر آستانهٔ بحرانی‌بودن را تغییر داده باشید). خود Deadline زنجیره‌ای نمی‌سازد و منطق شبکه را قفل نمی‌کند — همان کاری که Constraint می‌کند.
Total Slack شوکی است که فعالیت بدون به‌خطر انداختن پایان کل پروژه (یا یک محدودیت) دارد؛ Free Slack شوکی است که بدون جابجا کردن جانشین مستقیمش دارد. برای مدیریت منابع، Free Slack نگاه دقیق‌تری است؛ برای گزارش بحرانی‌بودن، Total Slack.
هیچ — تاریخچهٔ Baseline دست نمی‌خورد. فعالیت غیرفعال در محاسبات کنار گذاشته می‌شود ولی داده‌هایش باقی می‌ماند؛ به همین دلیل برای claims بهتر از حذف کردن است. فقط مراقب باشید فیلترهای گزارش شما فعالیت‌های غیرفعال را نشان ندهند (در فیلتر، Active Tasks را شرط کنید).
بله؛ MSP در هر جدول (Task/Resource/Assignment) چندین فیلد عددی و متنی خام (Number1..10، Text1..30 و ...) دارد که از طریق Custom Fields می‌توانید rename، فرمول و Graphical Indicator به‌شان بدهید. اگر فایل را با دیگری ردوبدل می‌کنید، نام فیلدها را در مپینگ import/export هماهنگ نگه دارید.
← همه‌ی نوشته‌ها RSS